[ptx] thoughts for hugin UI, post 0.5

[Pablo d'Angelo]

Hi all,

First of all: I believe there can't be an optimal tab order,
where one does not need to jump back in the tabs. More on this later.

I also wanted to keep the number of tabs as low as possible, for example 
I don't like the many tabs of PTGui.

Rob Park wrote:
> On 6/3/05, Bruno Postle <bruno at postle.net> wrote:
> 
>>1. The "Images" and "Camera and Lens" tabs are the wrong way around.
>>
>>The camera attributes (type, a, b, c, fov etc..) are independent of
>>anything else, in principle they can be known immediately after
>>first loading the images - So they should be in the first tab where
>>the images are loaded.
>>
>>Whereas the roll, pitch and yaw for the photos is generally not
>>known until after optimisation - This information isn't interesting
>>when you start a project and should be on a later tab.
> 
> 
> I think I agree with this one.

So the image list with the positions should be moved into a separate tab 
after the optimize stage?
But usually, an anchor image is needed, so that needs to be defined in 
the Lens tab, as well as a button to edit the anchor image position 
graphically (like the one on the images tab).

Currently this is all on the first tab, because there was space, and it 
is sometimes needed to change the positions before optimisation. The 
lens panel is a bit crowded already, so I didn't want to add all the 
image management functions there. Also control point function that 
relate to the whole pano and not just an image pair are place here, 
because there was space and it was before the optimize tab.

>>The "feature matching (autopano)" box on the first tab is unrelated
>>to everything else, shouldn't it be on the "control points" tab?
> 
> Agreed.

Hmm, but then there needs to be a way how to manage (autopano, delete) 
control points on all images, not just a single pair. -> a new list on 
the control points tab which is already too crowded.
Or maybe all the autopano stuff should be moved into a separate tab, 
where the images to be used could be selected from a list?

>>2. There are settings on the last "stitcher" tab that are not really
>>related to stitching and are more related to to the project itself.
>>
>>The output type (and to some extent the "field of view") is critical
>>to the optimisation step and often needs to be adjusted early on.

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

> I was kinda thinking that those didn't belong on a "stitcher" tab when
> I started this thread, but I couldn't really put it into words and I
> wasn't sure where else to put it so I just left it.

I agree with the projection, but not with the field of view.

>>I'd like an additional "panorama" tab that contained the following:

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

>>- Pull down menu to set the panorama type.
>>
>>- A small preview similar to the existing preview popup.
>>
>>- "Fit" button to adjust the field of view.
>>
>>- field of view boxes to set this manually.
>>
>>- "centre horizontally" button (same as in the preview).
>>
>>- "centre vertically" button.

Except for panorama type, all this is only useable after optimisation.

So it shouldn't be put together in a tab that is placed before the 
optimizer tab.

> I agree with all of this so far, for a "preview" tab to replace the
> preview window.

Actually, the I like the idea of a separate preview window, because not 
so much space is wasted by the other widgets of the hugin window 
(toolbar, tabs etc.).

>>- 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.

Would be a nice feature to have, probably a lot better than the current 
selection of the anchor image position :)

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

> Yeah! A lot of times I'll have a 270 degree pano, and in the preview
> window, image 1 starts in the middle, then it goes to the right, off
> the right edge and wrapping onto the left edge of the output image,
> that's crap, and guessing the proper anchor to get it centered
> properly is hard. Being able to just say "no, put it here" instead of
> having to guess which image to anchor on would be great. Better yet,
> an automatic "figure out where the gap is" button would be nice.

Actually the center button should do what you want, at least in rc1. 
Have you tried it?

>>- The panodruid stuff from the old preview can go here.
> 
> Does anybody really use the druid? I don't think it could ever be as
> useful as the various tutorials out there, I say just drop the druid.
> 
> At least, the druid should be put into some kind of help menu that
> would be accessible from all tabs, to give you advice at every step of
> the way, not just when you're looking at the preview.

Yes, its a bit misplaced at the current position. Actually, it should 
probably have its own window.

Note that the panorama druid can be disabled, if you like to have more 
space on the preview tab.

> Also, it should really be possible to zoom in on the preview. I mean,
> I know the preview is supposed to be a low quality draft thing, but
> when I've got a particularly wide pano, it just scales it down to fit
> the window and you can't see anything at all because it's just so damn
> small.

Maybe later on.


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

  1. add images, sometimes set anchor image and position.
  2. In rare cases, set some initial yaw parameters, for
     very complex 360 deg multirows.
  3. Set lens parameters.
  4. use autopano or create control points manually
  5. change projection
  6. optimize
  7. watch preview
  8. check ctrl points [optional]
  9. optimize again
  10. use preview window to select suitable view (by clicking
      center etc)
  11. set image size and output options on pano panel, and render
      the pano.

Usually I follow (more or less) the sequence above, with multiple 
iterations of 6,7, 8 or 2 or 1, 6, ...
Often I change the projection type after optimisation (usually only
when I create a cylindrical or equirectangular image)

If we want to click through the tabs with minium switching back between 
tabs something like this would be the result:

1. manage images (add, remove, move), edit initial optimisation 
parameters (like lens and image position variables), cropping etc. These 
are all properties for the input images.
2. Control point management tab. Creation of control points, and 
interface for managing them for each pair as well as for more than two 
images (autopano, deletion).
3. tab to set panorama options required by optimizer (just projection 
format)
4. optimizer tab (may be merged with 3. )
5. preview and generic panorama options (field of view, pano size)
6. stitcher options + stitcher execution

However, since the process is usually nonlinear after the first 
optimisation, one needs to go back to 1. or 2. after 3. or 5.

In the current interface the above points are mapped to the following tabs:

1. split into images tab and lens tab
2. pairwise control point management on control points tab, multi image 
ctrl point management on images tab, control point list window.
3. on pano tab
4. optimizer tab
5. pano tab, preview window
6. pano tab

So the current structure is not too bad IMHO, just 3. on the pano tab 
doesn't really fit into the average workflow. However, putting it onto 
the optimizer tab does not make sense, because nobody would expect it 
there.

2) could be split into a control point editor and a control point 
manager (for autopano, ctrl point deletion) tab, and control point list 
window.

But I think the management tab would be a bit empty. Maybe somebody has 
a nice idea how the control point functionality from the first tab could 
be relized within the control point tab).

Having a single window for 5., whether it should be a new tab, or an 
extension of the current preview window, would be a good idea.

ciao
   Pablo