avi@hpcehfe.UUCP (11/16/87)
I am interested in finding out what techniques people use (or know about) to perform monitor 'gamma correction'. In particular, does anyone have a method to linearize screen luminance without a photometer (or similar measuring device), but simply with some visual task which is independent of the display hardware. A matching task using true gray in one field and a dither pattern of black and white pixels in the other will not necessarily work, since there's no gaurantee that turning on half the pixels (for example) will generate a luminance reading halfway between min and max. In fact, different layouts of the black and white pixels can lead to significantly varying luminance readings. Other than general coverage in computer graphics texts, I have found only three useful references addressing this topic (see below). Pointers to articles or tutorials (for color or monochrome) are appreciated. %L Catm79 %A E. Catmull %T A Tutorial on Compensation Tables %J Computer Graphics %V 13 %N 2 %D August 1979 %P 1-7 %O SIGGRAPH 1979 Proceedings. %L Cowa83 %A W. B. Cowan %T An Inexpensive Scheme for Calibration of a Colour Monitor in Terms of CIE Standard Coordinates %J Computer Graphics %V 17 %N 3 %D July 1983 %P 315-321 %O SIGGRAPH 1983 Proceedings. %L Mart87 %A D. Martindale %A D. Kochanek %T Quality Film and Video Output for Computer Graphics and Animation %R CHI+GI 1987 Tutorial Notes %D April 1987 Avi Naiman Hewlett Packard & University of Toronto (415) 857-6310 avi%hpcea@hplabs.hp.com ...!hplabs!hpcea!hpcehfe!avi
jbm@aurora.UUCP (Jeffrey Mulligan) (11/19/87)
in article <880002@hpcehfe.HP.COM>, avi@hpcehfe.HP.COM (Avi Naiman) says: > > I am interested in finding out what techniques people use (or know about) > to perform monitor 'gamma correction'. In particular, does anyone have a > method to linearize screen luminance without a photometer (or similar > measuring device), but simply with some visual task which is independent > of the display hardware. A matching task using true gray in one field > and a dither pattern of black and white pixels in the other will not > necessarily work, since there's no gaurantee that turning on half the > pixels (for example) will generate a luminance reading halfway between > min and max. In fact, different layouts of the black and white pixels > can lead to significantly varying luminance readings. > Indeed. However, it would seem that this failure of spatial independence is a monitor defect. For example, an isolated "on" pixel may be dimmer that a similar pixel in the middle of a large "on" field because of inadequate video bandwidth. If this is the case, then a simple gamma correction table (say, from photometer measurements of large uniform fields) isn't enough to insure you get what you want. I have tried doing things like you propose; instead of doing a brightness match, you can interleave frames of the white/black dither pattern with a uniform gray, and adjust the level of the gray to minimize the flicker. Another approach is to do a brightness match between rapid black/white flicker and steady uniform gray. I tried both of these earlier this year on my monitor (brightness match of b/w flicker and gray, and flicker minimization of b/w stripes and uniform gray, with both vertical and horizontal stripes). I got a different answer with each method, and none of the answers agreed with the photometer data from a large field. The different results may have straddled the photometer data, I don't remember. We are getting a new monitor. A problem related to the failure of spatial independence arises in conjunction with dithering gray scale pictures for printing. The problem is that the size of a single ink dot is often larger that the positional resolution for drawing a dot; thus two adjacent black dots give something less than twice as much black area. The is a guy at IBM Almaden Research labs (whose name escapes me) who has worked on correction schemes for printing accurate gray scale images. Presumably these techniques could be applied equally well to monitors exibiting failures of spatial independence. -- Jeff Mulligan (jbm@ames-aurora.arpa) NASA/Ames Research Ctr., Mail Stop 239-3, Moffet Field CA, 94035 (415) 694-5150
dave@onfcanim.UUCP (11/22/87)
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