4
$\begingroup$

I want to create a depth map via the node editor by mapping the "Z" of my render to a "Map Value" node with Size 0.05. Basically this scales the depth down to 1/20th of it. When I save the resulting image as a .PNG or .EXR (using new GIMP version) the resulting grey values are not what I expected. They are not even linear. When I press the left mouse button in Blender on the render window, the values are very plausible (first RGB values where like R 0.1 G 0.1 B 0.1, the CM RGB values are off like in the saved pictures, e.g. R 0.3492, ...). I made a test scene with planes at different z-values (see table) and looked at the curves:

enter image description here

I tried a gamma 2.2 correction and it seemed to linearize the output. But I cannot reconstruct my z values. With the plausible values from the render image "color picker" I can. How do I export THOSE values? I cannot post another link, but one person is saying that I should just output the Z directly without the scaling. Does the mapping node play a role?

enter image description here

$\endgroup$
9
$\begingroup$

There are a few things going on, here.

Firstly, the z-depth is exactly the distance of each pixel from the camera. You can demonstrate this by setting the clipping planes of your camera to specific values, and then using your mouse to inspect the RGB values in the render result view (not the saved image). The closest pixels will be the same value as your near clipping plane (assuming there's geometry that close), and the farthest pixels will be the same values as your far clipping plane (except for where the sky is visible, where the value will go to "a very large number"). I proved this to myself just a couple of days ago. I'll see if I can dig that project back up and upload a demonstration of some kind.

Secondly, those values don't fit in any typical RGB image. So anytime they need to be put into a file, they get mapped to 0-255. That means what might have been a 19-1200 floating-point range got squashed down to 0-255 non-floating point.

Lastly, when the image undergoes that transformation from floating point precision to 0-255, it ALSO gets mapped to a new color domain, which often includes a gamma adjustment and other strange transformations. It's usually quite effective for visual data, but plays havoc with numeric data.

The solution is an image format that is not limited to a 0-255 range for each RGB value. Enter OpenEXR and HDR. They can store the raw, floating-point values as they are in Blender, without compressing them... much. They're still limited to 32-bit floating point values, but that's plenty for just about anything.

So, if your data ever leaves Blender, it's been compressed somehow, unless you save it DIRECTLY to EXR or some other high-range format (without any intermediate nodes or processing). The best idea would be to use the buffer directly in Blender, rather than loading it from a file. If you do need to save it to a file, make sure that you're saving to some 32-bit format.

It may also be worth looking into the Mist Pass. It's similar... but different.

$\endgroup$
  • 2
    $\begingroup$ Also tag the data in the file as data, non-colour. $\endgroup$ – troy_s Oct 21 '16 at 15:03
  • 1
    $\begingroup$ If I save the Z values directly into an EXR, it works. Don't use any intermediary nodes! Thank you. $\endgroup$ – Close Call Oct 24 '16 at 6:46
  • $\begingroup$ I'll add that detail, for clarity. $\endgroup$ – Matt Oct 24 '16 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.