| Re: All I get is gray scale (and IDL 5.5) [message #29071] |
Fri, 01 February 2002 05:15  |
Ruediger Kupper
Messages: 7
Registered: February 1999
|
Junior Member |
|
|
David Fanning wrote:
> Yes, something is not right. I'd slip a
>
> DEVICE, TRUE_COLOR=24
>
> into an IDL start-up file. I don't think you
> want a Direct Color visual. :-(
Hi Gary and David,
now, perhaps there is a possibility for me to understand
this issue, since I tried several times and never managed.
I encountered the same problem as Gary, and I
(heuristically) found the same solution for it, i.e.,
keeping IDL from allocating a Direct-Color visual by
explicitely requesting a True-Color one.
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=0 call to turn on
IDL's internal color translation table, AFTER the first
window has been opened. (The translation table is enabled
right after requesting the True-Color visual, but it
switches to bypassed when the first window opens. Although
this was atready the case with IDL 5.4, the TV command
obviously didn't bother - It does with IDL 5.5.)
Okay. Now, if anyone of you can help me with the following
questions, I would greatly appreciate:
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.
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?
Third question (related to this): How and when is IDL's
internal translation table used on a 24-bit display? The
documentation is not very helpful, as it refers to 8-bit
displays (in which case I do understand what it means).
Actually, the documentation says:
(1) "By default, the translation tables are used with shared
and static color tables. When using displays with private
color tables, the translation tables are bypassed." While
also stating
(2) "When a private or static color table is initialized,
the bypass flag is cleared. It is set when initializing a
shared color table."
Now this gives us something to think about :-).
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? We use IDL
in our group, with a central startup file, and on many
different machines (Windows NT, Intel Linux, DEC Alpha Unix,
DEC Alpha Linux, 8-bit and 24-bit graphics cards), and, for
licensing reasons, IDL versions ranging from 5.5 back to
5.2. Do I really have to ask every single user to try, until
he finds a configuration that works on his system? I would
expect a high-end visualisation tool like IDL to work
without every single user needing to know the internals of
his graphics hardware.
Fith question: Does RSI give any statement on this (sorry to
say so) absolutely weird color management on X systems?
Please excuse me sounding a bit frustrated (or "stupid", as
Gary put it), but I actually feel like it :-(.
I'm using DECOMPOSED=0, by the way, but this should not
really matter here.
Thank you in advance for any helpful comments,
Regards,
Rüdiger.
|
|
|
|
|
|
| Re: All I get is gray scale (and IDL 5.5) [message #29168 is a reply to message #29071] |
Fri, 01 February 2002 06:55  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
David Fanning (david@dfanning.com) writes:
> 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 am feeling particularly jumbled this morning.
(There was a cow licking me all night long, and
my hair is going in every possible direction this
morning. I *look* like Albert Einstein, even if I
don't think like him.)
The thing about Direct Color visuals that made them
attractive (to some people), was not only that they
were 24-bit and color tables could be loaded, but
that when you loaded your new color tables, your
graphics windows updated automatically, as they
do on an 8-bit display. After working with 24-bit
displays for awhile now, I'd consider this a disadvantage,
but for someone coming directly from 8-bit displays,
this did seem like heaven on earth.
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
|
|
|
|
| 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
