| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29177] |
Thu, 07 February 2002 10:32  |
Nigel Wade
Messages: 286
Registered: March 1998
|
Senior Member |
|
|
Robert Stockwell wrote:
>
>
> Nigel Wade wrote:
>
>> Robert Stockwell wrote:
>>
>>
>>> Greetings all,
>>> its been hours since a post about colors, so I
>>> figured I volunteer a post.
>>>
>>> I have IDL 5.5 on Redhat Linux 7.2 running KDE
>>> in 24bit color mode.
>>>
>>
>> Snap.
>
>
> Snap?
>
Ditto, the same.
Don't tell me you never played snap as a kid? Maybe it's called something
else over the pond. How does that saying go "two countries separated by a
common language"?
>
>> This incantation seems to work (xloadct displays correctly):
>>
>> device,true=24
>> window,/pixmap &wdelete
>> device,bypass_translation=0
>
>
>
> I did put this in my startup. (Of course, _after_ posting the message
> to the newsgroup, a coworker pointed out the bug report on rsinc.com,
> which I had failed to find with my searches).
That's strange. Do you do a device,decomposed=0 first? I have a feeling
that fixes the visual to the default.
>
> This does NOT solve my problem, although it does make it better.
> Now I get greyscale, and any color table commands are ignored,
> and xloadct only has greyscale, regardless of which table I choose.
> ....WHAT THE!?? Hey, when I put the cursor on the colorbar of
> xloadct, I do get the IDL color table, but for the entire desktop!
> That is to say, the plot window now looks correct, but the entire
> desktop is also in that color table, and thus gets wacky colors
> assigned to everything (i.e other programs are now all blue, some
> have black on blue fonts and are unreadable, etc). When I move the
> cursor off the colorbar in Xloadct, it goes back to normal (normal
> desktop colors, and greyscal IDL plot window).
> Hmmmmm, we're on to something here.
Yep, that's DirectColor. Just like PsuedoColor for 8 bit.
It does seem strange that you are unable to force it into TrueColor.
>
> PS anyone else amazed that RSI let this broken "24bit color on linux"
> out the door. OOPS! I think we should chip in and by them a linux
> computer that they can at least run the new releases before they ship!
>
I can understand it getting shipped. I would, however, have hoped they
could have released a patch for it by now.
--
-----------------------------------------------------------
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523568, Fax : +44 (0)116 2523555
|
|
|
|
| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29180 is a reply to message #29177] |
Thu, 07 February 2002 09:34  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Jaco van Gorkom (j.c.van.gorkom@fz-juelich.de) writes:
> That is the situation for video hardware which handles 32-bit color.
> In 8-bit color hardware (think government-funded research) there can only
> be 256 different colors on the screen at any one time. So if I ask IDL to
> allocate 256 colors, it uses a private colormap. This causes color flashing
> when moving in or out of plot windows and/or draw widgets. Result: when
> looking at a plot window in the correct colors, the black and gray/white of
> the slider bars appear in some of the first 20 colors of the color map.
> Usually
> black on black. With the mouse on the slider button, the general desktop
> color
> map is active. Ergo I do not see the plot in the color map I am adjusting.
> Or am I missing something?
Oh, I see what you are talking about. Yes, allocating
256 colors on an 8-bit X Windows system will give you
color flashing problems. This is entirely due to the
way X Windows works, and has nothing to do with IDL.
But it *is* a problem, certainly.
> P.S.: I just got this new PC last week. It seems that those cheap
> videocards
> with 1MB memory are no longer made, so now they got me a whopping 32MB.
> I'll have to start writing those 5-6 lines of code soon! xcolors.pro, isn't
> it?
Something like that. :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29181 is a reply to message #29180] |
Thu, 07 February 2002 09:33 |
Robert Stockwell
Messages: 74
Registered: October 2001
|
Member |
|
|
David Fanning wrote:
> Robert Stockwell (rgs1967@hotmail.com) writes:
>> PS anyone else amazed that RSI let this broken "24bit color on linux"
>> out the door. OOPS! I think we should chip in and by them a linux
>> computer that they can at least run the new releases before they ship!
>>
>
> There is always huge pressure around a software release to
> either (1) meet the ship date, or (2) fix the software.
Tell me about it :)
I often do programming as an independent contractor and
there has never been a case where the client
has allocated enough time to "properly" finish a project.
There is always a decision to be made on what features and
functionality will be dropped from the final version.
But broken linux/color seems to be a rather large bug to slip by.
I'm not much a a linux user, but it seems that 24 bit color
in linux would be quite common.
> Fixing the software is never finished, so eventually
> you just say "What the hell, enough is enough" and
> ship the software. It's like writing a book in that
> respect, which is why editor's impose deadlines
>
> But shipping with broken color and no help files is
> making the decision at the completely wrong end of
> the continuum, in my opinion. I'd have been much more
> content to wait another couple weeks or even a month
> for a more complete product. I feel embarrassed for
> them, and I don't even work there.
I agree. I was embarrasses when I helped a colleague convert
some simple matlab code to IDL. He read in some data, and
created an image overlayed on a map, and the results were
terrible (due to the crazy colors). He interpreted it as
an error in reading the data, when in fact I had to inform
him that it was merely broken IDL. I don't think we won
over a user from Matlab.
(Especially since I had in the past (jokingly) chided him
for using a toy scripting language like matlab, when real
scientists used the awesome programming power of objects
and pointers with IDL. lol )
But I suppose RSI is telling us that color is only for
the style-over-substance crowd.
Cheers,
bob stockwell
aka bobby greyscale
|
|
|
|
|
|
|
|
|
|
| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29188 is a reply to message #29187] |
Thu, 07 February 2002 08:01 |
Jaco van Gorkom
Messages: 97
Registered: November 2000
|
Member |
|
|
"Robert Stockwell" <rgs1967@hotmail.com> wrote in message
news:3C6291D0.4020500@hotmail.com...
<skipped some color stuff...>
> This does NOT solve my problem, although it does make it better.
> Now I get greyscale, and any color table commands are ignored,
> and xloadct only has greyscale, regardless of which table I choose.
> ....WHAT THE!?? Hey, when I put the cursor on the colorbar of
> xloadct, I do get the IDL color table, but for the entire desktop!
> That is to say, the plot window now looks correct, but the entire
> desktop is also in that color table, and thus gets wacky colors
> assigned to everything (i.e other programs are now all blue, some
> have black on blue fonts and are unreadable, etc). When I move the
> cursor off the colorbar in Xloadct, it goes back to normal (normal
> desktop colors, and greyscal IDL plot window).
> Hmmmmm, we're on to something here.
I remember once working in a window manager in which the IDL plot
windows were prevented from getting the focus. The cause was some
setting somewhere in the window manager configuration. Sorry, I
cannot recall more details, but this definitely matches with the
behaviour your are describing. (although I would only have expected
this on 8-bit color)
Funny isn't it, this color behaviour of xloadct? It seems to be the only
way for widgets to handle color on 256-color hardware. No way of
seeing the color bar or the plots/images which your are trying to adjust
while adjusting the sliders.
Hope this helps a little,
Jaco
|
|
|
|
|
|
| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29192 is a reply to message #29190] |
Thu, 07 February 2002 06:54 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Robert Stockwell (rgs1967@hotmail.com) writes:
> PS anyone else amazed that RSI let this broken "24bit color on linux"
> out the door. OOPS! I think we should chip in and by them a linux
> computer that they can at least run the new releases before they ship!
There is always huge pressure around a software release to
either (1) meet the ship date, or (2) fix the software.
Fixing the software is never finished, so eventually
you just say "What the hell, enough is enough" and
ship the software. It's like writing a book in that
respect, which is why editor's impose deadlines
But shipping with broken color and no help files is
making the decision at the completely wrong end of
the continuum, in my opinion. I'd have been much more
content to wait another couple weeks or even a month
for a more complete product. I feel embarrassed for
them, and I don't even work there.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29194 is a reply to message #29193] |
Thu, 07 February 2002 06:40 |
Robert Stockwell
Messages: 74
Registered: October 2001
|
Member |
|
|
Nigel Wade wrote:
> Robert Stockwell wrote:
>
>
>> Greetings all,
>> its been hours since a post about colors, so I
>> figured I volunteer a post.
>>
>> I have IDL 5.5 on Redhat Linux 7.2 running KDE
>> in 24bit color mode.
>>
>
> Snap.
Snap?
> This incantation seems to work (xloadct displays correctly):
>
> device,true=24
> window,/pixmap &wdelete ; fix the IDL 5.5/Linux colour problem
> device,bypass_translation=0
I did put this in my startup. (Of course, _after_ posting the message
to the newsgroup, a coworker pointed out the bug report on rsinc.com,
which I had failed to find with my searches).
This does NOT solve my problem, although it does make it better.
Now I get greyscale, and any color table commands are ignored,
and xloadct only has greyscale, regardless of which table I choose.
....WHAT THE!?? Hey, when I put the cursor on the colorbar of
xloadct, I do get the IDL color table, but for the entire desktop!
That is to say, the plot window now looks correct, but the entire
desktop is also in that color table, and thus gets wacky colors
assigned to everything (i.e other programs are now all blue, some
have black on blue fonts and are unreadable, etc). When I move the
cursor off the colorbar in Xloadct, it goes back to normal (normal
desktop colors, and greyscal IDL plot window).
Hmmmmm, we're on to something here.
Anyways, I think I will have to change my config to only use 16 bit colors,
as Reimar suggested.
Thanks for the response.
Cheers,
bob
PS anyone else amazed that RSI let this broken "24bit color on linux"
out the door. OOPS! I think we should chip in and by them a linux
computer that they can at least run the new releases before they ship!
>
>> image = dist(100)
>> loadct,13
>>
>> shade_surf,image,shade=bytscl(image)
>>
>>
>
> This shows a shaded surface with red at the peak, going down to blue at the
> corners. The axes are in red. Is this what was intended?
Yes I think so. Not very exciting or nice looking, but it was
a watered down snip of code that manifested the problem.
(on that color table, I think 255 is red, hence the red axis
instead of white.) You have a 'white on black' background I guess,
my preference is to always flip white and black so my plots are
black on white, so it looked a little different to me.
|
|
|
|
| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29199 is a reply to message #29194] |
Thu, 07 February 2002 02:23 |
Nigel Wade
Messages: 286
Registered: March 1998
|
Senior Member |
|
|
Robert Stockwell wrote:
> Greetings all,
> its been hours since a post about colors, so I
> figured I volunteer a post.
>
> I have IDL 5.5 on Redhat Linux 7.2 running KDE
> in 24bit color mode.
Snap.
>
> I cannot get proper colors to show up on screen
> (they are fine in postscript files though).
It can be somewhat troublsome.
>
> I have tried the conventional wisdom, ensuring I
> am in 24 bit mode, setting the decomposed keyword, etc.
> But nothing works. I have gone through every keyword
> that device will take (true_color=24, direct_color=24,
> translation, etc), and toggled all the relevant
> sounding ones to no avail (it seems to be in Direct
> Color mode no matter what I do, note below where I
> set true_color = 24, but it is still in direct color).
>
Are you doing this before you create any windows? Once IDL has created a
window, even if it hasn't actually displayed it on the screen yet, the X
visual is decided and cannot be changed. This is the reason it's usually
placed in the idl_startup file, so you know it's done before any windows
can be created.
This incantation seems to work (xloadct displays correctly):
device,true=24
window,/pixmap &wdelete ; fix the IDL 5.5/Linux colour problem
device,bypass_translation=0
> image = dist(100)
> loadct,13
>
> shade_surf,image,shade=bytscl(image)
>
This shows a shaded surface with red at the peak, going down to blue at the
corners. The axes are in red. Is this what was intended?
--
-----------------------------------------------------------
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523568, Fax : +44 (0)116 2523555
|
|
|
|
| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29202 is a reply to message #29199] |
Thu, 07 February 2002 02:05 |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Robert Stockwell wrote:
>
> Greetings all,
> its been hours since a post about colors, so I
> figured I volunteer a post.
>
> I have IDL 5.5 on Redhat Linux 7.2 running KDE
> in 24bit color mode.
>
> I cannot get proper colors to show up on screen
> (they are fine in postscript files though).
>
> I have tried the conventional wisdom, ensuring I
> am in 24 bit mode, setting the decomposed keyword, etc.
> But nothing works. I have gone through every keyword
> that device will take (true_color=24, direct_color=24,
> translation, etc), and toggled all the relevant
> sounding ones to no avail (it seems to be in Direct
> Color mode no matter what I do, note below where I
> set true_color = 24, but it is still in direct color).
>
> Here is sample code, where I get a yellow rectangle over
> the whole plot window, and the surface is blue.
>
> Anyone have any ideas of what is going on here?
>
> Cheers,
> bob stockwell
>
Dear Bob,
only on one of our machine the workaraound was working.
I don't know why.
I have changed to 16 bit. This works for us. No problems
at the moment.
Reimar
--
Reimar Bauer
Institut fuer Stratosphaerische Chemie (ICG-1)
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
http://www.fz-juelich.de/icg/icg1/
============================================================ ======
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_lib_intro.h tml
http://www.fz-juelich.de/zb/text/publikation/juel3786.html
============================================================ ======
|
|
|
|
|
|
| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29210 is a reply to message #29207] |
Wed, 06 February 2002 13:45 |
gary.hodgesREMOVE
Messages: 9
Registered: October 2001
|
Junior Member |
|
|
Robert Stockwell <rgs1967@hotmail.com> wrote:
: I have IDL 5.5 on Redhat Linux 7.2 running KDE
: in 24bit color mode.
Me too but with Gnome.
: I have tried the conventional wisdom, ensuring I
: am in 24 bit mode, setting the decomposed keyword, etc.
: But nothing works. I have gone through every keyword
: that device will take (true_color=24, direct_color=24,
: translation, etc), and toggled all the relevant
: sounding ones to no avail (it seems to be in Direct
: Color mode no matter what I do, note below where I
: set true_color = 24, but it is still in direct color).
For me it was suggested to put the above in a startup file which solved my
problem with color. I couldn't get no satisfaction putting those settings in
my actual code. Here is my startup file:
~>more .idl_startup
!PATH = '/usr/local/rsi/coyote:' + !PATH
DEVICE, TRUE_COLOR=24, Decomposed=0
When I plot to postscript I had to set Decomposed=1 in the code to get
color.
Good luck,
Gary -- That is just about everything I know about color.
|
|
|
|
| Re: ARG! Direct Color problem IDL 5.5/Linux (decomposed doesn't help) [message #29270 is a reply to message #29183] |
Thu, 07 February 2002 15:16 |
Andrew Cool
Messages: 219
Registered: January 1996
|
Senior Member |
|
|
Jaco van Gorkom wrote:
>
snip
>
> That is the situation for video hardware which handles 32-bit color.
> In 8-bit color hardware (think government-funded research) there can only
> be 256 different colors on the screen at any one time. So if I ask IDL to
> allocate 256 colors, it uses a private colormap. This causes color flashing
> when moving in or out of plot windows and/or draw widgets. Result: when
> looking at a plot window in the correct colors, the black and gray/white of
> the slider bars appear in some of the first 20 colors of the color map.
> Usually black on black. With the mouse on the slider button, the general desktop
> color map is active. Ergo I do not see the plot in the color map I am adjusting.
> Or am I missing something?
>
> Cheers,
> Jaco
I know your problem with the 8bit colour hardware in government-funded
research,
as my mob mainly used IDL under OpenVMS and Xterms for many years.
We gave up allowing the default allocation of 256 colours pretty quickly
too.
These days, most of us here allocate only 64 colours, and of that the
top dozen or
so are set to standard colours like red, orange,yellow,green, etc,
leaving about
50 colours for the actual colour scale.
By allocating only 64 colours, this allows us to open say 3-4 separate
IDL sessions
without any conflicting colour table problems or flashing windows as the
cursor
moves around the screen.
And we're not missing anything in terms of detail. Let's face it, with
256 colours,
can you really tell which shade of lime-green pixelA is, and compare
that exactly
to your colour bar legend? I'd say No - you just get a feel for the
value.
Less can sometimes be more when eyeballing colour plots. Trends in the
data are
just as visible, and you've always got the cursor readout if you need to
reference
pixelA back to the original data.
32 bits to represent 8 bit data might just be overkill ;-)
But then some people describe me as brain dead too.
Andrew
------------------------------------------------------------ ---------
Andrew D. Cool .->-.
Electromagnetics & Propagation Group `-<-'
Surveillance Systems Division Transmitted on
Defence Science & Technology Organisation 100% recycled
PO Box 1500, Salisbury electrons
South Australia 5108
Phone : 061 8 8259 5740 Fax : 061 8 8259 6673
Email : andrew.cool@dsto.defence.gov.au
------------------------------------------------------------ ---------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
