Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!onfcanim!dave
From: dave@onfcanim.UUCP
Newsgroups: comp.graphics
Subject: Re: Gamma Correction of Monitors
Message-ID: <15480@onfcanim.UUCP>
Date: Sun, 22-Nov-87 13:17:52 EST
Article-I.D.: onfcanim.15480
Posted: Sun Nov 22 13:17:52 1987
Date-Received: Wed, 25-Nov-87 02:23:22 EST
References: <880002@hpcehfe.HP.COM> <1314@aurora.UUCP>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 59

Another thing to keep in mind: "gamma" is only an approximation to the
actual response of the monitor.

The process of "gamma correction" assumes that the monitor behaves in
such a way that

	screen_luminance = video_voltage ** gamma

for some value of "gamma" > 1.0.

If this relationship were precisely true, then if you plot luminance
(measured with a photometer of some sort) against DAC input value
on a log-log graph, you should get a straight line whose slope is "gamma".
If you try this experiment, you won't get a straight line, because the
response of the CRT gun (and perhaps phosphor) doesn't precisely follow
the mathematical model.

So, any method of computing a CRT's gamma is a method of giving you a
one-degree-of-freedom fit of an exponential function to the CRT's true
response.  It will give you a result that is a lot better than that
produced by assuming that the CRT is linear, but errors will remain.

The only way I can think of to *really* do correction for a CRT's response
over its full intensity range is to actually measure its output for
a representative sample of DAC values (say, 20 values spaced a factor of
sqrt(2) apart), then fit a function through those data points (probably
a B-spline would be good).  This function then relates DAC value to
intensity on screen, and you can use standard root-finding techniques
to determine what DAC value to use to give you any specific intensity,
which is exactly what is necessary for building a lookup table to compensate
for the CRT's response.

Of course, this still doesn't compensate for light falloff at the edges of
the screen, or single isolated pixels being darker than an area with the
same pixel value, but it's a start.


I have a program (in C) that does the spline fitting and lookup table
calculations described above that I could send to people, or is there
enough interest to post it to USENET at large?

There are actually 2 versions.  The "real" version is intended for
use with film recorders, and deals as best it can with a medium where
the 3 colours interact with each other.  It also handles different
pixel encodings, positive and negative film, and plots graphs of what
is going on.  It's about 90Kb of source, so I'm not willing to send it
at the expense of my uucp neighbours, but if you can call onfcanim
directly I can send it that way.

There is also a simplified version that it a lot easier to read.  It handles
only one colour at a time, but that should be OK for CRT's since the
colours should be independent of each other.  It is written for negative
film, with exposure measurements in terms of density (base 10 log of
transmission), so you'd have to make a few changes to use photometer
readings instead, but that shouldn't be hard.  It's about 15 Kb before
compression, so I'd send it by mail.

	Dave Martindale
	{watmath,micomvax,musocs}!onfcanim!dave