by Gregory Ward Larson, Silicon Graphics,
Inc.
by Gregory Ward Larson, Silicon Graphics,
Inc.
We have introduced a new photometric type for accurate, high dynamic range images within TIFF. We hope this will eventually become an official part of the central TIFF specification, since it fills an important gap in image storage and manipulation for global illumination, rendering and high-end digital photography.
Most image encodings use 8 bits for each of three primaries, RGB or YCrCb. This leads to a severe restriction in the recordable dynamic range of about 2 orders of magnitude. Other formats have been introduced, but they fare little better in terms of dynamic range. Even Pixar's 33-bit/pixel log format only covers about 3.5 orders of magnitude. This is good enough for most film applications, but still pales compared to the visible range of real-world luminance values.
Color is another problem. None of the popular image formats is able to record the full gamut of visible colors. To do so, one would either have to encode negative primary values, or use imaginary primaries, as in the CIE color systems. One attempt to overcome this limitation is the CIE Lab photometric type defined within TIFF. Unfortunately, since this system encodes the luminance channel in 8 bits, this encoding results in visible luminance steps over its limited dynamic range. Also, due to the way the encoding was written, it does not cover the full gamut.
Another solution is to encode standard RGB values as float triples. This is already allowed in the existing TIFF specification. The trouble with this approach is that each pixel would then take up 96 bits -- a quadrupling of image size! Since floating point values do not compress well due to their poor entropy characteristics, this results in a very inefficient encoding in terms of file space.
In our implementation of full-range pixels, we have arrived at the following uncompressed encoding based on the CIE Luv perceptually uniform color system:
This is the uncompressed 48-bit/pixel format, which will likely never be used.
Space requirements are reduced in the SGILOG compression codec by using the valid range of CIE (u',v') chromaticities and accepting some loss in color resolution. This reduces the encoding requirements of ue and ve to 8 bits each, for a total pixel size of 32 bits. Run-length encoding reduces space requirements further. Each of four bytestreams is encoded separately. Since the upper byte of log luminance changes very slowly, this usually compresses well, and the total image size is less than an uncompressed RGB image, and sometimes even less than a LZW-compressed one.
The usable dynamic range of the 32-bit/pixel compressed format is 38 orders of magnitude in 0.3% luminance steps. Color differences are imperceptible, and the full gamut of visible colors is included. Even supersaturated colors like laser illumination can be represented in this format.
A smaller, 24-bit/pixel compression is also available, called SGILOG24. This covers about 5 orders of magnitude in 1.1% luminance steps. These steps are still imperceptible, but can become perceptible under certain image transformations. The color resolution is also not quite as good, though it uses an indexing scheme over the visible gamut to optimize the encoding. Since this compression is not run-length encoded, it may actually end up larger than the 32-bit/pixel encoding in some cases.
In addition, there is a special photometric type for luminance-only (grayscale) images that compresses to less than 16 bits/pixel. There is actually little necessity for this type since the run-length encoded 32-bit/pixel format is not much larger than the 16-bit/pixel format when applied to grayscale input, but it is provided to make it explicit when there is no color information.
The SGILOG codec talks to the application in one of four basic data formats:
The desired data format is set with the codec pseudotag SGILOGDATAFMT after the file is opened and SGILOG or SGILOG24 compression is set or determined. (Note that files opened for read-only may still have their pseudotags and certain other fields changed.)
One of the benefits of having a dynamic range format is that it becomes possible to store calibrated data. Absolute data calibration may be useful in design applications where the actual luminance values relate to visual performance. Tone-mapping functions may use absolute levels to decide how to display an image in order to reproduce visibility. To accomplish either of these goals, the pixel data must be calibrated in physical units.
In this version of the TIFF library, we introduce a new global tag called StoNits, which is a 64-bit IEEE double value indicating the number of candelas/meter^2 corresponding to a decoded Y value of 1.0.
There are three reasons for setting the StoNits value rather than always storing absolute values in the file. First, the presence of this tag indicates that absolute values are known. (Often, they are not.) Second, the dynamic range of the encoded data, though large, is not infinite. Especially in the case of the SGILOG24 compression, there is not enough headroom to cover any physical value one might encounter, so getting the pixels into the proper range first is a good idea. Third, display is made much simpler if the stored values are already scaled by some factor to bring most pixels into a 0.01-1 range. In particular, if the application requests 8-bit/primary data from the codec (by requesting SGILOGDATAFMT_8BIT or using the TIFFRGBAImage routines), there is no sophisticated tone-mapping operation to bring all values into a displayable range. If the values don't start out with a good exposure value, the image will appear too bright or too dark when naive applications attempt to display it.
To a basic TIFF reader, one needs to add the following code fragment to interpret the new format as XYZ data. When interpreting file tags during initialization:
if (!TIFFGetField(tif, TIFFTAG_COMPRESSION, &comp))
comp = COMPRESSION_NONE;
if (!TIFFGetFieldDefaulted(tif, TIFFTAG_PHOTOMETRIC, &phot))
quiterr("TIFF has unspecified photometric type");
switch(phot) {
case PHOTOMETRIC_LOGLUV:
case PHOTOMETRIC_LOGL: /* include only if prepared for Y-only data */
if (comp != COMPRESSION_SGILOG && comp != COMPRESSION_SGILOG24)
quiterr("Only support SGILOG compressed LogLuv data");
TIFFSetField(tif, TIFFTAG_SGILOGDATAFMT, SGILOGDATAFMT_FLOAT);
break;
/* ...other supported photometric types */
default:
quiterr("TIFF has unsupported photometric type");
}
if (!TIFFGetField(tif, TIFFTAG_STONITS, &stonits))
stonits = 1.; /* should record illegal value? */
Later, data is read in the usual fashion, except that the buffers point to float arrays with three floats allocated per pixel. Data will be interleaved (PLANARCONFIG_CONTIG) with this codec, so it is not necessary to include a case for separate data planes. To get to absolute physical units (in candelas/meter^2), simply multiply the XYZ pixels by the stonits field recorded above.
Obviously, if the photometric type is LOGL, be prepared to receive only Y data.
To a standard TIFF writer, one needs to add the following code fragment to the initialization routine to set up for sending XYZ data:
TIFFSetField(tif, TIFFTAG_COMPRESSION, COMPRESSION_SGILOG); TIFFSetField(tif, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_LOGLUV); TIFFSetField(tif, TIFFTAG_PLANARCONFIG, PLANARCONFIG_CONTIG); TIFFSetField(tif, TIFFTAG_SGILOGDATAFMT, SGILOGDATAFMT_FLOAT); TIFFSetField(tif, TIFFTAG_STONITS, stonits); /* if known */
Later, data is written in the usual fashion, except that each pixel is represented by an XYZ float triple.
A complete conversion program to and from Radiance RGBE and XYZE formats is included in the following archive:
We have collected over 100 high dynamic-range images using this new format. Most come from Radiance renderings, but a few were taken from the radiance map work of Paul Debevec and Jitendra Malik. We hope that you will use this information to test out tone-mapping algorithms and high dynamic range displays. Please ask permission before publishing any of these images elsewhere, and give proper credit to the image author(s).