Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Re: IDLgrWindow Setting - Why render image gets erased?
Victor writes: > After swimming through IDL Documentation and messg boards, I couldn't > find an answer to the following (and I'm surprized this hasn't been > discussed .. or maybe I couldn't find it - it looks fundamental) > > # When you render an image in IDLgrWindow object, then if you try to > maximize the window/resize (interactively with mouse clicks), the image > disappears. > > Thanks in advance > - Victor > > P.S. Setting RETAIN = 2 helps with leaving the image rendered if you > switch between windows, however, doesn't solve the above problem. Can you say "iImage" (and understand the underlying mountain of code)? :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.dfanning.com/
On Mon, 31 Oct 2005 17:06:17 -0800, Victor wrote: > Hi all, > > After swimming through IDL Documentation and messg boards, I couldn't > find an answer to the following (and I'm surprized this hasn't been > discussed .. or maybe I couldn't find it - it looks fundamental) > > # When you render an image in IDLgrWindow object, then if you try to > maximize the window/resize (interactively with mouse clicks), the image > disappears. > > Thanks in advance > - Victor > > P.S. Setting RETAIN = 2 helps with leaving the image rendered if you > switch between windows, however, doesn't solve the above problem. IDLgrWindow is a low-level window object that you must draw explicitly. This includes the initial draw as well as handling any sort of event that happens to the window, such as a resize. In the case of a resize, you generally have to at least call the Draw method again so that the IDLgrWindow can update the window on the screen after the resize. But IDLgrWindow is the lowest-level window object provided by IDL. There are several other objects and tools that are higher-level and smarter: Widgets (WIDGET_DRAW) IDLitWindow XOBJVIEW iTools Few applications exist that use stand-alone IDLgrWindow objects for display. Most applications use WIDGET_DRAW and widget application architecture to manage the graphics windows. Karl
Thanks Karl for giving the right pointers. Xobjview works the best for the application that I am developing. By the way, I'm not sure if this is a bug in Xobjview - when I export the image into .TIFF (using file->export) and later open with a Tiff editor, the image is "FLIPPED". It gets exported just fine if exported as .JPEG ! Any Comments? - Victor PS: David, I'm working on it, and as soon as I understand and reproduce the iImage mountain of code I'm planning to start-up "VDL" (Victor's Data Language) ;-) Thanks 2 all Karl Schultz wrote: >> # When you render an image in IDLgrWindow object, then if you try to >> maximize the window/resize (interactively with mouse clicks), the image >> disappears. >> > IDLgrWindow is a low-level window object that you must draw explicitly. > This includes the initial draw as well as handling any sort of event that > happens to the window, such as a resize. In the case of a resize, you > generally have to at least call the Draw method again so that the > IDLgrWindow can update the window on the screen after the resize. > > But IDLgrWindow is the lowest-level window object provided by IDL. There > are several other objects and tools that are higher-level and smarter: > > Widgets (WIDGET_DRAW) > IDLitWindow > XOBJVIEW > iTools > > Few applications exist that use stand-alone IDLgrWindow objects for > display. Most applications use WIDGET_DRAW and widget application > architecture to manage the graphics windows. > > Karl
Victor wrote: > ...I'm not sure if this > is a bug in Xobjview - when I export the image into .TIFF (using > file->export) and later open with a Tiff editor, the image is > "FLIPPED". It gets exported just fine if exported as .JPEG ! I see the same behaviour. The documentation for WRITE_TIFF, keyword ORIENTATION has a good outline of the issues here. It ends with... Warning Not all TIFF readers honor the value of the ORIENTATION field. IDL writes the value into the file, but some readers are known to ignore this value. In such cases, we recommend that you convert the image to top-to-bottom order with the REVERSE function and then set ORIENTATION to 1. The above suggest this is a problem with the viewer, but I see it with several viewers: Quicktime PictureViewer, Xnview, Microsoft Imaging for Windows, Paint Shop Pro and ImageMagick Imdisplay. I note that the iTools do *not* have this behaviour. So I think that it needs to be fixed in Xobjview. You should report this to RSI as a bug. It's probably not too hard to jump into the Xobjview code and fix it for yourself. Or just choose another format like PNG or JPEG. Do you have any reason for wanting TIFF output? -- Mark Hadfield "Kei puwaha te tai nei, Hoea tahi tatou" m.hadfield@niwa.co.nz National Institute for Water and Atmospheric Research (NIWA)