[ptx] thoughts for hugin UI, post 0.5

[Bruno Postle]

On Sat 04-Jun-2005 at 21:38 +0100, Pablo d'Angelo wrote:

> So the image list with the positions should be moved into a separate tab 
> after the optimize stage?

It could just be the second tab, I just think the lens tab should be
first and contain the "load images" stuff.

> How is the panorama field of view critical for the optimisation step? 
> Its not even used by the optimizer, as far as I know.

It isn't, but I see it as very closely linked to the panorama type
and should be in the same place.

> Hmm, where should the panorama tab be placed? just before or after the 
> optimizer tab?

Either has advantages.  There is never going to be a perfect order
for these things since any serious stitching involves an iterative
process, jumping back and forth between tabs.

> > > - I'd quite like an interactive tool to manually pan, roll and zoom
> > > everything.  I currently do this by guessing values for the anchor
> > > image which is awkward at best.
> 
> Do you mean operations that can be used to specify yaw, pitch roll for 
> the panorama camera? This would essentially be a way to move and rotate 
> the currently fixed axes in the preview window, and then apply the changes.

> By zooming, you mean adjusting the HFOV/VFOV of the panorama?

Yes, this is why this would be a different thing from the current
preview.

If the existing preview pop-up gained zoom functionality, it should
be a simple enlargement with scroll-bars and middle-mouse panning -
These wouldn't change any panorama parameters.

The new tool would be a mini-panorama editor; zooming would change
fov, mouse panning would change pitch and yaw, and some other method
would adjust roll (this would also be the ultimate cropping tool for
single photographs).

So the tab that contains this new panorama editor needs to also
group all the other stuff that changes the output panorama: fit
button, centre button, hfov, vfov and panorama type selector.

Image dimensions, file format, rendering engine, colour correction,
interpolation etc.. are something else, they are tweaking the output
process but don't fundamentally effect the panorama itself - They
can never effect the internal preview for example.

> But maybe we should analyse the typical steps during
> creation of a panorama, this is roughly what I usually do:

I don't think reducing the amount of tab switching is that
important, but there is functionality that is just in very
un-obvious places:

* The centre and fit buttons are in a preview pop-up.  Nothing in
the preview should be able to alter the project since it is an
optional viewer (and very resource intensive).

* The panorama type and fov are mixed-in with rendering options.  It
should be possible to use hugin without ever touching the stitcher
tab until the end of the process.

-- 
Bruno