In Favor of Back End Gamma Correction

Greg Ward Larson, Silicon Graphics, Inc.
Holly Rushmeier, IBM T.J. Watson Research Center

A proposal has been made by the VRML Color Fidelity Working Group to make rendering VRML models in a pre-compensated color space an ISO standard. This goes against common wisdom in computer graphics, which regards the standard rendering equation, modified only slightly in VRML, to be a linear combination of illumination terms. A linear sum of terms corresponds more closely to physical reality than the same equation raised to a power, as implied by a pre-compensated color space. Even if terms in the equation are not absolutely correct, they are at least an attempt to mimic reality, whereas a pre-compensated rendering equation cannot possibly achieve high fidelity illumination gradients. Our basic defense of traditional CG gamma correction boils down to the following:

Q: Why should we render our VRML models in a linear color space?
A: Because VRML stands for "Virtual Reality Modeling Language," and reality uses a linear color space.

There have been at least four arguments in favor of rendering VRML models in a gamma-compressed color space. These arguments are summarized below, followed by our rebuttal to each point. Finally, we offer what we feel are some compelling arguments in favor of doing proper back end gamma correction in VRML browsers.

Arguments for rendering VRML models in a gamma-compressed color space:

1. We're not modeling reality, anyway, we're just going for a certain look.
2. Uncorrected renderings look "better" in simple subjective tests.
3. Textures on surfaces come from images that are already in a gamma-compressed space, and converting them to a linear space can introduce banding.
4. PC-compatible 3D acceleration boards don't have the necessary gamma look-up tables to do gamma correction right.

Rebuttals to arguments in favor of rendering VRML in a gamma-compressed color space:

1. Even if VRML browsers make no attempt to model reality (and we believe they should), other software that has been around a lot longer does, and we want to convert to and from these other systems. For an example of what happens when importing a gamma-2.2 VRML model into a standard rendering/animation system, see the following web page.
2. The subjective tests conducted so far have been based on very simple geometry and lighting, and did not consider anything other than pure preference -- there were no comparisons to real scenes or accurate renderings. For an example of the differences between rendering with and without gamma correction, see the following web page.
3. Banding may be introduced if the linear color space holds only 8 bits/primary, which is a function of the hardware and the software involved, not VRML or image standards themselves. Banding of texture images is very difficult to see, as textures tend to be fairly "busy" and don't have smooth, dark gradients where banding may show.
4. There are only a few PC-compatible cards on the market, and there is no reason they shouldn't improve in the future to include gamma correction, which would provide some needed product differentiation. Even without it, per-vertex gamma correction can be done inexpensively in software, producing approximately correct renderings on output. Combining this with gamma-compressed texture images produces results that are nearly identical to per-pixel gamma-corrected renderings.

Arguments in favor of back end VRML gamma correction:

• The rendering equation was never meant to be raised to a power. (See the following web page for a complete specification of the VRML lighting equation.) Taking the results of the equation and sending them directly to an uncompensated CRT is effectively the same as raising the output to a power of about 2.5. Although the equation starts out as a linear sum of terms, raising it to a power yields cross-terms between various components, such as specular versus diffuse and light A versus light B. Clearly, this is a non-physical result, implying the contribution of one component influences the contribution of another. More importantly, light falls off as the fifth power of distance, and as the 2.5 power of the cosine of the angle to the surface, both of which are nonsense.
• Different display devices have different gamma response curves. Although most properly adjusted CRT monitors have similar response curves, they aren't exactly the same, and CRT display devices are losing market share as high performance flat screen technologies take over. Even today, laptop computers use LCD displays that exhibit little if any non-linearity in their response functions, and they must be compensated differently than traditional CRT displays. If gamma correction is ignored by the graphics hardware, and no software compensation is applied, there will be no way to obtain consistent results on these increasingly common devices. Even if the standard specifies a 2.2 gamma response, the fact that gamma correction hardware is not required on the more mature CRT systems makes its inclusion in LCD display hardware very unlikely.
• There is a whole world of rendering software that currently does gamma correction properly, and to create a new standard that is inconsistent with this existing base is ill-advised. If anything, VRML browsers should be insisting on proper gamma correction in their rendering back end, so that models shared with these other systems will look the same. Not everything is created in VRML editors on PC's. Most content comes from other sources, or will be shared with other rendering software, eventually.
• Scientific visualization is an emerging market for VRML. Most SciViz systems currently do gamma correction in their renderings, even though they care very little about modeling real surfaces and reflection. Exporting these models to a VRML browser that neglects gamma correction results in different colors and shading. Even if the colors are recomputed in a gamma-compressed space, the lighting may be different enough that elements visible in the original model will become invisible in the VRML browser. This is not an acceptable result, and there is no way to compensate for changes in lighting without user intervention. See the following web page for more information and examples.

Although it's true that a gamma-compressed space has been the standard for image viewing for many years, encoding images is entirely different from encoding 3D geometry and materials. People working in 3D CG rendering have always used a linear color space, and with good reason -- it is a better approximation of physical lighting. Altering the standard CG lighting model would introduce new kinds of incompatibilities between different rendering systems, making data sharing unnecessarily difficult and promoting graphics hardware that neglects an important part of the rendering pipeline.

The first goal of the Color Fidelity Working Group should be fidelity to physical coloration. The physical world is, after all, everyone's standard for reality.