Re: Color question (answer is not device,decomposed=0)

[Rick Towler <rtowler(at)u.washington.edu>]

This is really an X windows issue.  I am no expert but I lived with this
same problem for a long while.

>I tried using hardware and software rendering (by using
>obj_new('IDLgrWindow',renderer= )), but both came up yellow (and perhaps
>I can't use hardware rendering, although I have Mesa installed, and I
>have an NVidia TNT card).

This will have no effect since all images are *rendered* on your solaris
X client and then displayed on your local linux X server.  So for every
"frame" sent to you, every pixel in that frame is sent too.

Your problem lies in the fact that your solaris display is running at 16
bit and your linux display is at 24 bits.  Solaris sends over an 16 bit
pixel with a that maps incorrectly in you linux X server's 24 bit color
table.  This is why it works on the 16 bit solaris display and not your
24 bit linux display.

Easiest solution is to run your linux desktop at 16bbp.  If I understood
you correctly, your Solaris hardware is running at 16bpp and running
both client and server at the same depth should solve your problem.

You may be able to run your solaris box at 24bpp.  This should solve
your problem too.

Lastly, if your output is static, send it to a .jpg or .gif file and
view it with a local image viewer (like ee or xv).  This is a minor pain
but it works.

If none of these solutions work for you take a look at the many X
Windows How-To's  (http://www.linuxdoc.org/) I'm sure there you'll find
a better explanation of your problem and will surely find a better
solution.

Good Luck!

-Rick Towler



David Fanning wrote:
> 
> Troy Carter (tcarter@princeton.edu) writes:
> 
> > I also tried it on a 16bit x-terminal (running an xsession from the
> > solaris machine) -- this time I get white on black.  So, it seems it is
> > my linux box causing the problem...
> 
> Sorry, we have rapidly gotten beyond my depth. I'll turn
> you over to the Linux experts in the newsgroup. But from
> the evidence you present, I suspect IDL per se isn't at
> fault, which is pretty much what I expected. :-)
> 
> 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