Menu
▾
▴
[Openev-discuss] Re: Random Comments on OpenEv (fwd)
|
From: William H. <wh...@at...> - 2000-08-02 18:01:02
|
Hi:
On Wed, 2 Aug 2000, Frank Warmerdam wrote:
> William Hughes wrote:
> > Some initial reactions to openev, based on a couple of hours
> > of playing.
> >
> > -openev crashes very frequently on my system
>
> Steve or I will have to look into the crashing in more detail. It may
> be related to your video drivers, or it may be specific to OpenEV. It's
> hard to tell yet.
>
Thanks.
> > -in particular, openev does not seem to deal well with a file
> > which changes. As far
> > as I have seen, either the change is not reflected in the
> > displayed image, or the viewer crashes.
>
> Are you working with CEOS files? Generally it is unwise to rewrite
> a file open in another process; however, if it is rewritten with a file
> of the same size and layout I would not expect it to result in a crash.
>
Actually, MFF files mostly. Agreed, it is unwise to rewrite a
file open in another process, on the other hand, perhaps a viewer
should be able to handle this.
> The failure to update on screen properly is expected. There is caching
> at various levels in OpenEV, and it has no way to know that the underlying
> file changed. We will be adding a "refresh" option that will flush all
> caches and reread from disk.
Thanks. Loading images into python is probably a better
way of working anyway.
> > Some random comments (some of these may reflect my
> > lack of knowlege about the program)
> >
> > -it would be nice to have a cursor which jumps
> > when clicked (perhaps the point query tool could have
> > an option to provide this behaviour)
>
> In early design discussions (before I started work on the project) it
> was decided not to have a persistent, visible cursor in view windows. The
> point query layer is intended to approximate this when needed. In select
> mode you should be able to select a point in the point query layer, and
> drag it to a new location.
>
Yes, point query seems to to most of what I want.
This seems to be more of a user inteface/program familiarity
issue than a question of functionality.
> > -a go_to pixel coordinates for the cursor, point query tool
> > would be nice
>
> This would be natural for the cursor, if there was one. I think it
> would be good to extend the current shape attribute tool to include
> a tab showing the vertices of current shape, and to make it editable.
> This would allow exact position of query points, and other shapes when
> needed. A likely limitation of such a tab would be that the points
> would only be shown in the natural coordinate system of the feature.
> For instance, if the points were in raw image coordinates, it wouldn't
> be able to position them based on lat/long coordinates.
>
> Would this be acceptable?
>
Yes. (one trick would be to accept lat/long coodinates and
map them to pixel coordinates (approximate if needed)
and use these. This is what EV does now. This might
be easy, or it could be a nightmare depending on your
underlying imlementation)
> > -some sort of command history would be nice. in particular
> > a way to load/reload a file that was loaded previously, without
> > having to walk the directory tree.
>
> I am keen on adding a "recently accessed files" list to the file menu,
> which would do some of this. I had also hoped to implement simple
> project files that could save the state of all views, and layers to a file
> for later reloading, but it was beyond the scope of the project at this
> time.
>
Ok
> > -need to be able to save preferences
>
> Application preferences are saved when the application successfully
> shuts down. They are not saved if the application crashes.
>
I will test this again
> > -the complex scaling needs work
>
> I would appreciate input on this. Under what circumstances does it seem
> inappropriate? What algorithm do you suggest?
>
One problem is that
I could not change the scaling on the magnitude
interpretation of the complex image. The basic algorithms looks fine.
I will be looking at this in greater detail.
> > -the jump to full scene tool does not always seem to take rotation
> > into account
>
> You are correct. Currently a number of operations, including print, and
> view overview ignore rotation. I take it that you find this to be a
> problem? The thinking for zoom to overview was that it would "return you
> to the natural view" including resetting the rotation, zoom and offset.
>
It does not seem to be a problem. I just noticed a couple
of times that zoom to overview cropped corners (I was doing
some wierd stuff at the time though).
> > -frequent error messages about not recognizing WGS_84
>
> Could you capture some of these and email them to be directly? Also,
> could you tell me where I could get to some of the data files you are
> working with?
>
I will be preparing some more complete "bug" reports in the near
future. These random comments are just that. Feel free to
ignore anything that does not help.
> > -preprocessing a large image to make zooming faster produces
> > very poor scaling. The speed increase is only moderate.
>
> By preprocessing I assume you mean the File->Import step to turn
> the image into a tiled, pyramided TIFF file, right? What do you
> mean about producing very poor scaling?
>
I tried this with a 200 megabyte CEOS file. When I used the File->Import
step, the overview looked ugly (far too much contrast). When
I simply opened the file, the overview looked file. If
I changed the scaling for the import file to match the scaling
for the opened file the images appeared to be identical.
>
> > -if the name of a layer is changed in the raster dialog
> > box, this is not reflected in the layers tool immediately
> > (clicking on the tool does not cause an update, switching
> > views does)
>
> This is a know flaw, and I hadn't considered it serious enough to
> spend the time to fix. Fixing it properly would require implementing
> some sort of new signal on internal data objects and isn't trivial.
>
This is a minor irritant. Certainly not worth significant effort.
> > -link views would be nicer for different sized images
> > if it worked from the current display (i.e. display
> > a similar area in both views, then link by identifying
> > the center pixel in both images)
>
> In my experience linked views will operate based on the same center
> point, zoom level and rotation. If the views have different coordinate
> systems (for instance, two different sized raw images), then the
> correlation will be meaningless. If the images are different sized
> raw images, it isn't clear to me how I could find corresponding regions
> in the two images.
>
> Note that the linked windows capability should work well if both images
> have associated GCPs (to lat/long as is the case with most CEOS images)
> and if they are being used to warp the image.
>
It is possible to have two different sized raw images,
without any GCPs, such that they are locally similar.
(e.g. image 1 is a subset of image 2, or image 1 has slightly
different pixel spacing). In this case, zooming and rotation
can be meaningful to some extent, but only if a pair
of "corresponding" points is identified. (again
this may only be a case of not knowing the best
way to accomplish a task)
> > -it is possilbe to get the view confused (blocks in the
> > wrong place) eventually this goes away. A refresh might
> > help here
>
> I haven't had this happen before. Does it only happen when you are
> overwriting a file?
>
> Note that relatively little testing is done in multi-view mode, so some
> of your problems may result from that. I will spend a bit of time today
> trying to reproduce some of your problems; however, if I cannot I will
> look into them more closely when I am next there in the office.
>
This happened in multi view mode when I was playing with linked
views. I am not sure I can reproduce it. After playing around a bit
more the problem went away. I was not overwriting files at
the time.
-William
|