| IDL Color Blues [message #9683] |
Mon, 11 August 1997 00:00  |
wonko
Messages: 22
Registered: March 1997
|
Junior Member |
|
|
I tend to loose
The colors I choose
I got the IDL blues
The colors are flashing
The session is crashing
Labels have strange sizing rules
The online help won't work:
The display becomes weird
And the scrollbars are of no use
[guitar solo]
IDL 5 behaves bad
My widgets go mad
Yeah, I tell ya, I got the ol' IDL blues
Yes, I'm okay, just too many IDL problems today, maybe I also drank too
much tea. But why does the IDL online help scroll nearly two pages down
if I press the arrows, and not even one when I click between scrollbar
and arrow? Why do I sometimes have to mark the text to make it visible?
Why do my widgets size themselves wrong in IDL5?
Problem of the day: When there are too few free color cells for my IDL
application, I use the COLORS keyword in the first WINDOW command to
create my own color table with as many colors I want.
Now, is there a way to tell IDL which colors to take, and to keep some
of the lower color cells intact? That's where the system colors are, and
the colors of IDL's widgets.
It is very annoying when the display flashes when I enter and leave
windows. And the other application that has all the colors (it's another
IDL session, BTW) doesn't even have open windows at the time, so I would
not notice any flashing.
Sun UltraSparc, Solaris 2.5.
Alex, waiting for IDL 5.0.2
--
Alex Schuster Wonko@weird.cologne.de PGP Key available
alex@pet.mpin-koeln.mpg.de
|
|
|
|
| Re: IDL Color Blues [message #9743 is a reply to message #9683] |
Thu, 14 August 1997 00:00  |
Alex Schuster
Messages: 124
Registered: February 1997
|
Senior Member |
|
|
David Foster wrote:
> You might try putting the following in your
> /usr/openwin/lib/Xdefaults (or .Xdefaults) file:
>
> Idl*colors: -10
>
> This tells IDL to reserve 10 colors before grabbing color indices,
> thereby sparing colors used by the system.
I tried this on some of our 8-bit Suns, but didn't notice any change.
I started an IDL session, opened a window, and IDL grabbed all available
colors. Okay so far.
Then I starten another session, and opened a window with COLORS=50. When
I moved the mouse into the window, the color table was changed, and the
50 colors allocated the first 50 cells.
Maybe this problem related to OpenWindows 3.4? (No, I did not forget to
xrdb the .Xdefaults file.)
BTW, where does one find information about the entries in the .Xdefaults
file? The only iformation I found was in
$IDL_DIR/resource/X11/lib/X11/app-defaults/Idl, it wasn't of much help.
Lines like
! Size, resize behavior of the File Selection box, dialog_pickfile()
Idl*XmFileSelectionBox.resizePolicy: XmRESIZE_GROW
Idl*XmFileSelectionBox.width: 400
look promising.
Alex
--
Alex Schuster Wonko@weird.cologne.de PGP Key available
alex@pet.mpin-koeln.mpg.de
|
|
|
|
| Re: IDL Color Blues [message #9764 is a reply to message #9683] |
Tue, 12 August 1997 00:00 |
David Foster
Messages: 341
Registered: January 1996
|
Senior Member |
|
|
Alex Schuster wrote:
>
> Aviv Gladman wrote:
>
>> We used to have the colourmap swapping problem on our 24-bit Ultras, which
>> kind of surprised me as there is really no concept of colourmaps for a
>> 24-bit display. In DirectColor mode, IDL tries to grab all 16 million odd
>> colours into a private colourmap, resulting in the flashing. You can
>> probably solve you problem using the DEVICE, TRUECOLOR=24 . the DEVICE,
>> DECOMPOSED=0 or DEVICE, DECOMPOSED=1 commands can then be used to turn
>> on/off 8-bit colour mapping (in one mode, 24-bit colours are mapped to the
>> loaded 8-bit colour palette so TV and PLOTS use a 256 colour palette that
>> can be loaded via XLOADCT, in the other mode, 24-bit colours are as
>> expected, RGB settings, and images always seem to use an greyscale
>> palette in this mode). When swapping colourmaps in 8-bit emulation, you
>> have to redraw the window to get the colour change to have an effect
>> (since you aren't actually changing the colour palette, you're just
>> changing the RGB colour mappings).
>
You might try putting the following in your
/usr/openwin/lib/Xdefaults (or .Xdefaults) file:
Idl*colors: -10
This tells IDL to reserve 10 colors before grabbing color indices,
thereby sparing colors used by the system.
Dave
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
David S. Foster Univ. of California, San Diego
Programmer/Analyst Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of Psychiatry
(619) 622-5892 8950 Via La Jolla Drive, Suite 2200
La Jolla, CA 92037
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
| Re: IDL Color Blues [message #9769 is a reply to message #9683] |
Tue, 12 August 1997 00:00 |
Alex Schuster
Messages: 124
Registered: February 1997
|
Senior Member |
|
|
Aviv Gladman wrote:
> We used to have the colourmap swapping problem on our 24-bit Ultras, which
> kind of surprised me as there is really no concept of colourmaps for a
> 24-bit display. In DirectColor mode, IDL tries to grab all 16 million odd
> colours into a private colourmap, resulting in the flashing. You can
> probably solve you problem using the DEVICE, TRUECOLOR=24 . the DEVICE,
> DECOMPOSED=0 or DEVICE, DECOMPOSED=1 commands can then be used to turn
> on/off 8-bit colour mapping (in one mode, 24-bit colours are mapped to the
> loaded 8-bit colour palette so TV and PLOTS use a 256 colour palette that
> can be loaded via XLOADCT, in the other mode, 24-bit colours are as
> expected, RGB settings, and images always seem to use an greyscale
> palette in this mode). When swapping colourmaps in 8-bit emulation, you
> have to redraw the window to get the colour change to have an effect
> (since you aren't actually changing the colour palette, you're just
> changing the RGB colour mappings).
Aviv,
thanks for your answer. But the problem is not so much the swapping of
the
colormaps. It's that when I tell IDL to take 32 colors, it takes the
absolute
color cells 0-31. This is where some system colors are, eg. colors for
the
window manager, and the color of IDL's widgets. If I could tell IDL to
take,
say, the color cells 224-255, the swapping would affect only the
application
that uses those colr cells.
Sorry, I wasn't very clear there.
At the UltraSparc with 24-bit display the problem can be solved by
DEVICE,
PSEUDO=8. The results are similar as with DEVICE, TRUE_COLOR=24 and
DEVICE, DECOMPOSED=0, but the display deems to be faster.
However, we also have 8-bit SUNs, and there it no way to prevent the
swapping.
Alex
|
|
|
|
| Re: IDL Color Blues [message #9771 is a reply to message #9683] |
Tue, 12 August 1997 00:00 |
Aviv Gladman
Messages: 8
Registered: August 1997
|
Junior Member |
|
|
We used to have the colourmap swapping problem on our 24-bit Ultras, which
kind of surprised me as there is really no concept of colourmaps for a
24-bit display. In DirectColor mode, IDL tries to grab all 16 million odd
colours into a private colourmap, resulting in the flashing. You can
probably solve you problem using the DEVICE, TRUECOLOR=24 . the DEVICE,
DECOMPOSED=0 or DEVICE, DECOMPOSED=1 commands can then be used to turn
on/off 8-bit colour mapping (in one mode, 24-bit colours are mapped to the
loaded 8-bit colour palette so TV and PLOTS use a 256 colour palette that
can be loaded via XLOADCT, in the other mode, 24-bit colours are as
expected, RGB settings, and images always seem to use an greyscale
palette in this mode). When swapping colourmaps in 8-bit emulation, you
have to redraw the window to get the colour change to have an effect
(since you aren't actually changing the colour palette, you're just
changing the RGB colour mappings).
Aviv S. Gladman
On 11 Aug 1997, Alex Schuster wrote:
> [poem snipped, hey, we have to save bandwith, right?]
>
> Problem of the day: When there are too few free color cells for my IDL
> application, I use the COLORS keyword in the first WINDOW command to
> create my own color table with as many colors I want.
> Now, is there a way to tell IDL which colors to take, and to keep some
> of the lower color cells intact? That's where the system colors are, and
> the colors of IDL's widgets.
> It is very annoying when the display flashes when I enter and leave
> windows. And the other application that has all the colors (it's another
> IDL session, BTW) doesn't even have open windows at the time, so I would
> not notice any flashing.
>
> Sun UltraSparc, Solaris 2.5.
>
> Alex, waiting for IDL 5.0.2
> --
> Alex Schuster Wonko@weird.cologne.de PGP Key available
> alex@pet.mpin-koeln.mpg.de
>
>
|
|
|
|
| Re:IDL Color Blues [message #9829 is a reply to message #9683] |
Fri, 15 August 1997 00:00 |
Paul Crain
Messages: 1
Registered: August 1997
|
Junior Member |
|
|
Alex,
Since you are using a Sun UltraSparc, your problem with the
colors may primarily be that the window manager is still using
pseudoColor even though your system supports trueColor.
If you copy the file /usr/dt/config/Xservers to
/etc/dt/config (you may have to create a config directory)
and edit the last line to read
:0 Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner
-dev /dev/ffb0 defdepth 24
your desktop colors should become trueColor colors. This will
work even if you are still using openwindows. You may have to
reboot for the change to take place.
Paul
Paul Crain
p.d.crain@larc.nasa.gov
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
