| Re: problem loading color palette [message #49474 is a reply to message #49404] |
Tue, 25 July 2006 08:20   |
aetherlux
Messages: 12
Registered: July 2006
|
Junior Member |
|
|
Karl Schultz wrote:
> On Tue, 25 Jul 2006 03:57:47 -0700, aetherlux wrote:
>
>> Karl Schultz wrote:
>>> On Mon, 24 Jul 2006 09:10:36 -0700, aetherlux wrote:
>>>
>>>> Hi everybody, I use IDL 6.0 with Debian GNU/Linux. Today after trying
>>>> to load a color palette to draw several maps, I have noticed that the
>>>> palette is not loaded.
>>>> I use:
>>>> device, decomposed=0
>>>> xloadct (and then I choose the palette or loadct, 41 -- the number of
>>>> the palette)
>>>>
>>>> It happens with all the palettes.
>>>> I guess that it is related with the X server. Perhaps it is a
>>>> consecuence of a recent update from Debian Sarge to Etch, which has
>>>> changed my Xserver (in Sarge it was XFree86 and now in Etch is Xorg).
>>>>
>>>> Does anybody know a solution to force IDL to load the palettes?
>>>
>>> It really may be more of a function of your desktop software, especially
>>> the window manager.
>>>
>>> Term: ICCCM - Inter-client communications convention manual
>>>
>>> IDL uses the ICCCM-compliant method of setting the colormap ID in the
>>> top-level window. A ICCCM-compliant window manager is supposed to notice
>>> this and make that colormap active (this is known as "installing" a
>>> colormap) when the window receives colormap focus. The colormap focus
>>> policy is often the same as pointer focus policy, but it also may be
>>> different.
>>>
>>> First, try just clicking or pointing at the window, to set focus on that
>>> window. If that does not work, investigate your window manager's colormap
>>> focus capabilities and see if there is an option that you can adjust to
>>> make it work.
>>>
>>> A lot of newer desktops and window managers steadfastly refuse to install
>>> a different colormap on the server because it causes all the GUI elements
>>> on the desktop to appear with "false colors". There is some debate over
>>> the ICCCM and some desktops sort of "ignore" some parts of it.
>>>
>>> As a last resort, try the undocumented feature:
>>>
>>> DEVICE, /INSTALL_COLORMAP
>>>
>>> This makes IDL use the non-ICCCM-compliant method of installing the
>>> colormap itself whenever the window gets focus.
>>>
>>> You might also try using a TrueColor visual (DEVICE, TRUE_COLOR=24). But
>>> I think this causes IDL to translate the colors through the palette on
>>> the client side, which is not as fast.
>>>
>>> Hope this helps,
>>> Karl
>>
>> I've tried it. I had seen about this in the ITT/RSINC web page. I am
>> using IDL in two different laptops, the first with Ubuntu and Gnome and
>> the other with Debian and Icewm. In the Debian/icewm laptop when I run
>> the program first the new window appears almost out of the screen, to
>> the left of the screen.
>
> I don't know what might be causing this. I have a laptop with Ubuntu
> installed - maybe I'll see if I have the same problem.
>
> Are you using a virtual desktop that is larger than the physical screen?
>
> You also might submit this issue to ITTVIS Technical Support with all the
> supporting information. That way, you can be sure it will be
> investigated.
>
>> Although I have tried to choose my palette, it has not been loaded and
>> the colors are from the default IDL palette. If I move the mouse pointer
>> to the window with the map (almost out of the screen) then the map
>> colors change and it is showed with the right colors. By the way, the
>> complete icewm desktop environment changes to awful and strange colors.
>
> That is exactly the expected behavior. This is all about the colormap
> installation process that I tried to explain above. You see, all but very
> expensive graphics systems have only one color table in its hardware. When
> an X client, like IDL, wants its own color table, it must share this
> hardware resource with other clients, including all the desktop crud. So,
> the window manager adjusts the contents of the hardware color table
> depending on which client has the focus. If you don't buy my explanation,
> then read some material about X Windows. These issues are fairly well
> known and understood.
>
> Again, this "colormap flashing" issue is regarded as pretty distasteful in
> the Linux community. One approach to avoiding it is using the TrueColor
> visual. More recent versions of IDL now try to use a TrueColor visual
> before DirectColor by default for this very reason. You can explicitly
> request this behavior by using "DEVICE, TRUE_COLOR=24" before issuing any
> graphics commands. I think you'll be much happier if you do this.
>
>> I have a bigger problem, now the image is showed with right colors, but
>> the my output file with this map in yet saved with the default colors.
>
> Sorry, I don't know what you mean by "output file". You'll need to say
> how you created it.
>
> Karl
I have got to solve the problem. It works fine but yet with the window
placed to the left of the screen.
Before issuing any graphics command:
device, /install_colormap
device, true_color=24
device, decomposed=0
xloadct
now you can choose your favourite palette.
About the "output file": I write a tiff file to disk to save the
obtained graphic:
myfile='/home/user/map.tif'
write_tiff,myfile,map,4
Thank you very much everybody.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
