Encoding Gamma

That wraps up gamma correction on the decoding side of things, but what about encoders? After all, they must put the proper information into the PNG file in the first place, so that decoders can do their job correctly. The issue is more complex than for decoders, and not only because there are so many ways to generate an image. Consider the process of creating an image in an editor, which might seem the most straightforward case since it involves, in some sense, exactly the opposite procedure from that employed by the decoder. That is, the artist manipulates the image so that the displayed output has the desired appearance, then saves the result in a file with the proper gamma. Ordinarily, the editing application would simply write a gamma value that corresponds to the artist's display system. But if the image in question originated on another system, some editors will actually preserve its gamma setting by using a decoding_exponent for all manipulations on the artist's system--just as a normal viewer would. Thus the artist sees an image displayed in her own ``gamma space,'' but the underlying image samples actually remain in the gamma space of the original system.

The case of an electronic camera that writes image files directly turns out to be the simplest possibility; as noted earlier, the camera has its own transfer function and exponent, and the camera's manufacturer should know precisely what that exponent is. When the camera saves an image, whether in PNG format or something else, the proper gamma value is simply the one that will make the end-to-end product of exponents equal to the correct constant--which, you'll recall, is around 1.14 in the case of images captured in a TV studio environment and intended for display on a computer system. But even under different lighting conditions, the camera knows what the conditions are and can correct for them accordingly, perhaps via preset gamma settings for half a dozen situations, for example: dimly lit, flash-illuminated, studio lighting, sunny day (high contrast), bright cloudy day (lower contrast), and so on.

For images captured with a traditional camera and scanned from a print, the issue is slightly fuzzier. If the scanner writes directly to an image file with no user control of brightness and contrast, the case is exactly analogous to that of the electronic camera: the scanner manufacturer knows what its transfer function is and can encode the proper gamma value in the file. But most scanners operate in conjunction with editing software that allows the user to tweak not only gamma-related settings but also color balance and saturation; this case is more like the first one considered (regardless of whether the user considers himself an ``artist'').

Ironically, images that are generated completely artificially are the most complicated case. Most calculations on artificial scenes, including those for VRML and ray-traced worlds, are done with ``linear lighting'' that would correspond to a gamma of 1.0. But in creating the scene, the artist usually makes adjustments based on how it displays on her system, and if she happens to use a viewer that performs no gamma correction, her feedback to the software that generates the images will be skewed--in effect, she will modify the colors, textures, lighting, and so forth, so that the gamma value corresponds to her display system. The solution, of course, is to use only software that supports gamma correction, both for generating the images and for viewing them.