NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/rec/video/15002

Text File | 1992-12-22 | 3.4 KB | 81 lines

Newsgroups: rec.video
Path: sparky!uunet!usc!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watmath!watcgl!imax!dave
From: [e-mail] (Dave Martindale)
Subject: Re: Need help with gamma computation
Message-ID: <[e-mail]>
Organization: Imax Corporation, Mississauga Canada
References: <-62130@nemesis>
Date: Tue, 22 Dec 1992 05:19:01 GMT
Lines: 70

In article <-62130@nemesis> [e-mail] writes:
>
>I am working with a device that as far as programming goes looks like a
>VGA controller but outputs NTSC.  Recently I have encountered
>excessive brightness problems and am trying to find how to compute
>the gamma value for NTSC.  I know there is a standard for televisions
>and I would like a definitive value on that too.

[ further explanation deleted }

You're confusing two different subjects: gamma correction and non-encodable
colours.

First, gamma correction:  The CRT is a nonlinear device - light out is not
proportional to voltage in, but proportional to voltage in raised to
some power between 2 and 3.  This power is called the CRT's gamma.
To compensate, you apply "gamma correction".

For example, say you have an intensity between 0 (black) and 1 (white),
represented as a floating-point number.  To convert to an 8-bit value to
feed to the D/A converter, the naive way to do it is

    pixel_value = (int)(intensity * 255.0 + 0.5);

This doesn't work properly, because of CRT gamma.  Instead, do gamma
correction first:

    gc_intens = pow(intensity, 0.45);
    pixel_value = (int)(intensity * 255.0 + 0.5);

The 0.45 is the reciprocal of a CRT gamma of 2.2.  This is in fact the
value that the NTSC standard says you should compensate for (PAL uses 2.8).
For example, if the intensity is 0.18 (mid-grey), the correct pixel value
is 118 (not 46!).

If your intensities are already in integer form, you can do gamma
correction as

    pixel_value = (int)(255.0 * pow(pixel_value / 255.0, 0.45) + 0.5);

Unfortunately, quantizing to integer twice like this throws away a lot of
the intensity resolution in dark areas, and you are going to get banding
problems in dark regions of some images.  Doing gamma correction in hardware
with only 8-bit pixel values suffers the same fate.

Also, note that 0 and 1 are fixed points for the gamma correction function:
0->0 and 1->1.  It is only intermediate values that are different.

Now for the second part: non-encodable colours.  The NTSC standard was
set up with the assumption that scenes would never contain full-saturation
full-intensity colours.  Nature just isn't like that.  You can use
full saturation up to 75% intensity without the NTSC-encoded waveform
reaching amplitudes that are outside the normal B&W range, and you can
use higher intensities at somewhat lower saturation.  But there are some
RGB colours that you can display on a monitor that just can't be turned
into broadcastable NTSC signals.

For more detail about video colour encoding, unrepresentable colours,
and one way of dealing with them, see "Television Colour Encoding and
"Hot" Broadcast Colours", p 147, Graphics Gems II, edited by James Arvo,
Academic Press.

A final note: Standard colour bars use 75% intensity colours.  That's
75% *after* gamma correction, not before.  So the correct thing to
store in the frame buffer is just 0.75 * 255 = 191.  (Unless the
frame buffer has gamma correction hardware and you're using it,
in which case you have to figure out what to store in the image in
order to get 191 after gamma correction.)

    Dave