In Favor of Back End Gamma Correction
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:
We're not modeling reality, anyway, we're just going for a certain look.
Uncorrected renderings look "better" in simple subjective
Textures on surfaces come from images that are already in a
gamma-compressed space, and converting them to a linear space can
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
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.
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.
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
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.
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.