| Re: q: what is the role of color tables for true color images [message #9310] |
Wed, 25 June 1997 00:00 |
Struan Gray
Messages: 178
Registered: December 1995
|
Senior Member |
|
|
Mirko Vukovic, mirko.vukovic@grc.varian.com writes:
> I have a P133, 16bit color card, win95 and idlV5.
I have Macs and PPC Macs with IDL4.01 and the 5.0 pre-release, so my
experience may not be relevant.
> What do the color table settings have to do with
> display of images using
>
> tv,r,chan=1
> tv,g,chan=2
> tv,b,chan=3
They act as lookup tables. The intensity that ends up in the
screen buffer is not [r(i,j), g(i,j), b(i,j)] but [table(r(i,j)),
etc]. This means that you can do (crude) colour table animation and
gamma correction but most of the time is a total pain in the arse. I
don't know how IDL works around the colour table having less than 256
entries. In the IDL 4 paper manuals this was explitly stated in the
chapter on IDL graphics devices, naturally enough in the section on
the postscript device :-)
The only workaround I've found in direct graphics is to load colour
table 0 before plotting, since the lookup still happens if you combine
the rgb planes into a single 3-dimensional picture and use the TRUE
keyword with TV.
> For that matter, can someone tell me how many bits are there in
> r,g,b in 16 bit displays?
On the Macs IDL behaves internally as if the display were 24 bit.
That is, if you use TVRD() to read an 8-bits-per-channel image back
from the display you don't get an image posterised to 5-bits. The
posterisation does occur on the screen - as it must - and is obvious
in things like greyscale images with smooth ramps.
Struan
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
