Re: [Openexr-devel] 16-bit unsigned integer

[Florian Kainz]

Assuming you have 16-bit integers that represent RGB data in the 
range from 0 to 1, I would recommend converting them to 16-bit 
floating-point (half) numbers.  Here's why:

By representing RGB data as half (or optionally as 32-bit floats)
it becomes possible to make the numbers in the pixels proportional
to the pixels' luminance.  This way "correct" image processing,
and displaying an image on a screen, become rather easy.

There are 15361 different half values values between 0 and 1, and 
their distribution is close to perceptually uniform.  Conversion 
from 16-bit integers to half is lossy, but the data loss cannot 
be detected visually, unless you post-process the original and the
half image specifically to highlight the differences.  For any 
pixel value greater than 0.000061, the relative error introduced 
by conversion to half is less than 0.0005.

It would of course be easy to add a new 16-bit integer pixel type
to OpenEXR, but I think it would be a bad idea to use this type to
represent RGB data.  We would either have to define a fixed mapping
from integers to luminance values, or the mapping would have to be 
defined by an attribute in the file header.

A fixed mapping would make use of the integer data type lossy, 
unless the mapping happens to be exactly the same as what the
program writing a file uses internally. (One might say that we 
already have such a fixed mapping; it is called "half".)

If the mapping from integers to luminance values was defined by an 
attribute in the file header, then programs that wanted to extract 
RGB data from arbitrary OpenEXR files would have to include code 
that knows how to interpret the extra attribute.