| Re: gamma correction [message #31222] |
Fri, 28 June 2002 07:29  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
> What are you talking about here David?
>
> When I use DEVICE, DECOMPOSED=0, I can use the 256 entry color table.
> You taught me that incantation! :-)
OK, here is the test. Run this in a fresh IDL session.
;*********************************************************** *
PRO TEST
; Get 24-bit JPEG image.
file = FilePath('rose.jpg', SubDir=['examples', 'data'])
Read_JPEG, file, rose
; Display it by running through ugly color table.
LOADCT, 5
DEVICE, TRUE_COLOR=24, DECOMPOSED=0
TV, rose, TRUE=1
END
;*********************************************************** *
Does your display have a beautiful rose in it, or
does it look, well, strange?
Please tell us what version of IDL you are using, too.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: gamma correction [message #31223 is a reply to message #31222] |
Fri, 28 June 2002 06:33  |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
David Fanning <david@dfanning.com> writes:
> UNIX machine in TRUECOLOR mode, with color decomposition
> turned OFF, did not take the image values through the
> color table before display, as it does with PCs.
What are you talking about here David?
When I use DEVICE, DECOMPOSED=0, I can use the 256 entry color table.
You taught me that incantation! :-)
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: gamma correction [message #31229 is a reply to message #31223] |
Thu, 27 June 2002 21:42 |
Dick Jackson
Messages: 347
Registered: August 1998
|
Senior Member |
|
|
"David Fanning" <david@dfanning.com> wrote in message
news:MPG.1785543b517ba7a498991a@news.frii.com...
> Dick Jackson (dick@d-jackson.com) writes:
>
>> By changing the colortables with Gamma_CT or just
>> using TVLCT [with 24-bit images]
>
> I just point out again that while this would probably
> work on a Mac and PC, it probably won't work on a
> UNIX machine. The last time I checked (several years
> ago and God knows RSI has changed the way color works
> enough times that two years is ancient history), a
> UNIX machine in TRUECOLOR mode, with color decomposition
> turned OFF, did not take the image values through the
> color table before display, as it does with PCs.
Sorry, you had mentioned that. Would someone confirm whether this is still the
case!
> In other words, on UNIX machines a true-color image
> is a true-color image [...]
>
> Now I see that the fore-sighted engineers at RSI
> were really concerned about gamma correction and
> had put the machinery in place to handle this
> without me even realizing it. Have I mentioned that
> I *love* IDL!
:-) Gotta wonder, was it intentional? Could they be reconciled?
> I'm just feeling sorry for the UNIX
> guys now. They are going to have to modify the
> numbers in their image to get the same effect.
We can always just make three lookup arrays and use them 'manually' to give the
same effect, as in:
newImageRedChannel = redLookup[origImageRedChannel]
Or simpler, if all three channels are using the same transfer function (simple
gamma curve, for example), we could just make one 256-byte lookup table and
then:
TV, /True, gammaLookup[origImage]
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
|
|
|
|
| Re: gamma correction [message #31230 is a reply to message #31229] |
Thu, 27 June 2002 20:53 |
Med Bennett
Messages: 109
Registered: April 1997
|
Senior Member |
|
|
Ben Tupper wrote:
> On Wed, 26 Jun 2002 16:22:22 -0600, David Fanning <david@dfanning.com>
> wrote:
>
>> David Fanning (david@dfanning.com) writes:
>>
>>> Here is a program that demonstrates what I mean. How do these
>>> ideas square with the "right" way in Infarct (or whatever
>>> the hell it was called) Ben?
>>
>> Whoops, I meant Med Bennet, of course. Blush...
>>
>> David
>
> If you meant me, then it's a pleasure to be confused with Med. Med
> might not feel similarily.
>
> Cheers,
>
> (The other) Ben
I am also pleased to be confused with Ben! My original comment was
somewhat snide, in that I have other software packages that implement a
"gamma correction" function to jpeg images (IrfanView, excellent freeware
image viewing/manipulation software, and Paint Shop Pro), and I have (or
had) little or no understanding of the fundamental underpinnings of such
operations, or how those other sw packages implement said gamma
corrections - all that I know is that they can make an image look a lot
better. Thanks all for the enlightenment, so to speak! :)
--
----
Real email address is mbennett at indra dot com
ICBM Coordinates: 40.02N, 105.29W, 1670 m
|
|
|
|
| Re: gamma correction [message #31231 is a reply to message #31230] |
Thu, 27 June 2002 16:57 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Dick Jackson (dick@d-jackson.com) writes:
> 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.
I just point out again that while this would probably
work on a Mac and PC, it probably won't work on a
UNIX machine. The last time I checked (several years
ago and God knows RSI has changed the way color works
enough times that two years is ancient history), a
UNIX machine in TRUECOLOR mode, with color decomposition
turned OFF, did not take the image values through the
color table before display, as it does with PCs.
In other words, on UNIX machines a true-color image
is a true-color image and what you have is what you
see. I always thought this was the correct way to
operate and assumed the PC behavior (which almost
always results in wacky image colors) was a bug.
Now I see that the fore-sighted engineers at RSI
were really concerned about gamma correction and
had put the machinery in place to handle this
without me even realizing it. Have I mentioned that
I *love* IDL! I'm just feeling sorry for the UNIX
guys now. They are going to have to modify the
numbers in their image to get the same effect.
> Sorry for the long ramble, I hope it's of some help.
I think the long discussion just points out my
earlier contention that gamma is a strange thing
and it is hardly ever clear what you mean by it.
Charles Poynton is clear about most things having
to do with color, and in my experience almost
invariably right. I look forward to seeing the IDL
code that results. :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| 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
|
|
|
|
| Re: gamma correction [message #31235 is a reply to message #31232] |
Thu, 27 June 2002 13:23 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ben Tupper (btupper@bigelow.org) writes:
> If you meant me, then it's a pleasure to be confused with Med. Med
> might not feel similarily.
Well, of course I was thinking of you, Ben. The strong
chin, the courtly demeanor, etc. But the question is,
do you know anything at all about this gamma business?
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: gamma correction [message #31237 is a reply to message #31236] |
Thu, 27 June 2002 11:06 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
"David Fanning" <david@dfanning.com> wrote in message
> Dick Jackson (dick@d-jackson.com) writes:
>
>> Usually, colortables are used with 2D (nx, ny) images where the byte
values are
>> looked up in the RGB colortables, while 3D images (3, nx, ny) have their
byte
>> values used exactly as given.
>>
>> Less common, but equally valid, is to display a 3D image where each
plane's byte
>> values are looked up in the colortables. Gamma_CT changes the
colortables so
>> that an image that uses them appears to have had its 'gamma' changed.
>>
>
> Well, it does on PCs and Macs. I'm not sure it
> does on UNIX machines, at least not in all versions
> of IDL. :-)
>
> 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.
>
Gamma is not really brightness but color intensity. Gamma correction
adjusts your image data to compensate for the nonlinear relationship between
the image's RGB values and the displayed intensity of the pixel on the
screen. On 8 bit systems gamma correction is usually applied to the LUT but
on 24 bit systems it is applied to the image data at some point between the
frame buffer and the phosphor on your screen. Many newer computers ship
with some type of gamma correction in place. As far as I understand, *and I
don't*, the basic idea is:
;typical gamma for a typical monitor
gamma=2.5
;read an image
image_file = filepath('elev_t.jpg', $
subdirectory=['examples', 'data'])
read_jpeg, image_file, image_data
;display original image
window, 0
tvimage, image_data
;display "gamma corrected" image
gc_image = byte(0 > image + image^(1/gamma) < 255)
window, 1
tvimage, gc_image
Now I can't stress more that there are all sorts of details I am ignorant of
and thus are omitted from the example above.
So to answer the original posters question:
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.
-Rick
|
|
|
|
|
|
| Re: gamma correction [message #31245 is a reply to message #31244] |
Wed, 26 June 2002 15:20 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Dick Jackson (dick@d-jackson.com) writes:
> Usually, colortables are used with 2D (nx, ny) images where the byte values are
> looked up in the RGB colortables, while 3D images (3, nx, ny) have their byte
> values used exactly as given.
>
> Less common, but equally valid, is to display a 3D image where each plane's byte
> values are looked up in the colortables. Gamma_CT changes the colortables so
> that an image that uses them appears to have had its 'gamma' changed.
>
> Quick examples:
>
> =====
>
> COMMON Colors ; allow access to color tables
> Device, Decomposed=0 ; set to use color tables for lookup
>
> file = FilePath('rose.jpg', SubDir=['examples', 'data'])
> Read_JPEG, file, image
>
> TV,/True,image ; show original image
>
> Gamma_CT,0.5 ; set gamma 0.5
> Plot,[r_curr,g_curr,b_curr] ; show the colortables (crudely!)
> TV,/True,image ; show image
>
> Gamma_CT,2.0 ; set gamma 2.0
> Plot,[r_curr,g_curr,b_curr] ; show the colortables
> TV,/True,image ; show image
>
> END
>
> =====
>
> No need to recompute the image array, it just passes through the transforming
> colortables on its way to the display. Hope this helps!
Well, it does on PCs and Macs. I'm not sure it
does on UNIX machines, at least not in all versions
of IDL. :-)
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.
What if we convert the RGB image to HSV color space and
only apply the gamma to the brightness (value) part of the
image?
Here is a program that demonstrates what I mean. How do these
ideas square with the "right" way in Infarct (or whatever
the hell it was called) Ben?
Cheers,
David
;*********************************************************** ***
PRO Example, gamma
IF N_Elements(gamma) EQ 0 THEN gamma = 2.0
; Get 24-bit JPEG image.
file = FilePath('rose.jpg', SubDir=['examples', 'data'])
Read_JPEG, file, image
; Show original image.
DEVICE, Decomposed=1
Window, XSize=227*2, YSize=149, /Free, $
Title='Gamma of ' + StrTrim(gamma, 2)
TV, image, True=1
; Convert from RGB to HSV color space.
r = Reform(image[0,*,*])
g = Reform(image[1,*,*])
b = Reform(image[2,*,*])
Color_Convert, r, g, b, h, s, v, /RGB_HSV
; Perform gamma correction on the "brightness".
correction = long(256*((findgen(256)/256)^gamma))
new_v = correction[BytScl(v)] / 255.0
; Convert back to RGB space.
Color_Convert, h, s, new_v, rr, gg, bb, /HSV_RGB
; Create the gamma corrected image and display it.
g_image = image
g_image[0,*,*] = rr
g_image[1,*,*] = gg
g_image[2,*,*] = bb
TV, g_image, True=1, 227, 0
END
;*********************************************************** ***
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: gamma correction [message #31246 is a reply to message #31245] |
Wed, 26 June 2002 14:17 |
Dick Jackson
Messages: 347
Registered: August 1998
|
Senior Member |
|
|
Hi all,
"David Fanning" <wrote in message
news:MPG.1783bfeb1d50d36a989916@news.frii.com...
> Med Bennett (no.spam@this.address.please) writes:
>
>> Hmmm... my Irfanview software happily gamma corrects 24-bit JPEGs - I do it
all
>> the time. Why shouldn't IDL be able to do it?
>
> I'm not suggesting gamma correction is impossible.
> I just don't know what it means. What do you think it
> means for 24-bit images? In other words, what are you
> doing to the image when you gamma correct it?
Usually, colortables are used with 2D (nx, ny) images where the byte values are
looked up in the RGB colortables, while 3D images (3, nx, ny) have their byte
values used exactly as given.
Less common, but equally valid, is to display a 3D image where each plane's byte
values are looked up in the colortables. Gamma_CT changes the colortables so
that an image that uses them appears to have had its 'gamma' changed.
Quick examples:
=====
COMMON Colors ; allow access to color tables
Device, Decomposed=0 ; set to use color tables for lookup
file = FilePath('rose.jpg', SubDir=['examples', 'data'])
Read_JPEG, file, image
TV,/True,image ; show original image
Gamma_CT,0.5 ; set gamma 0.5
Plot,[r_curr,g_curr,b_curr] ; show the colortables (crudely!)
TV,/True,image ; show image
Gamma_CT,2.0 ; set gamma 2.0
Plot,[r_curr,g_curr,b_curr] ; show the colortables
TV,/True,image ; show image
END
=====
No need to recompute the image array, it just passes through the transforming
colortables on its way to the display. Hope this helps!
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
|
|
|
|
|
|
|
|
|
|
| Re: gamma correction [message #31365 is a reply to message #31222] |
Fri, 28 June 2002 14:01 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
David Fanning <david@dfanning.com> writes:
> Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
>
>> What are you talking about here David?
>>
>> When I use DEVICE, DECOMPOSED=0, I can use the 256 entry color table.
>> You taught me that incantation! :-)
>
> OK, here is the test. Run this in a fresh IDL session.
...
> Does your display have a beautiful rose in it, or
> does it look, well, strange?
Beautiful rose, thank you very much! IDL versions checked from
5.2 to 5.4.
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
