Re: [Openexr-devel] New 8-bit data type

[Florian Kainz]

Klas Skogmar wrote:
> 
> I think it would be good if an ordinary 8-bit "byte" datatype was
> added, that could be used to create images with a HALF luminance
> channel, and two byte color channels (Lab for example). This would
> increase the benefits of 32 bit/pixel images without taking a lot of
> space. What do you think?
> 
> /Klas
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openexr-devel

When we started our high-dynamic range file project here at ILM 
about three years ago, we discussed adding an 8-bit data type, 
but decided against it, for a couple of reasons:

* We wanted as few different data types in the file format as
  possible; this simplifies application programs that read the
  files, because they have to deal with fewer cases when 
  converting from one data type to another.

* Files would not get appreciably smaller by adding an 8-bit
  integer data type.  At least with PIZ compression, an 8-bit
  integer image would compress to almost the same size as a 
  16-bit floating-point image that happens to contain only 
  the numbers 0.0, 1.0, ... 255.0 (or any other set of 256
  distinct values, for example 0.0, 1.0/255, 2.0/255, ... 1.0).
  
* "Correct" interpretation of 8-bit image data is problematic.
  With floating-point data, we can simply define that the numbers 
  stored in the pixels are proportional to the quantities they 
  represent.  For example, 2.0 means twice the intensity (or 
  velocity, depth, etc.) as 1.0.
  With 8-bit data, some form of gamma or logarithmic encoding 
  must be used to achieve reasonable image quality.  128 does 
  not represent twice as much as 64.  People tend to disagree 
  on the details of how to convert properly from floating-point 
  to 8-bit integer data, so we would probably have to support
  multiple different ways of converting the data.  In order to 
  recover the original floating-point values, some description 
  of the conversion process would have be stored in the file 
  header (for example, "this is a file with a gamma of 2.2, 
  with a linear ramp for the lowest 16 values").  Application 
  programs reading the file would have know how to interpret 
  the information in the header, which would make writing those
  programs unnecessarily difficult.  Storing floating-point
  data is just easier.