mock-up of a panorama gui interface

[Bruno Postle]

On Thu 18-Apr-2002 at 02:47:34PM +0200, Peter Suetterlin wrote:
> 
> > 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.
> 
> Which by itself is OK, just:

[snip]

> My scripts look like
> p f2 w1000 h500 v360 u10 k0 n"JPEG" 
> 
> # Center ring
> i f0 w480 h640 y0    p0   r0  v48  a-0.014 b0.037 c-0.045 n"flat/aut_00.jpg"  X0 Y0 Z0
> i f0 w480 h640 y30   p0   r0  v=0  a=0 b=0 c=0 n"flat/aut_00.jpg"  X1 Y0 Z0
> i f0 w480 h640 y60   p0   r0  v=0  a=0 b=0 c=0 n"flat/aut_00.jpg"  X2 Y0 Z0
> i f0 w480 h640 y90   p0   r0  v=0  a=0 b=0 c=0 n"flat/aut_00.jpg"  X3 Y0 Z0
> ...
> v v0 a0 b0 c0
> v y1 p1 r1 
> ....

Ok, I was making a false assumption, I don't know why, since I figured
all this stuff out a couple of years ago.  It must have been so
traumatic that I blocked it out.

So a=0 is actually a reference to the value of 'a' in the source image
with id=0.  This is sane, since it implies a=1 is then a reference to
the value of 'a' in the image with id=1.

The default grey-image should go, since the first image should provide
the defaults for the remaining images.

The checkboxes marked default on the remaining images should then become
combo boxes with options: 'inherit from 0', 'inherit from 1', 'This
value'.  The default should be 'inherit from 0'.

> Well, the panorama preview doesn't *really* depend on the panorama
> settings.  After all, you would'n compute a 3000x1500 pano just to
> scale it down to 150x75 for display....

True, but you are also assuming that everyone makes full 360 degree
spherical panoramas.

> I would probably show a preview that is not really related to the pano
> settings, i.e., always show a standard pano of 360x180 degree.  And
> take the whole pano settings to the output screen (see my other
> comment)

Ah, I think that is another assumption I (and ptgui) have wrong.

The 'image orientation' tab shows the warped images as they fit into the
output panorama (which may or may not be a full spherical).

This is wrong, the warped images should always show the placement into a
full spherical, regardless of whichever output panorama-type is being
used.  Now this tab 'image orientation' naturally belongs before the
'panorama settings' tab since nothing depends on the output panorama.

This also solves another problem with ptgui.  I do a lot of partial
panoramas where the output is a rectangular reprojection of two or three
shots (like the example in the mockup).  When I get some of the
parameters wrong they disappear off the edge of the warped image, making
them useless.  They won't disappear off the edge of a full
equirectangular panorama :-).

> Hm, also an idea.  -> Show all points, but highlight the ones in the
> current image pair?

pteditor does this, there are three colours for selected, related and
unrelated points (I think).

> > >   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.
> 
> Whis is true, indeed.  Then again, if you (e.g.) change size or type
> of the pano, then you will probably want to save it with adifferent
> name, which means you have to open both tabs anyhow.

indeed, and since the 'panorama settings' tab moves to after 'image
orientation', it might as well move to after 'control points' as well.

The 'panorama settings' tab and 'output' tab would then be next to each
other and can be merged.  I'd still like to see a table view, so the
output panorama is presented in the same format as input panoramas.

> > 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.  
> 
> Oops, I'm a bit lost.  Is this still related to the pano/output tab?

It was..

> You're talking about the internal representation of the data, but that
> doesn't have to be directly connected to the way it is presented in
> the UI?

No, but I feel that it's 'good for the soul' to get used to thinking of
all images that have well-described optical properties as 'panoramas'
:-)

The workflow isn't always:

    lots-of-small-images -> combine -> one-big-image

Sometimes it's:

    one-big-image -> extract -> one-or-more-small-images

-- 
Bruno                                           http://bruno.postle.net/