The LogLuv Encoding for Full Gamut,

High Dynamic Range Images

Gregory Ward Larson

Silicon Graphics, Inc.
Mountain View, California

Abstract colors. This is due to the imperfect separation of luminance

The human eye can accommodate luminance in a single and chrominance, and the limited gamut of a non-negative
view over a range of about 10,000:1 and is capable of RGB color space.
distinguishing about 10,000 colors at a given brightness. By In this paper, we present a new pixel encoding that uses
comparison, typical computer monitors have a luminance a log representation of luminance and a CIE (u’,v’)
range less than 100:1 and cover about half of the visible representation of chrominance.* We call this a LogLuv
color gamut. Despite this difference, most digital image encoding. This encoding has the following desirable
formats are geared to the capabilities of conventional properties. It:
displays, rather than the characteristics of human vision. In • Covers the entire visible color gamut.
this paper, we propose a compact encoding suitable for the • Covers the full range of perceivable luminances (over
transfer, manipulation, and storage of high dynamic range 38 orders of magnitude).
color images. This format is a replacement for conventional
RGB images, and encodes color pixels as log luminance • Uses imperceptible step sizes in a perceptually
values and CIE (u',v') chromaticity coordinates. We have uniform space.
implemented and distributed this encoding as part of the • May be calibrated to absolute luminance and color.
standard TIFF I/O library available by anonymous ftp. After
• Enables optimal visual fidelity on any output device.
explaining our encoding, we describe its use within TIFF
and present some techniques for handling high dynamic In addition to these inherent features, we have the
range pixels, and demonstrate with an example image. following technical goals for our format. We would like it
to be:
1. Introduction • Compact.
• Compressible.
Recently, there has been increased interest in high
dynamic range (HDR) images, both captured and synthetic • Easy to convert to XYZ and RGB formats.
[Debevec 97] [Ward 94], which permit extended processing • Incorporated into the TIFF standard.
and higher fidelity display methods [Debevec 98] In this paper, we describe our LogLuv pixel encoding
[Larson 97] [Pattanaik 98]. Conventional 24-bit RGB method, followed by a description of our extension to Sam
formats cannot encode this additional information, and Leffler’s free TIFF library. We then discuss some practical
simple floating point extensions require too much storage considerations, and give an example application to HDR
space. Some formats, used in the digital film industry, tone mapping, ending with a brief conclusion.
extend the dynamic range slightly using a logarithmic RGB
space. Pixar has been using a 33-bit/pixel log format for 2. Encoding Method
years, which covers 3.5 orders of magnitude with 0.4%
accuracy. Cineon has a 30-bit/pixel log format, but it only We have actually implemented two LogLuv pixel encodings,
covers about 2 orders of magnitude, depending on the type a 24-bit encoding and a 32-bit encoding. The 24-bit
of film being scanned. Another solution, employed in the encoding breaks down into a 10-bit log luminance portion
Radiance rendering system, is to append 8 bits to each pixel and a 14-bit, indexed uv coordinate mapping. The 32-bit
to represent a common exponent for three 8-bit RGB
mantissas [Ward 91]. This provides over 77 orders of *
magnitude in dynamic range, and works well for the Chrominance is the quantity equivalent to hue plus
majority of images, but can produce visible quantization saturation. We follow conventional CIE usage by using
artifacts and gamut clamping for some highly saturated “color” and “chrominance” interchangeably, though the
latter is properly a subset of the former [Wyszecki82].
encoding uses 16 bits for luminance and 8 bits each for u’ 9y
and v’. Compared to the 24-bit encoding, the 32-bit version v' = (3b)
provides greater dynamic range and precision at the cost of −2 x + 12 y + 3
an extra byte per pixel. Also, the 32-bit format is simpler
and compresses better, such that most 32-bit LogLuv images 9u'
end up smaller than their 24-bit counterparts. Therefore, we x= (4a)
will not discuss the 24-bit encoding in this article, but refer 6u' − 16v ' + 12
the reader to the original paper for details [Larson 98].
4v '
2.1 32-bit LogLuv Pixel Encoding y= (4b)
The 32-bit LogLuv encoding uses 16 bits for luminance 6u' − 16v ' + 12
information and 16 bits for chrominance. The MSB is used
to flag negative luminances, and the next 15 bits record up where:
to 38 orders of magnitude in 0.27% relative steps, covering x = X/(X+Y+Z)
the full range of perceivable world luminances in y = Y/(X+Y+Z)
imperceptible steps. The lower two bytes encode u’ and v’,
respectively. The bit breakdown is shown in Fig. 1.
± Le ue ve 3. TIFF Input/Output Library

The LogLuv encoding described has been embedded as a

Figure 1. Bit allocation for 32-bit pixel encoding. MSB is a sign new SGILOG compression type in Sam Leffler’s popular
bit, and the next 15 bits are used for a log luminance encoding. TIFF I/O library. This library is freely distributed by
The uv coordinates are separate 8-bit quantities. anonymous ftp at the site given at the end of this article.
The conversion to and from our log luminance encoding When writing a high dynamic range TIFF image, the
is given in Eq. 1. The maximum luminance using this LogLuv codec (compression/decompresson module) takes
encoding is 1.84×1019, and the smallest magnitude is floating point CIE XYZ scanlines and writes out 24-bit or
5.44×10-20. An Le value of 0 is taken to be exactly 0.0. The 32-bit compressed LogLuv-encoded values. When reading
sign bit is extracted before encoding and reapplied after the an HDR TIFF, the reverse conversion is performed to get
conversion back to real luminance. back floating point XYZ values. (We also provide a simple
conversion to 24-bit gamma-compressed RGB for the
Le =  256(log 2 Y + 64) (1a) convenience of readers that do not know how to handle
HDR pixels.)

[ ]
An additional tag is provided for absolute luminance
Y = exp 2 ( Le + 0.5) / 256 − 64 (1b) calibration, named TIFFTAG_STONITS.* This is a single
floating point value that may be used to convert Y values
Since the gamut of perceivable u and v values is returned by the reader to absolute luminance in candelas per
between 0 and 0.62, we chose a scale factor of 410 to go square meter. This tag is set by the application that writes
between our [0,255] integer range and real coordinates, as out a HDR TIFF to permit prescaling of values to a
given in Eq. 2. reasonable brightness range for display, where values of 1.0
will be displayed at the maximum output of the destination
ue =  410u' (2a) device. This avoids the image reader having to figure out a
good exposure level for absolute luminances. If the input
data is uncalibrated (i.e., the absolute luminances are
ve =  410v ' (2b) unknown), then there is no need to store this tag, whether the
values are scaled or not.
u' = (ue + 0.5) / 410 (2c)
3.1 Run-length Compression
By separating the bytes into four streams on each
v ' = (ve + 0.5) / 410 (2d) scanline, the 32-bit encoding can be efficiently compressed
using an adaptive run-length encoding scheme
This encoding captures the full color gamut in 8 bits each [Glassner 91]. Since the top byte containing the sign bit and
for ue and ve. There will be some unused codes outside the upper 7 log luminance bits changes very slowly, this byte-
visible gamut, but the tolerance this gives us of 0.0017 units stream submits very well to run-length encoding. Likewise,
in uv space is already well below the visible threshold. the encoded ue and ve byte-streams compress well over areas
Conversions to and from 1931 CIE (x,y) chromaticities are of constant chrominance.
given in Eqs. 3 and 4.

4x
u' = (3a) *
STONITS stands for “samples to Nits,” where “Nits” is the
−2 x + 12 y + 3 photometric unit for luminance, also written
candelas/meter2. Use of this tag will be discussed later in
section 5.2.
3.2 Grayscale Images
For maximum flexibility, a pure luminance mode is also R G B
provided by the codec, which stores and retrieves run-length x 0.640 0.300 0.150
encoded 16-bit log luminance values using the same scheme y 0.330 0.600 0.060
as applied in the 32-bit LogLuv encoding. There is no real
space savings over a straight 32-bit encoding, since the ue Table 1. CIE (x,y) chromaticities for CCIR 709 RGB primaries.
and ve byte-streams compress to practically nothing for
grayscale data, but this option provides an explicit way to X  0.497 0.339 0164
.   R
specify floating point luminance images for TIFF readers Y  = 0.256 0.678 0.066 G  (5)
that care.     
 Z  0.023 0.113 0.864  B 
3.3 Raw I/O
It is also possible to decode the raw 32-bit LogLuv data
retrieved from an HDR TIFF directly, and this has some 4.2 Luminance Calibration
advantages for implementing fast tone mapping and display If the image corresponds to a luminous scene (as
algorithms. For the 32-bit format, one can simply multiply opposed to a painting or other reflective media), it may be
the output of a 32 Kentry Le table and a 64 Kentry uv table possible to calibrate the recorded information using the
to get a tone-mapped and gamma-compressed RGB result, TIFFTAG_STONITS field mentioned earlier. This is a real
provided the tone mapping algorithm can separate multiplier that is stored with the image by whoever creates
chrominance from luminance. A explanation of how this is it. When reading an image, an application can retrieve this
done is given in Section 5.1. value and multiply it by each pixel’s Y value to get an
absolute luminance in cd/m2. If the absolute luminance for a
3.4 Example TIFF Code and Images given pixel or subimage is known by the TIFF writer, this
Use of the LogLuv encoding is demonstrated and sample multiplier is also known, since it equals the absolute
images are provided on our web site, which is given at the luminance divided by the output Y value. If, on the other
end of this article. A converter has been written to and from hand, we are working from a scan of a photographic
the Radiance floating point picture format [Ward 94] negative or transparency, it may be possible to approximate
[Ward 91], and serves as an example of LogLuv codec this multiplier from the image exposure time, f-stop and film
usage. The web site itself also offers programming tips and speed. For 35mm photography, we can use the formula
example code segments. given in Eq. 6, borrowed from the IES Handbook [IES 93].
Example TIFF images using the 32-bit LogLuv and
200
16-bit LogL encoding are provided on the web site. These m= ⋅f 2
t (6)
images are either scanned from photographic negatives or πS
rendered using Radiance and converted to the new TIFF
format. Some images are rendered as 360° QuickTime VR where:
panoramas suitable for experiments in HDR virtual reality. S = film speed (ISO ASA)
f = aperture (f-stop)
4. Practical Considerations t = exposure time (seconds)
There are several important considerations in applying the Eq. 6 assumes that the maximum image brightness
LogLuv image format, which we describe in this section. corresponds to a Y value of 1.0. For photographic
Issues such as conversion to and from RGB space require negatives, which hold about 2 orders of magnitude of
thought about dynamic range and gamut limitations, and extended dynamic range beyond white, we assume this
calibrated versus uncalibrated color spaces. We also discuss “maximum” corresponds to a density of about 1.5 (3%
speed and space efficiency issues, and appropriate filtering negative transmittance).
and image manipulation techniques.
4.3 Converting back to RGB
4.1 Converting from RGB to XYZ For the reverse conversion, we invert the matrix from
Ideally, the original image data is available in a real, Eq. 5 as shown in Eq. 7.
XYZ color space or a spectrally sampled color space that
can be converted to XYZ using standard CIE techniques  R  2.690 −1276. −0.414  X 
[Wyszecki 82]. However, most imaging devices and G  = −1022 0.044   Y 
 . 1978
. (7)
renderers are based on some RGB standard. To get from  
RGB into XYZ space, a simple 3×3 matrix transformation  B   0.061 −0.224 1163
.   Z 
may be computed from the CIE (x,y) chromaticities for the
three RGB primaries and a white point [Rogers 85]. Using Since some of the matrix coefficients are negative due to the
the standard CCIR 709 RGB primaries for computer larger gamut of the imaginary CIE primaries, the formula
displays and a neutral white point for optimal color balance, given in Eq. 7 may result in negative RGB values for some
we derive the color transformation shown in Eq. 5. highly saturated colors. If the image processing software
can cope with negative values, it is better to leave them that
way, otherwise a gamut mapping operation may be
performed to bring them back into the legal range. Much
research has been devoted to this problem [Stone 88], but TIFF RGB images. Since luminance and chrominance are
clamping is the most often applied solution. We have also placed in separate byte streams, regions where one or the
found desaturating to a face of the RGB cube to be a simple other are relatively constant compress very well. This is
and effective solution to limiting the color gamut. often the case in computer graphics imagery, which will
If floating point RGB colors are maintained without compress between 15% and 60% for reasonably complex
gamut limiting (i.e., negative values allowed), it is possible scenes, and will often outperform LZW compression so
to go from LogLuv→RGB→LogLuv without losing data. much that the resulting file size is actually smaller than the
However, the opposite is not true, since the LogLuv LZW-compressed 24-bit RGB version. For scanned
encoding quantizes data into perceptual bins. Even in the imagery, the performance is usually not as good using run-
case of integer RGB data, there will be some differences due length encoding due to the increased complexity and image
to the binning used by the two encodings. noise. However, we never grow the data, as can happen
with the LZW compression algorithm, which is sometimes
4.4 RGB→ →LogLuv→ →RGB Information Loss worse than no compression at all.
Even though the gamut and dynamic range of the 32-bit For example, compression performance for the scene
LogLuv format is superior to that of 24-bit RGB, we will not shown in Fig. 2 is -8% for LZW compression, compared to
get the exact pixel values again if we go through this format 13% for our run-length encoding. The LZW file still ends
and back to RGB. This is because the quantization size of a up slightly smaller since it is starting from 24-bit pixels, but
LogLuv pixel is matched to human perception, whereas our compressed result has an additional advantage, which is
24-bit RGB is not. In places where human error tolerance is lower entropy. Specifically, we can apply an entropy
greater, the LogLuv encoding will have larger quantization encoding scheme to our run-length encoded result, and pick
volumes than RGB and therefore may not reproduce exactly up some additional savings. For the same figure, applying
the same 24-bit values when going back and forth. Over the gzip program to the result gains an additional 17%
most of the gamut, the LogLuv tolerances will be tighter, compression, making the resulting file smaller than the
and RGB will represent lower resolution information. (This straight LZW encoding. (Applying gzip to the LZW file
is especially true for dark areas.) In other words, the losses only reduces its size by 4%, which is not enough to make up
incurred going through the LogLuv format may be the difference.) In most cases, applying gzip to our run-
measurable in absolute terms, but they should not be visible length encoded 32-bit LogLuv TIFF yields a file that is
to a human observer since they are below the threshold of within a 10% of a gzip’ped 24-bit RGB file, which is almost
perception. always smaller than TIFF’s blockwise LZW compression.
We performed two tests to study the effects of going
between RGB and LogLuv formats, one quantitative test and 4.6 Image Processing
one qualitative test. In the quantitative test, we went through There are two basic approaches for processing LogLuv
all 16.7 million 24-bit RGB colors and converted to 32-bit encoded images. One method is to convert to a floating-
LogLuv and back, then measured the difference between the point RGB or XYZ color space and perform image
input and output RGB colors using the CIE E* perceptual manipulations on these quantities. This is probably the
error metric. We found that 17% of the colors were simplest and most convenient for general purposes. The
translated exactly, 80% were below the detectable threshold other method is to work directly in a separate luminance
and 99.75% were less than twice the threshold, where space such as Yuv or Yxy. For certain types of image
differences may become noticeable. In our qualitative test, processing, such as contrast and brightness adjustment, it
we examined a dozen or so images from different sources, may actually be faster since we can work on the Y channel
performing the RGB→LogLuv→RGB mapping in alone, plus we save a little time on our conversions.
interleaved 16 scan-line stripes that roughly corresponded to In general, it is not a good idea to convert to an
the maximum visible angular frequency. In this way, we 8-bit/primary integer space to manipulate high dynamic
hoped to notice the underlying pattern in cases where the range images, because the dynamic range is lost in the
translation resulted in visible differences. In all of the process. However, since most existing hardware and
captured images we looked at, the details present completely software is geared to work with 24-bit RGB data, it may be
obscured any differences caused by the translation, even in easiest to use this format for interactive feedback, then apply
sky regions that were relatively smooth. Only in one the manipulation sequence to the floating point data when
synthesized image, which we designed very carefully to have writing the file. Better still, one could use the approach
smooth gradients for our tests, were we just barely able to adopted by some software packages and store the sequence
discern the pattern in large, low detail regions. Even so, we of image processing commands together with the original
had to really be looking for it to see it, and it sort of faded in data. These commands may be recorded as additional TIFF
and out, as if the eye could not decide if it was really there tags and attached to the file without even touching the data.
or not. Besides saving time, this approach also preserves our
From these tests, we concluded that the differences absolute luminance calibration, if TIFFTAG_STONITS is
caused by taking RGB data through the LogLuv format will present.
not be visible in side-by-side comparisons. Compositing high dynamic range images using an alpha
channel is also possible, though one must consider the effect
4.5 LogLuv Image Compression of multiplying a floating point value by an integer value.
The simple adaptive run-length encoding scheme used When one is small and the other is large, the result may
to compress our 32-bit/pixel LogLuv format performs about either be wrong or show severe quantization artifacts.
as well on average as the LZW scheme used on standard Therefore, it is best to use a high dynamic range alpha
channel, which may be stored as a separate 16-bit LogL where:
TIFF layer. Lt, Rt, Gt, Bt = lookup table values
An additional benefit of the 32-bit LogLuv and 16-bit Le = encoded log luminance
LogL formats is that pixels may take on negative values, Ce = encoded uv color
which are useful for arbitrary image math and general Ld(Le) = mapped display luminance
masking and filtering. For example, an image may be
R1, G1, B1 = normalized color mapping
broken into separate 2D Fourier frequency layers, which
when summed together yield back the original image. The γ = monitor response gamma
coefficients for these layers may then be tuned Sr, Sg, Sb = red, green, blue coefficients
independently or manipulated in arbitrary ways. This is from middle row of Eq. 5 matrix
usually done in memory, such that the written file format Sr⋅R1(Ce) + Sg⋅G1(Ce) + Sb⋅B1(Ce) = 1
pays little part, but being able to write out the intermediate
pixel data without losing information has potential The color coefficients guarantee that all tabulated
advantages for subsequent processing. chrominance values will be between 0 and 255. To get from
the separately tabulated luminance and chrominance to
5. Motivating Application: Tone Mapping display values in the 0-255 range, we apply the formulas
given in Eq. 9.
Tone mapping is the process of mapping captured
image values to displayed or printed colors [Tumblin93]. Rd = Lt ( Le ) Rt (Ce ) /  256 Sr 1/γ  (9a)
With the added dynamic range and gamut provided by our
new encoding, we can get a much better mapping than we
could with the limited range of conventional digital images. Gd = Lt ( Le ) Gt (Ce ) /  256 S g 1/γ  (9b)
If our data is also calibrated (i.e., STONITS has been set by
the creating application), then we can go further to simulate
visibility using what we know about human color and Bd = Lt ( Le ) Bt (Ce ) /  256 Sb 1/γ  (9c)
contrast sensitivity. Recently, a number of tone mapping
techniques have been developed for images with high
Since the denominators in Eq. 9 are constant, they can be
dynamic range [Pattanaik 98] [Spencer 95] [Chiu 93]
precomputed, leaving only four table lookups, three integer
[Jobson 97]. Most of these methods introduce image-
geometric dependencies, so they cannot be applied multiplies and three integer divides to map each pixel.
independently to each pixel, or computed using integer We have implemented this type of integer-math tone-
math. In this section, we present an efficient tone-mapping mapping algorithm in an HDR image viewer, and it takes
technique for HDR images that can be applied on a pixel-by- less than a second to convert and display a 512×512 picture
pixel basis using integer operations [Larson97]. on a 180 MHz processor. The Le table size is determined by
the range of luminances present in the image, and only the
5.1 Efficient Tone Mapping colors needed are actually translated to RGB and stored in
As we mentioned earlier in Section 3.3, we can go the uv lookup table. We used the high dynamic range
directly from the luminance and uv image data to an RGB operator described in [Larson 97], which requires a
tone-mapped result by multiplying the output of two lookup modification to our algorithm to include mesopic color
tables. To get the math to work out right, both the correction, since it relates the luminance and color
luminance and uv table values must be in the monitor’s mappings. For pixels below the upper mesopic limit, we
gamma-compressed space, and the RGB values must be determine the color shift in uv coordinates, then do our table
premultiplied by their corresponding luminance coefficients. lookup on the result.
The computation for luminance and RGB table entries
corresponding to specific tone-mapped display colors is 5.2 Example Results
given in Eq. 8. Fig. 2a shows a scanned photograph as it might appear on a
PhotoCD using a YCC encoding. Since YCC can capture
Lt ( Le ) = 256 Ld ( Le )1/γ  (8a) up to “200% reflectance,” we can apply a tone mapping
operator to bring this extra dynamic range into our print, as
shown in Fig. 3a. However, since many parts of the image
(
Rt (Ce ) = 256 S r R1 (Ce ) ) 
1/ γ
were brighter than this 200% value, we still lose much of the
(8b)
  sky and circumsolar region, and even the lighter asphalt in
the foreground. In Fig. 2b, we see where 35% of the
original pixels are outside the gamut of a YCC encoding.
(
Gt (Ce ) = 256 S g G1 (Ce ) ) 
1/ γ
(8c)
 

(
Bt (Ce ) = 256 Sb B1 ( Ce ) ) 
1/γ
(8d)
 
 Figure 2. The left image (a) shows a PhotoYCC encoding of a Figure 4. The upper-left image (a) shows the circumsolar region
color photograph tone-mapped with a linear operator. The right reduced by 4 f-stops to show the image detail recorded on the
image (b) shows the out-of-gamut regions. Red areas are too negative. The lower-left image (b) shows house details boosted by
bright or too dim, and green areas have inaccurate color. 3 f-stops. The right image (c) shows our HDR TIFF mapped with
Fig. 3b shows the same color negative scanned into our the Pattanaik-Ferwerda tone operator.
32-bit/pixel high dynamic range TIFF format and tone
mapped using a histogram compression technique 5.3 Discussion and Other Applications
[Larson 97]. Fig. 4c shows the same HDR TIFF remapped It is clear from our example that current methods for
using the perceptual model of Pattanaik et al [Pattanaik 98]. tone-mapping HDR imagery, although better than a simple
Figs. 4a and 4b show details of light and dark areas of the S-curve, are less than perfect. It would therefore be a
HDR image whose exposure has been adjusted to show the mistake to store an image that has been irreversibly tone
detail captured in the original negative. Without an HDR mapped in this fashion, as some film scanner software
encoding, this information would be lost. attempts to do. Storing an HDR image allows us to take full
advantage of future improvements in tone mapping and
display algorithms, at a nominal cost.
Besides professional film and photography, there are a
number of application areas where HDR images are key.
One is lighting simulation, where designers need to see an
interior or exterior space as it would really appear, and
evaluate things in terms of absolute luminance and
illuminance levels. Since an HDR image can store the real
luminance in its full-gamut coverage, this information is
readily accessible to the designer. Another application is
image-based rendering, where a user is allowed to move
about in a scene by warping captured or rendered images
[Debevec 96]. If these images have limited dynamic range,
it is next to impossible to adapt the exposure based on the
current view, and impossible to use the image data for local
. lighting. Using HDR pixels, a natural view can be provided
for any portion of the scene, and the images may also be
Figure 3. The left image(a) shows the YCC encoding after used to illuminate local objects [Debevec 98]. A fourth
remapping with a histogram compression tone operator. application area is digital archiving, where we are making a
Unfortunately, since YCC has so little dynamic range, most of the high-quality facsimile of a work of art for posterity. In this
bright areas are lost. The right image (b) shows the same case, the pixels we record are precious, so we want to make
operator applied to a 32-bit HDR TIFF encoding, showing the full sure they contain as much information as possible. At the
dynamic range of the negative. same time, we have concerns about storage space and
transmission costs, so keeping this data as compact as
possible is important. Since our HDR format requires little
more space than a standard 24-bit encoding to capture the
full visible gamut, it is a clear winner for archiving
applications.
Our essential argument is that we can make better use of
the bits in each pixel by adopting a perceptual encoding of
color and brightness. Although we don’t know how a given
image might be used or displayed in the future, we do know
something about what a human can observe in a given scene.
By faithfully recording this information, we ensure that our Range Photography,” Computer Graphics (Proceedings of
image will take full advantage of any future improvements in ACM Siggraph 98).
imaging technology, and our basic format will continue to [Debevec 97] Paul Debevec, Jitendra Malik, “Recovering
find new uses. High Dynamic Range Radiance Maps from Photographs,”
Computer Graphics (Proceedings of ACM Siggraph 97).
6. Conclusion [Debevec 96] Paul Debevec, Camillo Taylor, Jitendra Malik,
“Modeling and Rendering Architecture from Photographs:
We have presented a new method for encoding high A hybrid geometry- and image-based approach,” Computer
dynamic range digital images using log luminance and uv Graphics (Proceedings of ACM Siggraph 96).
chromaticity to capture the entire visible range of color and [Glassner 91] Andrew Glassner, “Adaptive Run-Length
brightness. The proposed format requires little additional Encoding,” in Graphics Gems II, edited by James Arvo,
storage per pixel, while providing significant benefits to Academic Press, (1991).
suppliers, caretakers and consumers of digital imagery. [IES 93] Illuminating Engineering Society of North America, IES
This format is most appropriate for recording the output Lighting Handbook, Reference Volume, IESNA (1993).
of computer graphics rendering systems and images [Jobson 97] Daniel Jobson, Zia-ur Rahman, and Glenn A.
captured from film, scanners and digital photography. Woodell. “Properties and Performance of a
Virtually any image meant for human consumption may be Center/Surround Retinex,” IEEE Transactions on Image
better represented with a perceptual encoding. Such Processing, Vol. 6, No. 3 (March 1997).
encodings are less appropriate when we either wish to store [Larson 98] Greg Larson, “Overcoming Gamut and
non-visual (or extravisual) information as found in satellite Dynamic Range Limitations in Digital Images,” Color
imagery, or output to a specific device with known Imaging Conference, Scottsdale, Arizona (1998).
characteristics such as NTSC or PAL video. [Larson 97] Greg Larson, Holly Rushmeier, Christine
Through the use of re-exposure and dynamic range Piatko, “A Visibility Matching Tone Reproduction
compression, we have been able to show some of the Operator for High Dynamic Range Scenes,” IEEE
benefits of HDR imagery. However, it is more difficult to Transactions on Visualization and Computer Graphics, 3,
illustrate the benefits of a larger color gamut without 4, (1997).
carefully comparing hard copy output of various multi-ink [Pattanaik 98] Sumant Pattanaik, James Ferwerda, Mark
printers. Also, since we currently lack the ability to capture Fairchild, Don Greenberg, “A Multiscale Model of
highly saturated scenes, our examples would have to be Adaptation and Spatial Vision for Realistic Image
contrived from individual spectral measurements and Display,” Computer Graphics (Proceedings of Siggraph
hypothetical scenes. We therefore leave gamut validation as 98).
a future exercise. [Rogers 85] David Rogers, Procedural Elements for
Future work on the format itself should focus on the Computer Graphics, McGraw-Hill, (1985).
application of lossy compression methods for HDR images [Spencer 95] G. Spencer, P. Shirley, K. Zimmerman, and D.
and animations. A JPEG-like cosine transform should work Greenberg, “Physically-based glare effects for computer
very well, since LogLuv looks almost the same perceptually generated images,” Computer Graphics (Proceedings of
as the gamma-compressed YCbCr coordinates that JPEG Siggraph 95).
uses. Efficient compression is needed for broad acceptance [Stone 88] Maureen Stone, William Cowan, John Beatty,
of HDR imagery and extensions for digital cinema.
“Color Gamut Mapping and the Printing of Digital Color
Images,” ACM Transactions on Graphics, 7(3):249-292,
7. Acknowledgments
(October 1988).
[Tumblin93] Tumblin, Jack and Holly Rushmeier. “Tone
The author would like to thank Sam Leffler for his help and
Reproduction for Realistic Images,” IEEE Computer
cooperation in adding these routines to the TIFF i/o library,
Graphics and Applications, November 1993, 13(6).
Dan Baum for his support and encouragement, Paul
[Ward 94] Greg Ward, “The RADIANCE Lighting
Haeberli, Christopher Walker and Sabine Susstrunk for their
Simulation and Rendering System,” Computer Graphics
advice, and Alexander Wilkie, Philippe Bekaert and Jack
(Proceedings of Siggraph 94).
Tumblin for testing the software. Finally, thanks to Ronen
[Ward 91] Greg Ward, “Real Pixels,” in Graphics Gems
Barzel for his many helpful comments and suggestions on
II, edited by James Arvo, Academic Press, (1991).
the paper itself.
[Wyszecki 82] Gunter Wyszecki, W.S. Stiles, Color Science:
Concepts and Methods, Quantitative Data and Formulae,
8. References Second Edition, Wiley, (1982).

[Chiu 93]K. Chiu, M. Herf, P. Shirley, S. Swamy, C. Wang and K. 9. Web Information
Zimmerman “Spatially nonuniform scaling functions for
high contrast images,” Proceedings of Graphics Interface Links to Sam Leffler’s TIFF library, example LogLuv
'93, Toronto, Canada, (May 1993). images and other information may be found at:
[Debevec 98] Paul Debevec, “Rendering Synthetic Objects http://www.acm.org/jgt/papers/Larson99
into Real Scenes: Bridging Traditional and Image-Based
Greg may be reached by e-mail at [email protected].
Graphics with Global Illumination and High Dynamic