Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
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.
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 @
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 @