| Re: All I get is gray scale (and IDL 5.5) [message #29169 is a reply to message #29071] |
Fri, 01 February 2002 06:27  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ruediger Kupper (Ruediger.Kupper@Physik.Uni-Marburg.De) writes:
> now, perhaps there is a possibility for me to understand
> this issue, since I tried several times and never managed.
I seriously doubt whether it is *possible* to understand
this issue. But I'll give you a couple of heuristics
I use to get by.
> Then, upgrading to IDL5.5, all my colors were scrambled
> again. After a series of tests, I discovered that now I need
> an additional DEVICE, BYPASS_TRANSLATION=3D0 call to turn on
> IDL's internal color translation table, AFTER the first
> window has been opened.
I haven't encountered the need for this yet, but it
doesn't surprise me any. The way colors are handled in
IDL has changed with every single point release since
at least IDL 5.0. My impression is that the good folks
at RSI are as confused about the situation as we are.
What I do know is that colors are handled differently
on different platforms. This makes it *extremely* hard
to write portable code, which is the primary reason I
wrote all the color tools you find on my web page.
AFAIK, those tools produce the correct color pretty much
everywhere, and in every version of IDL, regardless of how
you have your damn computer configured. :-)
> First question: If I "don't want a Direct-Color visual", why
> does IDL want it? As this is the order in which IDL tries to
> allocate: Direct-Color first.
It would be easier to answer "Why does the sun come up
in the East?". Next question?
> Second question: I did not find any way how to use the
> Direct-Color visual at all, but perhaps I still don't
> understand it right - What exact difference is there between
> Direct-Color and True-Color, and how would IDL access the
> two different modes? Reading the IDL documentation I get the
> impresseion that everything should work fine - why doesn't it?
Here is my take on this question. It's probably not
right, but I haven't really run into anyone who knows the
answer, so who is going to call me a liar?
True-Color visuals are meant to be "static" color tables.
In other words, you can't load other values in the color
table. Why would you want to? You have all 16.7 million
possible colors available to you. If you want some particular
color, just specify it's color triple and be done with it.
Unfortunately, this doesn't square with how we want to
use IDL. As scientists, we like color tables. We have
used color tables for three centuries, and we want to
continue to use color tables. So, we want to load the
damn things. That's a problem. IDL solves it by providing
"virtual" color tables, or software color tables, as
an intermediary between you and the static color table
provided by the True-Color visual.
Most of the oddness in IDL's color handling comes in
as we go back and forth through this intermediary. I
suspect some of the problems are caused by different
implementations on the hardware end of what constitutes
a "true-color" visual. I can't imagine Microsoft, for example,
isn't going to try to "solve" this problem themselves
in their usual brain damaged way that confuses
everything else you are trying to do.
Anyway (I've lost my train here), Direct Color visuals
were designed to give you a 24-bit dynamic (as opposed
to static) color table. That is, they were 24-bit, but
you can change the numbers loaded in them. The best of
all worlds.
I've actually seen Direct Color visuals work---once.
On one incredibly lucky computer. But no one, and I mean
no one, agrees on what a Direct Color visual is suppose
to do. (PCs pretend they have never heard of it.) I suppose
IDL searches for it first, because it would be wonderful
if it were found, and if it worked, which it won't.
But, there you go.
> Third question (related to this): How and when is IDL's
> internal translation table used on a 24-bit display?
I don't have the foggiest idea. But I'd bet good money
it is used differently in every version of IDL. Presumably
the translation tables are used when color decomposition
is turned off. But that kind of behavior is just plain
dumb when you are trying to display a 24-bit image,
and causes all kinds of havoc on PCs.
> Fourth question: Even if we don't understand why it does,
> what it does - is there any way to determine a configuration
> that works, without having to try them all out?
I think so. If you have a 24-bit display, make sure
you have a TRUE_COLOR=24 visual class, then use my
color tools to get colors. If you have an 8-bit display,
make sure you have a PSEUDO_COLOR=8 visual class, then
use my color tools to get colors. :-)
> Fith question: Does RSI give any statement on this (sorry to
> say so) absolutely weird color management on X systems?
No, I have a secret agreement with RSI that doesn't expire
until 2015 that I will be the sole expert on IDL color
management. It was the only way I could further my career,
since my programming skills were so abysmal when I began.
> Please excuse me sounding a bit frustrated (or "stupid", as
> Gary put it), but I actually feel like it :-(.
Frustrated? About colors!? Nonsense!
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
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
