| Re: Help with moving from 8 to 24 bit colour [message #17189] |
Thu, 23 September 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Surendar Jeyadev (jeyadev@wrc.xerox.com) writes:
> I have long been interested in getting your book to step
> beyond my "plain graph" skills with PV Wave. Is this kind
> of thing written up there (see my earlier complaint above!)?
> I guess I will buy it anyway!!
Just about the only place it *is* written up, as far as I
can tell. :-)
I sell quite a few books to PV-Wavers. No returns so
far. (Knock on wood.) :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Help with moving from 8 to 24 bit colour [message #17190 is a reply to message #17189] |
Thu, 23 September 1999 00:00  |
jeyadev
Messages: 78
Registered: February 1995
|
Member |
|
|
In article <MPG.12533f6852f3ee22989906@news.frii.com>,
David Fanning <davidf@dfanning.com> wrote:
> Surendar Jeyadev (jeyadev@wrc.xerox.com) writes:
>
>> 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!),
>
> What this does is make your expensive new hardware act
> like it was last year's model. :-)
>
> But, I agree, this will solve all of your problems and
> you can carry on like you have been.
Yes, I recognized that that is what it would do. But, it was done
in the interest of time. I am still learning ...
> Should you ever have the need or desire to see more
> than 256 colors simultaneously, however, I recommend
> you use the TrueColor visual class and not the
> DirectColor visual class, which appears to be the
> default for your machine. DirectColor confuses all
> of us. :-)
Glad to know that even you are confused by this. The trouble is
that I cannot find a self contained book that can help. Being
sent off to learn about X windows and its graphical libraries
to do a reasonably simple analysis is too much! But, I will
continue to bite away ...`
> In a PseudoColor visual class you specify a color by
> specifying an index into a color table. Suppose, for
> example, we load the color yellow into color index
> 10 of the color table. Yellow is full red and full
> green, but no blue. We could load those values in
> the current color table like this:
>
> TVLCT, 255, 255, 0, 10
>
> To draw a plot in that yellow color, we would do this:
>
> Plot, data, Color=10
>
> We have specified the color as an *index* into the color
> table. If we load a new color into index 10, then the
> graphic display is automatically updated, since the
> display is "tied to" or "connected to" the index.
I remember this from the SunView to OpenWindows transition. In
those Good Old Days, Sun actually sent reasonable verbose
hard copy documentation explaining how all this worked! I
actually learnt something!!
> If we want a yellow color in a 24-bit environment, we
> don't use an index, but we specify the color directly.
> .....
Thanks a lot for this bit. But, guess what? I have a new
question for you.
I have long been interested in getting your book to step
beyond my "plain graph" skills with PV Wave. Is this kind
of thing written up there (see my earlier complaint above!)?
I guess I will buy it anyway!!
thanks, again
sj
--
Surendar Jeyadev jeyadev@wrc.xerox.com
|
|
|
|
| Re: Help with moving from 8 to 24 bit colour [message #17194 is a reply to message #17189] |
Wed, 22 September 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Surendar Jeyadev (jeyadev@wrc.xerox.com) writes:
> 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!),
What this does is make your expensive new hardware act
like it was last year's model. :-)
But, I agree, this will solve all of your problems and
you can carry on like you have been.
Should you ever have the need or desire to see more
than 256 colors simultaneously, however, I recommend
you use the TrueColor visual class and not the
DirectColor visual class, which appears to be the
default for your machine. DirectColor confuses all
of us. :-)
In a PseudoColor visual class you specify a color by
specifying an index into a color table. Suppose, for
example, we load the color yellow into color index
10 of the color table. Yellow is full red and full
green, but no blue. We could load those values in
the current color table like this:
TVLCT, 255, 255, 0, 10
To draw a plot in that yellow color, we would do this:
Plot, data, Color=10
We have specified the color as an *index* into the color
table. If we load a new color into index 10, then the
graphic display is automatically updated, since the
display is "tied to" or "connected to" the index.
If we want a yellow color in a 24-bit environment, we
don't use an index, but we specify the color directly.
That is to say, we must specify the color triple as
a number. Now, how could that be? Well, the number is
going to be a long integer, and we are going to
"decomposed" that number into three components that
will specify the red, green, and blue component of the
color we want. The lowest 8 bits of the number will
be used for red, the next 8 bits for green, and the
next 8 bits for blue. So a yellow color will have
the lowest 16 bits set, but none of the high bits
set. For example,
yellow = 2L^16 - 1
Plot, data, Color=yellow
Another way to write this is as a hexadecimal number:
Plot, data, Color='00FFFF'xL
Colors that are expressed directly are not tied or
connected to an index, so if we change the colors loaded
at a particular index we don't affect display colors at
all. The only way they can be changed is if we change
them directly by specifying another color.
In IDL you can turn this color decomposition off by
using the DEVICE, DECOMPOSED=0 syntax. With color
decomposition off, IDL treats the color value as if
it were an index and looks the color up in a color
table. In other words, IDL "acts" like it was an
8-bit device. Although not to the extend that display
colors are automatically updated when we change
colors in the color table.
In PV-Wave, it looks to me like you actually *make*
it an 8-bit device. In other words, it looks like
you can't turn color decomposition off when in 24-bit
mode, but you *have* to use decomposed color values.
It's hard to say which protocol is better. I would
say it is probably easier for PV-Wave users to use
old programs when they move to 24-bit machines, but
at the total expense of not being able to take
advantage of 24-bit color. (If they want 24-bit
color, of course, they can close all windows and
change the visual class, but then they have none
of the advantages of 8-bit color.)
IDL users get to take advantage of 24-bit colors
and they can still use old programs, but they have
to learn new techniques for automatic update of
their graphics displays when they change color
tables, since in 24-bit color the graphics display
colors are no longer tied to a color index.
I guess you take your picks and take your chances.
But that's color in a nutshell. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| 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
|
|
|
|
| Re: Help with moving from 8 to 24 bit colour [message #17211 is a reply to message #17194] |
Tue, 21 September 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
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.
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
is a *very* old keyword, I think. If you are sure,
could you show us the result of a "Help, /Device".
Cheers,
David
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".
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Help with moving from 8 to 24 bit colour [message #17212 is a reply to message #17211] |
Tue, 21 September 1999 00:00 |
jeyadev
Messages: 78
Registered: February 1995
|
Member |
|
|
In article <7s7n36$dqf$2@alster.dkrz.de>,
Martin.Schultz@dkrz.de <m218003@modell3.dkrz.de> wrote:
> In article <7s6au2$nsu$1@news.wrc.xerox.com>,
> jeyadev@wrc.xerox.com (Surendar Jeyadev) writes:
>
>> But, I do notice that when a start a Wave session and draw a simple plot,
>> the axes, labels, etc. are in red instead of white, while the lines of
>> the graph itself (the data) are white, as required.
>
> device,decomposed=0
> and get the GETCOLOR program from David Fanning:
> http://www.dfanning.com
>
>
> does that get you any further?
WAVE> device, decomposed=0
% Keyword DECOMPOSED not allowed in call to: DEVICE
% Execution halted at $MAIN$ (DEVICE).
I guess that I can just run the first programme twice and get over the
problem. Better still, I can put a dummy plot programme in my startup
file to just do a dumb plot, as I find that I get the right colours
in all subsequent plots -- even when I open new windows.
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.
thanks for the hints
--
Surendar Jeyadev jeyadev@wrc.xerox.com
|
|
|
|
|
|
| Re: Help with moving from 8 to 24 bit colour [message #17218 is a reply to message #17211] |
Tue, 21 September 1999 00:00 |
m218003
Messages: 56
Registered: August 1999
|
Member |
|
|
In article <7s6au2$nsu$1@news.wrc.xerox.com>,
jeyadev@wrc.xerox.com (Surendar Jeyadev) writes:
> I assume that this question has been asked, and answered, many times,
> but I cannot find an FAQ.
>
http://www.ivsoftware.com:8000/FAQ/default.htm
> SIRD background. I found that that the problem arose from
> the line
>
> max_colors = !d.n_colors
max_colors = !d.n_colors < 256 is much better ;-)
> But, I do notice that when a start a Wave session and draw a simple plot,
> the axes, labels, etc. are in red instead of white, while the lines of
> the graph itself (the data) are white, as required.
device,decomposed=0
and get the GETCOLOR program from David Fanning:
http://www.dfanning.com
does that get you any further?
Martin
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 441787 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
