Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
1) Yes.
2) Yes, you have to use a canvas, it's render settings > advanced > canvases, the exr will be placed in the render library. Spectral rendering has nothing to do with color spaces it's just a different way to handle light in the rendering process. And yes, as I already said the exr is in linear space so it's independent of tone mapping.
Yes, two completely seperate problems in this thread.
With some confusion based on the misapprehension that setting rec2020 in Spectral Rendering is the way to change the render format to rec2020.
With Spectral Rendering causing black areas, you could use it for still images where you can spot any errors and compensate. ...but for an animation I would say no.
The only way to choose BT2020 is to enable Spectral Rendering, so that's where my confusion is coming from.
As for .exr, they come out all white, and the only thing I can do to correct it is bring it into photoshop and bring down the exposure. Is there a way to get a properly exposed .exr?
You don't have to "correct" the EXR files. The compositing program will take care of that.
Does your compositor import EXR files?
Does your compositor output to rec2020? (most do, even the free versions!)
How will you judge the conversion/settings/result if you don't have a reference monitor or even a basic HDR screen?
This video of the process, EXR files from Blender to Resolve should give you a better idea of what you've got yourself into.
It is just normal that the exr looks white, it needs to be tone mapped to the color space of the output device, that in your case will be rec 2020. Gimp gets a set of tone mapping functions for HDR images. Don't know Photoshop.
Yes, I have Resolve, Premier, and AfterEffects, they all import .exr (from what I've tried with the last render I just did)
Again, yes all 3 will output Rec2020
I have my Asus ProArt PA329C which covers 84% Rec2020 in HDR, and I have 4 x 4K Televisions that all support HDR. How is it assumed that I don't have a "basic HDR screen"?
Thanks, I'll give it a look, at first import for an .exr still image, it was still all white in resolve, so I figured I must be missing something...
I rendered a still just to see what I was working with, but this will be for Video/Animation, and I'd prefer not to have to pre-process in photoshop first and then bring them into Resolve or Premiere/AfterEffects. I'm taking a look at the video that was posted, it looks l like it may have the answer...
The monitor's color space or calibration has nothing to do with the "black" colors.
As this is a wide topic, here is a link about all the stuff going on (and all the pitfalls involved) - be warned though, it is a long read and difficult to understand.
https://chrisbrejon.com/cg-cinematography/
@cgidesign This isn't useful. I mean it's a good reading and thank you that's very interesting, but doesn't provide a direct solution for daz studio that's what we're talking about here. If you know better please explain I'd be curious too.
p.s. And I mean it, seems very well done thank you for the link.
p.p.s. That the rec 2020 option in spectral rendering defines the output is only my opinion, since I don't have a rec 2020 monitor to test it. Specifically for what I understand it defines the input for color to spectral conversion, so if the user gets a rec 2020 monitor then iray treats the input colors as rec 2020. But again you can use rec 2020 without spectral they're two different matters.
https://docs.omniverse.nvidia.com/prod_materials-and-rendering/prod_materials-and-rendering/render-settings_iray.html
p.p.p.s. I use daz studio 4.15 to avoid the new iray issues in 4.20, so in my version the spectral rendering always uses linear srgb for color to spectral conversion. That's fine for me since I have a srgb monitor.
This is exactly the reason why so many people - including myself - seem to struggle with spectral rendering since 4.20 has been released.
I´ve got 4.15 installed as well but I forced myself to use the 4.20 beta lately becaue imho one has to move forward at one day anyways.
The problem is that with 4.20 you now have to chose a color space for spectral rendering and a simple srgb is none of the options.
Richard keeps claiming that rec709 is the same and has been used in older versions of DS for spectral rendering but no matter how often that is said, it doesn´t change the fact that it doesn´t look like a non spectral render. @Masterstroke´s pictures show that pretty obvious.
Before 4.20 I could use the benefits of spectral rendering without messing up my colors. That´s impossible now... at least to me and as it seems to a lot of others as well.
Either something is pretty broken here or we all lack the knowledge of how to set up a propper workflow as it seems to me.
If the full collar spectrum in the rec2020 *.exr file is included is easy to test on any monitor in Photoshop or Gimp. You can shift the collars with the Hue slider. You might never see the whole spectrum, but you should be able to see each end of the spectrum as you shift the slider.
e.g red is black, but green is visible
or
Green is black, but Red is visible.
At any Photoshop collor settings, the red fields are black in canvas rendering.
I assume an Iray bug here, or the full collar information is not suppose to be in the 32 bit exr file.
I find it more than a little alarming, after reading the replies here, that the only way to produce a video in a useable colorspace for HDR, is to render it out in still images with canvases, and then manually piece together each frame when there should be a raw, uncompressed video format capable of preserving whatever colorspace you wish to work in.
Richard is right rec 709 is the same as linear srgb. As for the example by @Masterstroke the reference is right with rec 709 and is out of gamut with rec 2020, but this is expected since he's on a srgb monitor.
The best color option you have for spectral rendering is rec 709 + faithful + cie 1964.
That's what anyone does when working with hdr it's not alarming at all. You output a series of exr images then post process.
I'll defer to your apparent expertise in this, but it's still alarming that it can't simply render out to AcesCG or BT2020 in a video container with a codec that houses 10-12bit information. It's not like Cinema cameras are shooting 24-30fps with layered raw 32bit images that need significant post-processing to be useable in Premiere and Resolve... I simply import my video, tell it the starting colorspace, and the desired output colorspace, and it's done. This is not the case for .exr images. If the goal of a PBR engine is to calculate light bounces into a software emulated camera sensor and produce an image as if it were a camera, it seems it fails miserably in this regard... It really should be as easy as "Render to BT2020" or "Render to AcesCG" and then all the information you need to work within that colorspace is present in the outputted video file. I can see how .exr is handy, especially for extra post effects, but it *is* a ton of work when you don't plan on using any of those post effects.
There is no one click solution because there is not a technical problem but a missconception about what happens. This link https://chrisbrejon.com/cg-cinematography/chapter-1-color-management/ is the one to read about the concepts. Normally I post something like "click this button to solve your issue" but in this case one need to understand the background mechanics to utilize something like BT.2020 or ACEScg.
Regarding the "black" color:
I was in the same boat not long ago and read a lot of information to understand what's going on. Below is my simplified answer of what I understood:
Technically it would help if the color picker could be switched to the desired working space. E.g. in Resolve, Nuke etc. you can do that. That would solve the picked color issue. But, the textures made in an image editor could still be an issue if that one still works in sRGB.
Example: pure sRGB picked in DS and rendered as BT.2020
I am not sure about that:
Here are two renders out of 4.20.0.12 beta:
Non spectral with default tone mapping.
Spectral REC.709 with default tone mapping:
It would be helpful, if anybody here had a monitor, that can display the ful collar range and render a gamut plate to an *.exr file and letting us know, if the rec2020 works or not.
I still don't think monitor callibration has anything to do with that, for a monitor only shows a part of the gamut spectrum. By shifting the focus to another part of the gamut doesn't work, it doesn't show another part of the collar spectrum, which suggests, that this collar information is not stored in the image file.
It is NOT the monitor !
You are correct. We have no way of telling Iray to switch to the matching "primaries". That would convert your colour chart texture (and all other sRGB textures) correctly and not have black areas.
The reason rec709 works is because it was always rec709 internally, even before we had a choice of other colourspaces added to the list.
But Vray 5 does this with AcesCG according to Autodesk/Maya. It takes the sRGB that most textures are created in, then converts and renders out to AcesCG without turning reds black or greens black, at least, if I understand this correctly: https://www.chaos.com/blog/everything-you-need-to-know-about-acescg
You can also read more about setting up a workflow in Maya here:
https://docs.chaos.com/display/VMAYA/ACEScg+Workflow+Setup
The pertinent quote is this:
"This is taken care of in a setting in Maya, which in turn, we adapt in V-Ray to do all the conversion for you at the end.
For your input images, we support the following color spaces natively: Raw, ACEScg, scene-linear or gamma Rec. 709, and sRGB."
Or am I misinterpreting what it's saying?
Yes I get what you mean, in CGI it's just easier to adjust an HDRI sequence in post rather than trying to mimic a real scenario with the rendering engine alone. Then yes of course real footage is different and an option to output directly on a rec 2020 codec would be useful to have anyway. I agree on that.
@cgidesign Thank you for the explanation I believe this settles it. It's a bug in the spectral conversion then. My mistake was to assume that the rec 2020 spectral conversion would only work for a rec 2020 output device. Also because I have no way to test this. But, if iray can't handle the rec 2020 spectral conversion then we can always use rec 709 for linear srgb, that's the "color picker" space. Then output to rec 2020 with exr as suggested to Jason.
@Padone It is not really a bug but a general limitation of the math used to convert color spaces via simple matrix transforms. It happens in all apps using this method. E.g. in the below linked thread a professional user has video material in ARRI Log color space (I think Lord of the rings was also shot with ARRI cameras). He puts it in Nuke for compositing and converts the ARRI Log gamut via OCIO transform into ACEScg gamut. So, all high end equippment and software but in the end he gets negative color values. All posters agree that this can happen. The ACES group is working on a more "smart" color conversion for v.2 of ACES because a lot of people faced those problems (and a lot of others specific to ACES as well).
https://community.acescentral.com/t/color-primaries-shifting-and-negative-values-ocio-confusion/892
What I missunderstood first when trying out wide gamut spaces in DS was the difference of gamut mapping via simple transforms versus gamut mapping with ICC profiles. In the latter one the "smart" conversion takes care that a color not fitting in the target color space gets converted in one or another way without ever creating negative values. But the simple matrix transforms don't take care of this. Like said before, this is one reason why the industry pros. tend to create textures and picked colors in that color space they decided to work in.
It is really not a topic that can be fully explained in a few forum posts. It took me a long time to go through all those web pages to finally understand why I can't just use ACEScg in DS and get "better" renders. But what I think would make sense for DS is, that, if it includes ACES, BT.2020 etc. at least the color picker should be switchable to the desired color space. But I assume those gamuts are only in DS because iray offers them - I don't think DAZ expected that we "hobby users" use those new features seriously and then ask for the same solutions the pros. have in their high end stuff.
So, if I am understanding you, and your posts correctly. In DS, theoretically, I could render out to BT.2020 or AcesCG if I first manually converted all of my textures to those colorspaces, or use textures that were created natively in those color spaces? This actually seems like a simpler solution than rendering out .exr and going frame by frame manually piecing them together in Resolve...
That's exactly why I assumed that the rec 2020 spectral would only work with a rec 2020 monitor, because it makes sense that the "color picker" is in the output space. But again I have no way to verify this because I don't have a rec 2020 monitor, so I trust your explanation instead that sounds reasonable to me.
@JasonWNalley I agree with @prixat, you don't really need to set rec 2020 for spectral conversion, this has nothing to do with the output color space, it's only for spectral conversion. I mean rec 709 with linear srgb textures will do just fine for the color picker.