[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-devel] 16-bit unsigned integer
From: |
Florian Kainz |
Subject: |
Re: [Openexr-devel] 16-bit unsigned integer |
Date: |
Tue, 15 Jul 2003 11:25:22 -0700 |
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.