| problem loading color palette [message #49404] |
Mon, 24 July 2006 09:10  |
aetherlux
Messages: 12
Registered: July 2006
|
Junior Member |
|
|
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?
|
|
|
|
| Re: problem loading color palette [message #49443 is a reply to message #49404] |
Thu, 27 July 2006 07:28  |
Karl[1]
Messages: 79
Registered: October 2005
|
Member |
|
|
This all seems to work fine for me on my ubuntu laptop with IDL 6.3.
All I had to do was:
device, decomposed=0
loadct, 1
tvscl, dist(400)
and I get a nice blue/white pattern. I don't get colormap flashing
because this version of IDL selects the TrueColor visual by default.
The window shows up in the upper-right corner of the screen, like it
should. I don't know what is going on with your debian/icewm setup.
Using
device, /pseudo_color
is probably wrong.
Most X servers in the XFree86 / X.org lineage do not have PseudoColor
visual support.
If I issue
device, /pseudo_color
device, /help
I get a message saying the PseudoColor is not supported and IDL is
using the default TrueColor visual instead, which is quite correct.
Use xdpyinfo to learn what Visuals are supported on your X server.
I also strongly recommend reading the IDL documentation about the X
device and/or contacting ITTVIS tech support for further assistance. A
lot of the discussion here is in the IDL documentation.
Karl
aetherlux wrote:
> 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.
|
|
|
|
| Re: problem loading color palette [message #49445 is a reply to message #49404] |
Thu, 27 July 2006 07:18 |
Karl[1]
Messages: 79
Registered: October 2005
|
Member |
|
|
The discussion about the arguments to write_tiff does not answer the
original question.
The palette loaded with loadct, xloadct, or tvlct does not
automatically get applied to your data when you write it to an output
file with write_tiff. The palette is for display purposes only. I'm
not sure how you came to the conclusion that write_tiff would translate
your image data stored in the map variable through the display device's
palette.
What you probably want to do is to get the contents of the palette with
TVLCT, /GET. Then, use your data in the 'map' variable to lookup the
R, G, and B values and write the result to the tiff file.
Something like:
TVLCT, r, g, b, /get
red = r[map]
green = g[map]
blue = b[map]
You now have the 3-channel RGB image in red, green, and blue.
aetherlux wrote:
> Well, I don't know how it works for IDL 6.3 but in IDL 6.0 Write_tiff
> supports several arguments. My whole Write_tiff is:
>
> Write_tiff,myfile,map,4,orientation=3
>
> It is a trick that I had found surfing the internet to get the correct
> orientation for my output file.
> Moreover I use the arguments "xresol=***" and "yresol=***" to indicate
> the resolution of the file, where *** is the resolution.
>
> Ben Tupper wrote:
>> aetherlux wrote:
>>
>>>>
>>>> > 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
>>>
>>>
>>
>> Hi,
>>
>> WRITE_TIFF is expecting only one or two argument according to the IDL
>> online docs (IDL 6.3). What are you trying to do with the third
>> argument (4) that you have shown?
>>
>> Ben
|
|
|
|
| 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.
|
|
|
|
| Re: problem loading color palette [message #49448 is a reply to message #49404] |
Thu, 27 July 2006 02:47 |
aetherlux
Messages: 12
Registered: July 2006
|
Junior Member |
|
|
Well, I don't know how it works for IDL 6.3 but in IDL 6.0 Write_tiff
supports several arguments. My whole Write_tiff is:
Write_tiff,myfile,map,4,orientation=3
It is a trick that I had found surfing the internet to get the correct
orientation for my output file.
Moreover I use the arguments "xresol=***" and "yresol=***" to indicate
the resolution of the file, where *** is the resolution.
Ben Tupper wrote:
> aetherlux wrote:
>
>>>
>>>> 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
>>
>>
>
> Hi,
>
> WRITE_TIFF is expecting only one or two argument according to the IDL
> online docs (IDL 6.3). What are you trying to do with the third
> argument (4) that you have shown?
>
> Ben
|
|
|
|
| Re: problem loading color palette [message #49472 is a reply to message #49404] |
Tue, 25 July 2006 11:08 |
btt
Messages: 345
Registered: December 2000
|
Senior Member |
|
|
aetherlux wrote:
>>
>>> 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
>
>
Hi,
WRITE_TIFF is expecting only one or two argument according to the IDL
online docs (IDL 6.3). What are you trying to do with the third
argument (4) that you have shown?
Ben
|
|
|
|
| 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.
|
|
|
|
| Re: problem loading color palette [message #49476 is a reply to message #49404] |
Tue, 25 July 2006 07:55 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
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
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
