| device,decomposed=1 question [message #14586] |
Fri, 12 March 1999 00:00  |
Vapuser
Messages: 63
Registered: November 1998
|
Member |
|
|
This is on a
IDL> print,!version
{ mipseb IRIX unix 5.1.1 Jul 20 1998}
Okay. I thought I understood this stuff, but now I'm not sure.
This is how I thought it worked. In decomposed color, IDL takes the
number and decomposes it into three single byte quantities, the least
significant is the red number, the next most significant is the green
number and the most significant is the blue number. It then uses these
three numbers and looks up the color in the current color table. Since
this is usually the gray scale, where the color indices map to
themselves, the result is the same as if you specified the color
values directly, with no 'color table' mediation.
But, if you have loaded a different color table, you should see
whatever color triple appears in the location given by the three
'decomposed' color numbers.
So, if you do the following
IDL> loadct,3 ; red temperature
IDL> tvlct,transpose( [0,255,0] ),1
IDL> plot,indgen(10),color='000100'x
You should see a y=x line in pure green. Right?
But I don't. I see nothing! What is wrong with my understanding?
Here's the result of an IDL> help,/device
Available graphics_devices: CGM HP LJ NULL PCL PRINTER PS REGIS TEK X Z
Current graphics device: X
Server: X11.0, Silicon Graphics, Release 6300
Display Depth, Size: 24 bits, (1280,1024)
Visual Class: TrueColor (4)
Bits Per RGB: 8
Physical Color Map Entries (Used / Total): 256 / 256
Colormap: Private, 16777216 colors. Translation table: Bypassed
Graphics pixels: Decomposed, Dither Method: Ordered
Write Mask: 16777215 (decimal) ffffff (hex)
Graphics Function: 3 (copy)
Current Font: <default>, Current TrueType Font: <default>
Default Backing Store: Pixmap.
Window Status: ---------------------
id typ( x, y, backing store) id typ( x, y, backing store)
32: Win( 640, 512, Pixmap) 0: Win( 640, 512, Pixmap)
To tell you the truth, this looks more like what I always called
'direct' color, namely that you specify the colors directly without
mediation of any colortable. My suspicion is made more substantial
when I attempt David Fannings example from his web page on 24 bit
decomposed color.
IDL> loadct,34
IDL> plot,indgen(10),color='00ffff'x
produces a yellow plot, not the purple that it should produce given
the 'color table'
Perhaps this is an SGI thing?
whd
By the by, I have a vector plotter I use alot, but it's effectively a
rewrite of velovect. The reason I got into the decomposed color morass
is because it uses some truecolor code that I was unsure about, since
I hacked it in pretty quick, and in checking it out against the 'font
of all color wisdom' that is our David, I found this discrepency.
|
|
|
|
| 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 @
|
|
|
|
| Re: device,decomposed=1 question [message #14671 is a reply to message #14586] |
Sat, 13 March 1999 00:00 |
bowman
Messages: 121
Registered: September 1991
|
Senior Member |
|
|
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.
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 @
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
