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.
|
|
|