| Re: problem loading color palette [message #49447 is a reply to message #49404] |
Thu, 27 July 2006 02:51   |
aetherlux
Messages: 12
Registered: July 2006
|
Junior Member |
|
|
I have found out that this solution doesn't work for Ubuntu. Instead,
if you X window system let it, you can try:
device, /pseudo_color
device, decomposed=0
xloadct
and then you can load your favourite palette.
It has worked for a colleague using Ubuntu.
aetherlux wrote:
> 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
