Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
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?
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
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.
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
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
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.
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
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.