How do I tell Daz to render in 32 bit color?
RexRed
Posts: 1,323
How do I tell Daz to render in 32 bit color?
I am getting banding in the grays of my VDB in the viewport and the banding is also in the PNG render.
I tried a beauty canvas and the banding is still there.
Do I need to change the color settings in NVidia panel or something?
VDB Banding.png
582 x 405 - 32K
Post edited by RexRed on
Comments
You need to use the canvasses feature in the Advanced tab of Render Setings - add a Beauty Pass Canvas, select everything in the scene, and then click the Nodes button and select Create From Selection. Now when you do your render and save it as MyRender a sub-folder will be created in the same location, names MyRender canvasses, and that will have an .exr file with the high bit-depth version of the render.
That is very helpful Richard, I belive what we are seeing in this image is the banding is actually in the VDB and not the Iray color.
You need to select Iray for rendering, not PBR, and, technically (probably not relevant), you need to ensure your video card uses 32-bit not 16-bit, although the latter point is almost certainly not the issue you are seeing.
The Daz PNG implemention does not support anything other than sRGB rendering. sRGB has a very limited dynamic range and produces banding outside that range.
PNG itself supports anything within the human range of perception, but it's complicated and not portable (despite the P).
PBR meaning? It isn'ta render engine, to be picked as an alternative to Iray, and the PBR Skin shader should support 32 bit colour output as any Iray shader should.
sRGB is a colour space, the renders saved from DS do not have a colour space assigned (so many editors will, by default, assign sRGB).
The portability has nothing to do with colour spaces - it's about being readily readable, using a common, published code base (unlike soem existing formats used for websites when it was released). PNG does support higher bit-depths, that isn't why the base render is limited to 8 bits per channel.
That's precisely what is happening. I extracted a 55x1 strip from somewhere around the center portion of the image and dumped the pixel values. They step down consistently about once ever 20 pixels; see the text at the end which records the exact RGB values from the strip (I've tried to include the strip as well as an RGB PNG).
You can take the EXR file from the "Beauty" canvas, i.e. the one you produced originally apparently without an alpha channel and convert this to a 16-bit PNG either with a gamma chunk (gAMA) to get sRGB with extra precision or with linear values. Both changes will, in this case, will be sufficient to avoid the bands.
Note that you will still see bands on a display unless you have an HDR monitor and appropriate software; the fact of the matter is that your pixel values are well below the dynamic range of 8-bit sRGB! People may also see zebra strips in the image, that's a visual side effect of the bands; our visual system automatically does edge enhancement on the edges of the bands.
For reference the 8-bit components in that strip are all around 27 and there are three separate steps from RGB(29,28,29) at the left to RGB(26,25,26) at the right. The final step in each case is more than a 6% reduction in light level; RGB%(6.1%,6.3%,6.12%). The measured human sensitivity to luminance changes (meausred using an sRGB HDR monitor) is about 1:60, so 1.6%; bands are unavoidable at component levels such as this even at the lower light levels involved. The 16-bit linear values range from 868 to 687; all give better than 1% accuracy. 1% is the generally accepted requirement in bright (daylight) conditions (13EV100 or thereabouts.)
We can convert the sRGB values into actual luminance levels in cd/m² given that the reference sRGB monitor has an output of 80cd/m²; the actual luminance of RGB(27,27,27) is 0.945cd/m² That corresponds to about 3EV100; pretty dark. At that luminance level we are losing our colour vision capability which is why the image doesn't look purple (the green component is consistently about 6% less bright than red and blue.)
R G B
=== === ===
29 28 29
29 28 29
29 28 29
29 28 29
29 28 29
29 28 29
29 28 28
29 28 28
29 28 28
29 28 28
29 27 28
29 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 28
28 27 27
28 27 27
28 27 27
28 27 27
28 27 27
28 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 27
27 26 26
27 26 26
27 26 26
27 26 26
27 26 26
26 25 26
26 25 26
26 25 26
26 25 26
26 25 26
26 25 26
My bad: I meant Filament
sRGB also defines a transfer function and that is what is relevant to the observed banding. This is what I am referring to; the transfer function limits the dynamic range by making a balanced choice between dynamic range and precision. I should probably have added that no 8-bit encoding can ever be sufficient; Poynton's estimate was (is) 463 separate levels based on 1% accuracy, my estimate based on 1/60 accuracy is 279 levels but I maintain 100:1 dynamic range is not enough).
The colour space does not matter in this context, it only matters how that colour space is digitally encoded.
I sort-of agree with your definition. However while you or I can write an HDR PNG which matches the v0 specification, for example by using a high gamma encoding, as in the ITU's definition of PQ, here:
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2100-1-201706-S!!PDF-E.pdf
It's still the case that the resultant image will hardly ever be handled correctly. You sort-of explained why:
Indeed. Most punters monitors really are very close to sRGB, so even if the output image file (PNG or otherwise) isn't sRGB it will get reduced to sRGB and that will often be done incorrectly causing the bands to re-appear. Producing a PNG which is not sRGB is just going to lead to confusion, bug reports and bad press.