Re: device,decomposed=1 question [message #14641 is a reply to message #14586] |
Tue, 16 March 1999 00:00   |
Vapuser
Messages: 63 Registered: November 1998
|
Member |
|
|
bowman@null.tamu (Kenneth P. Bowman) writes:
> In article <MPG.1153439eae020777989721@news.frii.com>, davidf@dfanning.com
> (David Fanning) wrote:
>
>> No, it doesn't look the value up in the color table. The three
>> numbers *are* the color. There is no color table involved.
>> In a 24-bit image, it would be the pixel value in each of the
>> red, green, and blue planes that create the value that is actually
>> expressed. Again, no color table involved at all.
>
> Actually, some 24-bit devices do have writable color tables. This is the
> distinction between TrueColor and DirectColor visuals. I believe our
> SGI's have DirectColor visuals, but most of our other 24-bit hardware does
> not allow one to change the color maps.
>
I can't get this to work. On my SGI (an Octane running 6.5.2)
there's no difference between TrueColor and DirectColor visuals
(whether decompose=1 or 0)) and, with /decomposed, both work as David
suggests, the color specified in the 'color=...' keyword *is* the
color, not a composited number comprising the three indices into a
color table.
The IDL help claims the DirectColor visuals allow for a writable
color table. I just can't seem to demonstrate what that means, or
whether it is, in fact, true. It certainly looks like, for all intents
and purposes, TrueColor=DirectColor.
Could you create a small example program, or give me a hint on how
to do it myself? I would have use of this capability and would love to
see how it works.
> Ken Bowman
>
> --
> Kenneth P. Bowman, Professor 409-862-4060
> Department of Meteorology 409-862-4466 fax
> Texas A&M University bowmanATcsrp.tamu.edu
> College Station, TX 77843-3150 Change the AT to @
|
|
|