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

[Florian Kainz]

Robin Rowe wrote:
> 
> There seems to be 32-bit unsigned int support, but not 16-bit except as fp
> half. Is that right?
> 

Yes, this is correct.  When we designed OpenEXR, we tried to keep the 
number of different pixel data types as small as possible.  Increasing 
the number of "options", for example, pixel data types, tends to make 
programs that read image files significantly more complicated.

Using OpenEXR in production at ILM, we found that the three data types
that OpenEXR provides are sufficient:

16-bit floating-point numbers have enough range and resolution for red, 
green, blue, alpha, and similar channels that represent "continuous" 
quantities.

For some types of information, for example, z depth, the range of the 
16-bit numbers is too small, so we added a 32-bit floating-point data 
type.

The 32-bit integer data type is meant to hold discrete per-pixel data,
for example, identifiers that indicate which object is visible at a
particular pixel.

If you have integer per-pixel data that happen to fit into 16 bits,
you can store them in a 32-bit integer channel.  OpenEXR will preserve
the data exactly, and the PIZ compression method will take advantage
of the fact that only 16 of the 32 bits are used.  If the remaining 
16 bits in each pixel contain only zeroes, PIZ will compress them
to almost nothing.

I would not recommend using integer image channels to store RGBA 
and similar data; if those types of data are converted to "linear"
floating-point numbers, programs that read the image files don't have
to guess how the integer pixel data map to luminance values.

Florian