[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-devel] New 8-bit data type
From: |
Florian Kainz |
Subject: |
Re: [Openexr-devel] New 8-bit data type |
Date: |
Tue, 06 May 2003 10:29:12 -0700 |
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.