A note on gamma correction and images
Graeme W. Gill
16 May 1993
What is all this gamma stuff anyway?
Although it would be nice to think that "an image is an image", there are a
lot of complications. Not only are there a whole bunch of different image
formats (gif, jpeg, tiff etc etc), there is a whole lot of other technical
stuff that makes dealing with images a bit complicated. Gamma is one of those
things. If you've ever downloaded images from BBS or the net, you've probably
noticed (with most image viewing programs) that some images look ok, some look
too dark, and some look too light. "Why is this ?" you may ask. This, is
gamma correction (or the lack of it).
Why do we need gamma correction at all?
Gamma correction is needed because of the nature of CRTs (cathode ray tubes -
the monitors usually used for viewing images). If you have some sort of real
live scene and turn it into a computer image by measuring the amount of light
coming from each point of the scene, then you have created a "linear" or
un-gamma-corrected image. This is a good thing in many ways because you can
manipulate the image as if the values in the image file were light (ie. adding
and multiplying will work just like real light in the real world).
Now if you take the image file and turn each pixel value into a voltage
and feed it into a CRT, you find that the CRT _doesn't_ give you
an amount of light proportional to the voltage. The amount of light
coming from the phosphor in the screen depends on the the voltage
something like this:
Light_out = voltage ^ crt_gamma
So if you just dump your nice linear image out to a CRT, the image
will look much too dark. To fix this up you have to "gamma correct"
the image first. You need to do the opposite of what the CRT
will do to the image, so that things cancel out, and you get
what you want. So you have to do this to your image:
gamma_corrected_image = image ^ (1/crt_gamma)
For most CRTs, the crt_gamma is somewhere between 1.0 and 3.0.
If that is all it is, why does it seem so complicated?
The problem is that not all display programs do gamma correction.
Also not all sources of images give you linear images (Video cameras
or video signals in general). Because of this, a lot of images
already have some gamma correction done to them, and you are
rarely sure how much. If you try and display one of those images
with a program that does gamma correction for you, the image gets
corrected twice and looks way to light. If you display one of those
images with a program that doesn't do gamma correction, then it will
look vaguely right, but not perfect, because the gamma correction is
not exactly right for you particular CRT.
Whose fault is all this?
It is really three things. One is all those display programs
out there that don't do gamma correction properly. Another is
that most image formats don't specify a standard gamma, or
don't have some way or recording what their gamma correction is.
The third thing is that not many people understand what gamma
correction is all about, and create a lot of images with varying
At least two file formats do the right thing.
The Utah Graphics Toolkit .rle format has a semi-standard way of recording
the gamma of an image. The JFIF file standard (that uses JPEG compression)
specifies that the image to be encoded must have a gamma of 1.0 (i.e. a
linear image - but not everyone obeys the rules).
Some image loaders (for instance xli - an X11 image utility)
allow you to specify not only the gamma of the monitor you
are using, but the individual gamma values of image you are trying to
view. Other image viewers (e.g. xv another X11 image program) and
utilities (eg. the pbm toolkit) provide ways of changing the gamma
of an image, but you have to figure out the overall gamma correction
yourself, allowing for undoing any gamma correction the image has,
and then the gamma correction you need to suite your CRT monitor.
[Note that xv 2.21 doesn't provide an easy way of modifying the
gamma of an image. You need to adjust the R, G and B curves to the
appropriate gamma in the ColEdit controls. Altering the Intensity
in the HSV controls doesn't do the right thing, as it fails to
take account of the effect gamma has on H and S. This tends
to give a tint to the image.]
How can I figure out what my viewer does, or what gamma my screen has?
The simplest way to do that is to try loading the file chkgamma.jpg
(provided with xli distribution), which is a JFIF jpeg format file
containing two grayscale ramps. The ramps are chosen to look linear
to the human eye, one using continuous tones, and the other using
dithering. If your viewer does the right thing and gamma corrects
images, then the two ramps should look symmetrical, and the point
at which they look equally bright should be almost exactly half
way from the top to the bottom. (To find this point it helps if
you move away a little from the screen, and de-focus your eyes a
If your viewer doesn't do gamma correction, then left hand ramp will have
a long dark part and a short white part, and the point of equal brightness
will be above the center.
If your viewer does have a way of setting the right amount of gamma correction
for a display, then if the equal brightness point is above center increase the
gamma, and decrease it if it is below the center. The value will usually be
[with xli for instance, you can adjust the display gamma with the
-dispgamma flag, and once you've got it right, you can set the DISPLAY_GAMMA
environment variable in your .profile]
How do I figure out what the gamma of an image is?
This is the most tricky bit. As a general rule it seems that a lot of
true color (i.e. 24 bit, .ppm .jpg) images have a gamma of
1.0 (linear), although there are many about that have some gamma
correction. It seems that the majority of pseudo color images
(i.e. 8 bit images with color maps - .gif etc.) are gamma corrected
to some degree or other.
If your viewer does gamma correction then linear images will
look good, and gamma corrected images will look too light.
If your viewer doesn't do gamma correction, then linear images will
look too dark, and gamma corrected images will ok.
Why Linear images are sometimes not such a good thing
One of the reason that many high quality formats (such as
Video) use gamma correction is that it actually makes better
use of the storage medium. This is because the human
eye has a logarithmic response to light, and gamma correction
has a similar compression characteristic. This means images
could make better use of 8 bits per color (for instance),
if they used gamma correction. The implication though, is that
every time you want to do any image processing you should
convert the 8 bit image to 12 or so linear bits to retain
the same accuracy. Since little popular software does this, and
none of the popular image formats can agree on a standard
gamma correction factor, it is difficult to justify gamma corrected
images at the popular level.
If some image formats can standardize on a particular gamma,
and if image manipulation software takes care to use
extra precision when dealing with linearized internal data,
then gamma corrected distribution of images would be a good thing.
(I am told that the Kodak PhotoCD format for instance, has a
standard gamma correction factor that enables it to get the
highest quality out of the bits used to hold the image).
Cognivision, 6 Oct 1993
Gamma correction is largely a crock because the fundamental assumption is
wrong. Yes, there is a (reasonably) reliable relationship between voltage and
phosphor emission power that the standard "gamma" formula models well enough
for our purposes. Unfortunately, this is not at all what the relationship from
pixel intensity value to visible brightness actually looks like. Major reasons
why not include the monitor offset (black level) control, and the CRT's
reflection of ambient light. The amplifiers can also be quite non-linear at
low voltage levels.
All this amounts to black not really being black, which throws a big wrench
into the gamma formula. Here is how I think of and deal with the problem:
The problem really comes down to mapping an image with a large dynamic range
(256:1) to an output medium with considerably less. Ektachrome slides can get
to 150:1, glossy prints with careful illumination 80:1, matte prints maybe
40:1, newspapers 15:1. A well adjusted monitor in a dark room maybe 100:1 if
everything is perfect. Figure 40:1 (if that much) for more normal monitor
situations. Contrast this to real world scenes in a office, which can easily
Clearly, something needs to get squashed in the process displaying or making a
hard copy of most images. The quest is to squash while maintaining the highest
perceived "likeness" to the true image. Humans perceive intensities
logarithmically, not linearly. Since we want to do image manipulations in
perceptual linear space, this means manipulating brightnesses in mathematical
log space. Humans also tend to "tune out" details in dark areas of a scene.
There was a lot of interesting research on this stuff done by Kodak back in the
Between the black level problem, the way our perception system works, and a
host of unpredictable environmental variables, it seems pointless to try to
come up with a formula that can then be "corrected" for. Even if you could
come close, my points are:
So, here's what I do. My software can map the input black to white range to
any other range, and can independently apply a "brightness" factor. The
brightness factor is exponential in nature, but doesn't affect full black or
full white. A value of 0 leaves everything alone. Positive values
increasingly slosh intensities smoothly to the white end, while negative values
slosh towards black. This doesn't try to model what the hardware is actually
doing, but provides enough controls to make things look good.
- Such a formula couldn't be reasonably approximated by anything as simple
as one "gamma" exponential.
- Even if the function was known, you don't want to "correct" for the best
linear mapping anyway. You want the best logarithmic mapping.
I have used this technique to pre-treat images for film recorders, printers,
and other output media with great results.