Hi Frank and all,
Well, you folks have been busy this morning! :)
I will clarify some points here..
On Fri, 20 Aug 2004 10:39:40 -0400, Frank Warmerdam <warmerdam@...> wrote:
>> - After a lot of interactions, the layers dialog gets "screwed up" and I get numerous:
>Have noticed this myself on occasion but I am not really too sure how to dig into it.
>It also doesn't seem to happen very frequently or repeatedly for me, though I may just
>not have tried hard enough to isolate the issue.
Clicking repeatedly on the visibility icon will eventually cause the problem.
>> - Opening a new view freezes the existing one.
>Always? Just under some circumstances? This sounds like it is mostly like
>an interaction with a particular underlying OpenGL driver, relating to managing
>more than one OpenGL state.
Since this one is difficult to describe, I was hoping that somebody else had noticed that...
Typically, it goes like this: open a new View, and go back to View1. The now uncovered portion of
View1 is not redrawn. Go back to View2 and then View1 again and now it looks ok. Zoom-in on View1
and the scrollbars change size but image stays the same. Go back to View2 and then View1 and now
it's ok. And it goes on like this. Closing View2 doesn't solve the problem and we have to shutdown
Hope this clarifies the problem.
As for the cause of this and others, my bet is the GTK win32 port which I read somewhere is not very
>> - Dialog sometimes have weird dimensions.
>Can you be more specific?
For example, the progress dialog can be 3-4 times higher than wide. Same with other dialogs.
However, this behavior is unpredictable and not easy to reproduce. Wouldn't be surprised if this was
another of GTK's annoyances.
>> - Opening and closing an image that is not georeferenced causes all subsequent images to open
>This should be fixable. I see what I can figure out this morning.
Saw you did. Thanks!
>> - Alpha channel is ignored when exporting an image.
>Your referring to the "File->Export" mechanism, right? Not the print-to-file
Yes. I had never used the print-to-file option until now. Tried it today and got a blank image so I
am not sure what went wrong...
>Do you mean that the alpha channel isn't even written out to the new file
Exactly. Even when exporting from a tiff file already having an Alpha channel.
>> - The tracker tool coordinates preference cannot be changed for a project.
>There is a general issue with regard to preferences and whether they should be
>saved in projects or not.
So what does this line in a project file mean?
<Translation x="-336160.46875" y="-5934558.0"/>
>> - The ROI tool is unreliable and should "snap" to the pixel resolution.
>Do you mean specifically when used with the export tool?
Yes. And when I use it for my fusion tool.
>The ROI tool does have a mode that restricts it within the outer boundary of a raster and I can
>see that it would be nice to further be able to restrict it to a pixel boundary
Yes since it's illogical to cut a pixel in half, for example :)
To do my fusions, I need the images to match perfectly and to ensure that, I have to zoom-in deep to
set the ROI correctly on pixel boundaries (actually, just slightly inside the ul corner and slightly
outside the lr corner).
>> - Root and square enhancements have been left out from the possible choices (had to add them)
>Do you mean that the icons aren't available on the icon bar?
Yes. Fortunately, the XML config makes it easy to add them. We only have to add the callback
functions in gvviewwindow.
>They were deliberately omitted to avoid clogging up the icon bar with too many
>enhancement options when they are rarely alot better than those that are available.
I tend to disagree on that one: for example, I have no use for Equalization but I discovered that
root enhancement is the one I really need...
>We really need some sort of popup list of actions we can apply to a raster layer.
That would be a good idea.
>> - Exporting many layers into a single image (ie, mosaics, alpha channel blending)
>Currently the only mechanism to accomplish this is the print-to-file
>approach. Otherwise it would be quite complex and in many ways out of
>the scope of OpenEV.
Couldn't we adapt the code from gdal_merge.py to do this?
>> - Add an option to use Averaging when exporting at 1:2, 1:4, 1:8
>Hmm, interesting option. It would be fairly complicated to implement
>though I think since I believe the export tool currently depends on
>GDAL to do the downsampling and GDAL doesn't have a really easy way
>of accomplishing this.
I made a temporary fix to serializeBand in vrtutils.py like this:
if opt_dict['DstRect'] != opt_dict['SrcRect']:
However, this causes problems in other uses of vrtutils...
But I think using VRTAveragedSource is a simple way to accomplish that.
And what about the GDAL warper functions? Is there a reason why they don't have Python wrappers?
>Thanks for the great feedback. Hopefully we can act on a few of these at least.
And thanks to you all for taking the time to read and respond!