| Re: Help with moving from 8 to 24 bit colour [message #17195 is a reply to message #17194] |
Wed, 22 September 1999 00:00   |
jeyadev
Messages: 78
Registered: February 1995
|
Member |
|
|
In article <MPG.1251e8384ce5356c989904@news.frii.com>,
David Fanning <davidf@dfanning.com> wrote:
> Surendar Jeyadev (jeyadev@wrc.xerox.com) writes:
>
>> Was the GETCOLOR suggestion in answer to the second question that I
>> asked (i.e. how do I get to see that palette?)? From what I see, that
>> is not what I want. I want to be able to see the 255 colours in the
>> table that I am using. When I issue the color_pallete command, I get
>> a very thin window which is blank.
>
> I don't know the Color_Palette program at all, but from your
> description I am almost positive the author uses a TV
> command in there. Your problem could be fixed, probably,
> by adding a TRUE=1 (or whatever) keyword to that TV command.
color_palette is a standard PV Wave procedure that opens a window and
presents a palette of the colours of the current colour table in a
chequerboard format. In the 8 bit world, you get about 234 colours,
and examples are given in the (online) manual. I am
looking up the latest Wave Reference Manuals on the website to see if
I can get it to display the colours in the 24 bit mode as well. What I
do know, from my application, is that the colour tables do exist and
I can load the different tables and the display updates just as it did
in the 8 bit world on my (ex)Sparc20. The fundamental problem seems to be
with the fact that the color_palette procedure also uses the !d.n_colors
variable:
yboxes=fix(!d.n_colors/(8*int))
for the number of colours to be displayed (int = 2 if !d.n_colors > 128,
1 otherwise). I guess that this throws off the procedure and that
!d.table_size would be a better choice. After some messing around, I found
that the solution is as follows:
device, pseudo_color=8
I am not sure what this does (that is part of today's education!), but
when followed by the 'color_palette' command, I get the colors available
*and* the palette is updated when I issue a 'loadct' command to load a
new colour table.
> Another alternative is to download the ancient CINDEX
> program from my IDL 4 archive file. This program is so
> old I believe it will still run in PV-Wave. :-)
>
> ftp://ftp.dfanning.com/pub/dfanning/idl_examples/archive4/ci ndex.pro
>
> If this program shows all red colors when you have a
> color table loaded, then you are going to have to figure
> out some way to turn color decomposition off. Are you
> *sure* Device, Decomposed=0 didn't work for you. That
Now, I do not what 'decomposition' is -- this the the second education
project for the day. I have never been interested in colour as the output
in hard copy format usually gets copied (note the employer!) and things
loose all meaning. However, I do have a number of applications to
display 3d data, and as long as they work, I am happy. I should add that
they are not terribly sophisticated and I can live with 8 bit colour!
> is a *very* old keyword, I think. If you are sure,
> could you show us the result of a "Help, /Device".
No, it did not work. And here is the transcript:
WAVE> device, Decomposed=0
% Keyword DECOMPOSED not allowed in call to: DEVICE
% Execution halted at $MAIN$ (DEVICE).
WAVE> info, /dev
Available graphics_devices: CGM HP NULL PCL PS REGIS TEK X Z
Current graphics device: X
Server: X11.0, Sun Microsystems, Inc., Release 3600
Display Depth, Size: 24 bits, (1280,1024)
Visual Class: DirectColor (5)
Bits Per RGB: 8
Physical Color Map Entries (Used / Total): 256 / 256
Colormap: Private, 16777216 colors. Translation table: Enabled
Dither Method: Ordered
Write Mask: 16777215 (decimal) ffffff (hex)
Graphics Function: 3 (copy)
Current Font: <default>
Default Backing Store: Requested From Server.
WAVE> device, pseudo_color=8
WAVE> info, /dev
Available graphics_devices: CGM HP NULL PCL PS REGIS TEK X Z
Current graphics device: X
Server: X11.0, Sun Microsystems, Inc., Release 3600
Display Depth, Size: 8 bits, (1280,1024)
Visual Class: PseudoColor (3)
Bits Per RGB: 8
Physical Color Map Entries (Used / Total): 256 / 256
Colormap: Private, 256 colors. Translation table: Enabled
Dither Method: Ordered
Write Mask: 255 (decimal) ff (hex)
Graphics Function: 3 (copy)
Current Font: <default>
Default Backing Store: Requested From Server.
WAVE>
The pseudo_color=8 setting seems to have changed the Visual Class (whatever
*that* may be!). If I try the true_color=24, this is what I get:
WAVE> device, true_color=24
WAVE> info, /dev
Available graphics_devices: CGM HP NULL PCL PS REGIS TEK X Z
Current graphics device: X
Server: X11.0, Sun Microsystems, Inc., Release 3600
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: Enabled
Dither Method: Ordered
Write Mask: 16777215 (decimal) ffffff (hex)
Graphics Function: 3 (copy)
Current Font: <default>
Default Backing Store: Requested From Server.
WAVE>
> P.S. I would also make sure (if you want 24-bit color) that
> you get a TrueColor visual class. Something like this, I think:
>
> Device, True_Color=24
>
> You will have better defined behavior in this class than in
> a DirectColor visual class. You can determine what class you
> have by opening a graphics window and typing "Help, /Device".
Tried it -- see above -- but it does not give me the colors in
the table when I run colour palette.
In short, it appears that I will still be in the 8 bit world as far
as Wave is concerned. I am not even sure what 24 bit colour will
buy for me as far as Wave is concerned. I do need it for some other
applications.
Thanks for all your help. Clearly, a considerable of ignorance has to be
dispelled first. I will start reading the manual about colour depth.
--
Surendar Jeyadev jeyadev@wrc.xerox.com
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
