| Re: gamma correction [message #31232 is a reply to message #31231] |
Thu, 27 June 2002 16:14   |
Dick Jackson
Messages: 347
Registered: August 1998
|
Senior Member |
|
|
Dealing with these issues in a *precise* manner is even more involved than what
Rick, David and I have written so far. For a full discussion of the issue,
Charles Poynton has provided the following:
http://www.inforamp.net/~poynton/GammaFAQ.html
And if you need more, his book "A Technical Introduction to Digital Video" has
been an excellent reference. When I had to dig into this stuff, I was really
surprised at how much I had been misunderstanding about light and color. (what
does "white" mean, anyway? :-)
David wrote...
> But here is an alternative point of view. Normally, we
> think of gamma as affecting the "brightness" of an
> image. Dick's example has the effect of actually
> changing the colors in the image, which may lead
> us away from the gamma idea.
"Rick Towler" <rtowler@u.washington.edu> wrote...
> As David and Dick pointed out the built in gamma correct functions act on
> the LUT which is meaningless for your average 24 bit image. There isn't a
> function in IDL to gamma correct a 24bit image but it should be fairly easy
> to implement. Search the web and newsgroups for info and example code.
I have to disagree with Rick and David's assessments of doing this with 24-bit
images. The R, G and B planes are entirely independent from one another when
they come from the camera and independent when they go to the monitor. It's
helpful to remember that our IDL image array values are just a nonlinear
encoding of actual light measurements, chosen to make the best use of the 256
levels in each color channel.
In IDL, all we can do for "gamma correction" is to provide an extra transfer
function that achieves a certain conversion from a given data value from the
camera (0-255) to a signal level to be sent to the monitor (also 0-255), for
each of R, G and B. This is precisely what Gamma_CT does by changing the three
colortables.
Now, how to calculate the correct function for a given purpose can be a tricky
business. In the simplest case, if the camera used to take an image has roughly
the same transfer function as your monitor (but in the opposite direction) then
you need to make no change at all. This is what we assume all the time when we
display any image in IDL or any other program without tweaking it. This is
handled by the default linear 'ramp' colortable for all R, G and B.
In an extreme case where you want to accurately reproduce a scene imaged by a
given camera on a given monitor, then if you know the transfer functions of:
- the camera's response to light (in R, G and B), and
- the monitor's light output in response to the signal level (in R, G and B),
then you can create functions for R, G and B to compensate for the difference
between these functions. I might mention that camera and monitor transfer
functions aren't exact exponential functions either, so some oddly-shaped curves
may be needed to do this well. This is what "ICC profiles" for imaging input and
output devices are all about, see more at www.color.org
But if you just want to try adding a 'gamma correction' (an exponential
function) in IDL as a step in the middle (between the camera and the monitor), I
see no harm in using Gamma_CT as in my example. I would just keep in mind that
there is already some function going on between the image array values and the
light coming from the monitor (something close to a gamma function at around
gamma=2.5 as Rick mentions). By changing the colortables with Gamma_CT or just
using TVLCT, you are just adding another function in front of that.
Sorry for the long ramble, I hope it's of some help.
Cheers,
--
-Dick
Dick Jackson / dick@d-jackson.com
D-Jackson Software Consulting / http://www.d-jackson.com
Calgary, Alberta, Canada / +1-403-242-7398 / Fax: 241-7392
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
