Loading a color table doesn't appear to work.
This article is old enough that assumes that user's can still come across 256 color tables as well as 8bit Pseudocolor
There are two main steps to setting up an IDL Direct Graphics window to use the video card's 256-color palette (a.k.a. "color table"). One of the two steps is frequently neglected, leading to symptoms that make users believe that IDL has failed to load the color table. These are the most common tell-tale symptoms:
-
TV or TVSCL loads its 2D image in grayscale, even though the user explicitly loaded a colorful color table.
-
Line and text-drawing commands (e.g. PLOT, CONTOUR, SURFACE, XYOUTS, etc .) draw strictly in shades of red.
This Tech Tip discusses why and how a simple call to:
will solve this problem.
NOTE: A different symptom that users wonder about is: "Why doesn't my graphics scene change color right after I load a new color table?" This topic is handled in Tech Tip #4287.
Discussion
There are three basic kinds of color models in computer operating systems and graphics libraries: True Color, Direct Color and "pseudocolor" (a.k.a. "palettized color"). True Color, the most common model used in programming these days, uses 24- or 32-bit values to define a color. Pseudocolor uses 8-bits, allowing color values only between 0 and 255 in magnitude. It sacrifices color range for efficiency, ease of use and code readability. Direct Color (available only on UNIX-type systems) is a much less frequently used in-between model; think of it as palettized color with a 4,096- to 16,777,216- element color table. IDL treats Direct Color like True Color, and we discuss them as if they were one model for the remainder of this Tech Tip.
It is common for computers (or their video cards) to have two color models simultaneously available to IDL graphics calls. Pseudocolor is almost always one of these because almost all graphics card have a 256-element buffer where a user-defined color table can be stored and modified. IDL defaults to using the other model, either True or Direct.
Many users do not realize that they can load a color table (and read it) without it ever having an impact on their display. That is, they can run commands like:
or:
see no effect in their graphics display, and assume that there was an error in execution. In fact, the only task performed by the above calls is to change the 256 color values stored in the video graphics card. IDL Direct Graphics has a different command to tell an IDL process to ***use*** the color table, and that is this:
This terminology "decomposed" is a little obscure; think of it as having a meaning like use-color-table=true.
After calling the above command, the ***next*** graphics window you initialize will use the 256-element color table model. Graphics windows cannot change their ruling color model after they are initialized. That is simply not allowed by any operating system or its graphics libraries.
Many users might like to switch back and forth between using True Color and Pseudocolor models during a single IDL session. Many users, for example, prefer to work with images in RGB True Color, while they color line plots with color table colors. To switch back to using True Color ***in the next graphics window*** run "DEVICE, DECOMPOSED=1". That brings up one final point: Once a "DEVICE, DECOMPOSED=..." call is run, it is valid for the entire remaining IDL session ... even if it occurs deep down in a sub-sub-subroutine. Thus, we recommend the following code convention for any user functions or procedures that used DEVICE's DECOMPOSED keyword:
Start your routine with the following two lines:
device, GET_DECOMPOSED=originalDCstate
device, DECOMPOSED=0
and at the bottom of your routine (and at every possible exit point) insert:
device, DECOMPOSED=originalDCstate
Particularly if you are sharing your code or its compilation with other IDL users, this will insure that you do not leave them in a color model state different than the one they had before they called your code.