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

[Drew Hess]

Klas, have you thought about using half values and subsampling the chroma
channels ala 4:2:2 YUV?  Then you would still have 32 bits per pixel.

-dwh-



On Tue, 6 May 2003, Florian Kainz wrote:

> 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.
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openexr-devel
>