Re: [Openexr-devel] OpenEXR in Blender's CVS

[Florian Kainz]

Gernot Ziegler wrote:
> It is integrated into imbuf, and provides a new output format option,
> OpenEXR.
> Currently, it outputs losslessly compressed OpenEXR files with
> the components "R", "G", "B", "A" and "Z". All components are in the range
> 0.0 - 1.0, where Z has near=0.0 and far=0.0 .


At least conceptually, R, G, B, and Z in an image have an
unlimited range.  One of OpenEXR's main advantages is that
pixel values that occur in practice can be stored in image
files without clamping or normalization.

Since A values are inherently limited to a zero-to-one range,
clamping out-of-range A data is fine.

Limiting RGB values to a zero-to-one range degrades the image
unnecessarily; you lose information about bright highlights.

Normalizing Z to a zero-to-one range is also undesirable;
see my reply to Gernot's other mail to openexr-devel:

> At ILM we output the actual Z values, without normalization.
>
> We often use FLOAT channels for Z data, because the range of the
> depth values can be enormous.  For example, in an image that shows
> the moon seen through a window, the distance to the window frame
> might be 1 meter, but the distance to the moon would be 3e8 meters.
>
> Normalizing the Z values to a zero-to-one range is probably not a good
> idea because even with FLOAT pixels you can lose too much precision.
> In the "window frame vs. the moon" example, you would probably not be
> able to tell whether a nearby object is in front of or behind the window
> frame if the Z data were normalized.  With floating-point pixels that
> indicate actual depth values, this problem does not occur.
>
> Normalizing Z values also makes depth compositing more difficult.
> Given two images with Z channels, you have to consider both images'
> near and far values in order to compare the images' depth values.
> And if you combine the two images into one, you have to make sure
> that you store proper near and far values with the composite image.
>
> I think Blender should save actual Z values, without normalization.
> If you need the near and far values, store them as float or double
> attributes in the file header.