| Re: Color problems with Linux [message #15087] |
Wed, 21 April 1999 00:00 |
uk2
Messages: 8
Registered: June 1994
|
Junior Member |
|
|
Hi Brian,
I can tell you what I've discovered, but I'd also be grateful to hear
anyone else's view on this.
1. Are you running Linux in 8, 16, or 24 bits? If its 16, change it to
8. IDL doesn't do 16 bit. If it's 24, please help me get my machine to
run in 24-bit mode!
2. Are you running netscape concurrently? Try to limit Netscape's
color-hogging. I've aliased netscape to the following in my .cshrc file
which seems to work:
alias netscape 'netscape -no-about-splash -ncols 75'
3. I've noticed other 'bad' X-applications like x11amp that seem to be
color intensive. I don't know why.
I think it is a bit problem. If you drop to 8 bit, reboot, and run IDL
without any other applications you should be able to resolve this. If
this works, the next problem you'll have is that the display 'inverts'
on you either when you run two sessions of IDL concurrently or some
other color-hungry application.
Cheers, Pete Riley
Brian Jackel wrote:
> Greetings
>
> One of my co-workers is having problems with IDL 5.2
> under Red Hat Linux.
>
> After placing the following lines in her .Xdefaults file
>
> idl.gr_visual: PseudoColor
> idl.gr_depth: 8
>
> IDL starts up believing that it has 256 colors. The
> problem is that the color table as displayed on the
> screen contains a fixed random assortment of entries
> (at least a hundred, it's hard to tell). Using LOADCT
> or XLOADCT does change the values obtained with
> TVLCT,r,g,b,/GET, but nothing changes on the screen.
>
> As a result, image display is basically useless. This
> is a significant problem for an astronomer who would
> like to display images...
>
> Any hints or suggestions would be most welcome.
>
> --
> Brian Jackel
|
|
|
|
| Re: Color problems with Linux [message #15088 is a reply to message #15087] |
Wed, 21 April 1999 00:00  |
Randy Frank
Messages: 2
Registered: April 1999
|
Junior Member |
|
|
Brian Jackel wrote:
>
> Greetings
>
> One of my co-workers is having problems with IDL 5.2
> under Red Hat Linux.
>
> After placing the following lines in her .Xdefaults file
>
> idl.gr_visual: PseudoColor
> idl.gr_depth: 8
You are runing into one of two known issues:
What is the default visual depth/class for the X server in
question (use xdpyinfo)? Either the X server being used does not
support a PseudoColor, 8bit visual in which case, you need to
start the server with a different command. If the X server has an
8bit PseudoColor visual, check the output from DEVICE, /HELP. It
is likely that IDL is getting a "private" colormap. In this case,
there is a known bug in fvwm(2) where it does not properly switch
between multiple colormaps in the same widget tree (what IDL uses).
You might be able to get the colormap to swap by using a raw WINDOW
command, but it is iffy. I wrote a patch to fvwm to fix this
problem while I was at RSI, but I don't think the fvwm developers
ever included the patch. Someone at RSI tech support might know
where the patch is though. If your problem is this latter case, you
can also work around the problem by using fewer colors in your IDL
windows.
Hope it helps.
>
> IDL starts up believing that it has 256 colors. The
> problem is that the color table as displayed on the
> screen contains a fixed random assortment of entries
> (at least a hundred, it's hard to tell). Using LOADCT
> or XLOADCT does change the values obtained with
> TVLCT,r,g,b,/GET, but nothing changes on the screen.
>
> As a result, image display is basically useless. This
> is a significant problem for an astronomer who would
> like to display images...
>
> Any hints or suggestions would be most welcome.
>
> --
> Brian Jackel
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
