mock-up of a panorama gui interface

[Bruno Postle]

On Thu 18-Apr-2002 at 10:44:59 +0200, Peter Suetterlin wrote:
> 
> - what is supposed to hide behind the 'Options' button in the menu
>   bar?

In ptgui, this is where you add paths to external executables;
ptoptimizer, ptstitcher, panorama viewer, image viewer etc..

> - Back/Forward: I suppose this steps to the next/previous tab.  Really
>   neccessary?

Probably not, again this is copied from ptgui which has a [next] button
on each tab.

> - cropping: I guess there will be some sort of rulers, either as in XV
>   or (more comfortable) like in Gimp?

I guess that's up to whoever implements it, ptgui has rulers that you
can drag across.

> - Maybe make 'No crop' a radio button and have it 'on' by default?

Good idea.

> - Lens settings: From the image it isn't clear how the information is
>   handeled.  Normally, I have only one abc/hfov setting for the first
>   image and use a=0 etc. for the others.  There should be an easy (and
>   obvious) way to achieve that via the gui.

I was attempting to show a list of images, the first one would actually
be the default settings with no actual image content.  The real images
would inherit properties from this.

I think the pt script files are really ugly when a=0 means 'inherit this
property from the first image in the sequence'.  I may have this wrong,
but if you actually want 'a' to be equal to zero, don't you have to set
a=0.00000001 ?

> - maybe switch Image orientation and Panorama settings tabs: How do
>   you want to preview the panorama if you don't know yet where to put
>   the single images?

That's true, these two tabs have no natural order, the warped image
depends on the panorama properties and the panorama preview depends on
the individual image orientations.

Possibly this is a sign that the underlying assumption is wrong?  I
can't think how else to do it.

> - is there an (easy) way to store the image orientation settings and
>   load them later?  I.e., image one always has pitch 0, roll 0, yaw 0,
>   image one has pitch 0, roll 0, yaw 30 and so on?  

I guess so, in ptgui, there is a method to save the current project as
the default, so new projects have the same parameters even before you
load the images.  This could get messy internally.

> - Control Points:  Very nice! 
>   I guess if you click on an existing point the list scrolls to the
>   corresponding entry?

There are loads of features that ptgui doesn't have, that is one of
them.

(Others are sub-pixel positioning, changing the type of a point after
it's created and reprojecting the zoom windows so they have the same
projection/orientation).

>   distance is not really clear - I guess this is only there if you
>   re-edit an already optimized pano?

yep, it's feedback from the optimizer.

>   Up and down scroll the list?  Are the corresponding images loaded
>   then?

not in ptgui, where only the points relevant to the current pair of
images are shown.

>   Maybe have an extra button 'Goto point' or 'Show point' to
>   prevent constant image display when you scroll through the list?

That would be neat, it would save hunting around the images trying to
find them.

>   Adding a point should work without the 'add' button.  I cannot really
>   see how adding with the button is supposed to work?? Where will it
>   be added?  Or is it 'press add' then 'click to image'?  Would be too
>   much, IMHO.

I think that simply clicking both images should create a control point
pair.  This would interfere with being able to move the points after
inserting them, mice have multiple buttons I suppose.

>   I like the tabbing of the two windows.  Do you think it is possible
>   to have a balloon popup for each tab that shows either filename or
>   yaw/pitch settings of that image?

That sort of thing could be important for multi-row panoramas.  The tabs
are taken straight from ptgui, if they were combo boxes then more
information could be shown, but then tabs are one-click and combo-boxes
are click-drag-letgo.

> - Output: Colour correction is the intensity/contrast correction
>   (parameter k?)
>   Why not include the 'Panorama settings' tab here, too?  Does that
>   really have to be a separate one?

I've split them because they are really related to the process of
stitching rather than the type of panorama that is being created.

In terms of the data model, I find it easier to think of both the output
panorama being a 'Panorama' and the input images being mini 'Panoramas'
in their own right.  This thinking is more extensible later on when
somebody wants to do one of these things:

- have multiple output panoramas (for a cube maybe).

- extract a section of a panorama, edit it in the gimp and reinsert it
  as one of the source images (like pteditor).

- extract a panorama that has roll, pitch, yaw, a, b & c values of its
  own (currently these are all zeroed).  Ptstitcher doesn't support this
  but there is no reason why it shouldn't in the future.

-- 
Bruno