[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The Skinny on 24-Bit Color (Long)
- Subject: The Skinny on 24-Bit Color (Long)
- From: davidf(at)dfanning.com (David Fanning)
- Date: Tue, 26 May 1998 21:04:17 -0600
- Newsgroups: comp.lang.idl-pvwave
- Organization: Fanning Software Consulting
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:11061
Thanks to the kind folks at RSI, I have the latest on the
24-bit color situation. Here is what I know about it.
The way 24-bit color is handled changed on BOTH the Windows
and Mac versions of IDL in IDL 5.1. According to RSI, these
platforms have never handled 24-bit color correctly and it
had gotten to the point that people were beginning to count
on the incorrect capabilities in their programming. In the
interest of cross-platform consistency (I'm all for this!)
they decided to fix both platforms to bring them into
compliance with the official 24-bit standards. (Some of this
information, by the way, is spelled out in the IDL 5.1
release notes, but none of it made it into the on-line help
or the official IDL 5.1 documentation.)
Here is the information I found in the release notes:
In previous releases of IDL on Windows platforms, when
the system's display properties were set to thousands of
colors or True Color, decomposed colors were being
translated by the IDL color table inconsistently.
In IDL 5.1, the Windows behavior with respect to decomposed
color has been made consistent with other platforms.
Decomposed colors are now no longer translated by the IDL
color table; rather, the red, green, and blue components
of the color are honored directly. To utilize the IDL
color table, colors must be specified as a single index,
and decomposed color must be turned off (either by
setting the system's display properties to 256 colors,
or by using the following command: DEVICE, DECOMPOSED=0).
In previous versions of IDL for the Macintosh the decomposed
setting on the graphics device with regard to images was the
opposite of the other platforms. IDL 5.1 now handles the
decomposed setting properly; DECOMPOSED=0 specifies passing
indices and DECOMPOSED=1 specifies passing in rgb triplets.
Any programs that depended or attempted to work around the
aforementioned problem will have to be revised.
I probably don't need to remind people in this newsgroup
that the last sentence certainly means that you will need
to become familiar with the !Version.Release system
What else does this mean to you if you are a Windows
or Macintosh user?
Well, for starters, it means that if you have decomposed
color turned ON (DEVICE, DECOMPOSED=1), which is often the
default setting on 24-bit devices, then an 8-bit image
will ONLY display in gray scale colors. It means that
the color table tools (XLoadCT or XCOLORS) won't work
at all. It also means that you will have to specify a
24-bit integer to get graphics to display in color:
Plot, data, Color = '00ffff'x
To get an 8-bit image to display in color, or to use a
color table tool, you will have to turn color decomposition
Notice that when you do this !D.N_Colors will equal 256,
not the 16.7 million it did in previous versions of IDL.
This, by the way, is how you will know you are on a 24-bit
color device. !D.N_Colors will be greater than or *equal* to
256. (In normal 8-bit Windows or Macintosh versions of IDL
you cannot ever have 256 simultaneous colors.) I don't
know how you will determine unambiguously the depth of the
visual class on an X window device, but more on that later.
If color decomposition is OFF, you will be able to display
color images with the colors loaded in the current color table,
the color table tools will work, and you will be able to
specify a graphics color as an index:
TVLCT, 255, 255, 0, 10
Plot, data, Color=10
If you change the colors in the current color table, *many*
of us will need to redisplay the image to see the new colors
take effect. What determines whether you are one of the
lucky ones, whose graphical displays change automatically
when you change color tables, is the kind of 24-bit color
device you are using. On Windows, you will be using a True-Color
device. True-Color devices are STATIC color devices. This
means that the colors used for the graphics are not tied in
any way to the colors loaded in the current color table.
If you change the color table values, you MUST redisplay the
graphic to see the colors take effect. I presume, but
do not know for sure, that the Mac is also a True-Color device.
If you are on a UNIX machine, there is a possibility that
you are using a Direct-Color device. (True-Color and
Direct-Color visual classes are selected with the DEVICE
command.) Direct-Color devices are DYNAMIC color devices.
This means that there is a dynamic interaction between
the colors of the graphic and the current color table
values. Change the values, and you automatically and
immediately update the colors in the graphic. There is
no need to re-display the image or graphic to see the
new colors take effect.
There is currently in IDL no facility to determine if
color decomposition is on or off. Nor is there any way
to determine which visual class you are currently using
or the depth (e.g. 8-bit or 24-bit) of that visual class.
According to RSI several programmers have seen a need for
such a facility and these requests have been noted. There
may be a way to determine such things in future releases
I think what this means in the short term is that your
programs are going to have to be written so as
to protect them from color decomposition being set
in such a way as to render them useless. It will be up
to each program to determine what kind of color decomposition
is needed and to configure the device appropriately. In
practice this probably means making sure color decomposition
is set correctly *every time you issue a graphics command*.
In widget programs this just means that every time you
set the current graphics window you also set color decomposition:
Device, Decomposed = 0
Note that you may have to change the color decomposition
setting frequently inside a single program. (For example,
you may have to display both 24-bit and 8-bit images.)
I still have a number of unanswered questions about
color on various devices, but I will be trying to work
this out over the next few weeks. It certainly makes
things more complicated as we contend with programs
that must work properly not only on 8-bit and 24-bit
devices, but in different versions of IDL too.
I'll have an article on my web page about this and I
promise to update it frequently as new information
becomes available to me.
As always, I am extremely grateful to get information
from the field. :-)
David Fanning, Ph.D.
Fanning Software Consulting
Coyote's Guide to IDL Programming: http://www.dfanning.com/