[ptx] thoughts for hugin UI, post 0.5

[Rob Park]

On 6/4/05, Pablo d'Angelo <pablo.dangelo at web.de> wrote:
> 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'm not saying jumping back in the tabs is a bad thing. For a while
I've had this thought that hugin would benefit from a wizard-like
interface, but I always come to the conclusion that the stitching of
panos is inherently non-linear, that you need to be able to easily go
back to an earlier step in the process and tweak the settings, and
that the tab interface essentially provides exactly this: You can
"kinda" go from one tab to the next in the same way that a wizard
would provide the options to you in a linear fashion, but they also
let you bounce around to what you need to change next easily.

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

Well, you have to find a balance between "many tabs with few widgets
in each" vs. "few tabs with many widgets cramped into each".

My stance is to group things that are logical to be grouped, and not
group things that aren't logical to be grouped. If it means adding a
few tabs to alleviate clutter on the existing tabs, that's fine with
me.

I'm not familiar with PTGui, so I don't know how many tabs it has.

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

Well, ideally we could get rid of the anchor image idea entirely. 

> Currently this is all on the first tab, because there was space,

I think this is a bad excuse to justify UI design ;)

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

Hey, whoa whoa there, nobody was saying anything about a new image
list on the control points tab. Just because we want to move the
control point functions onto the control points tab doesn't mean we
want to change them to be pairwise-only controls. The autopano
"generate control points" buttons (etc) should just be on the control
points tab.

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

Please, no, don't add any extra image lists, I already feel that the
image list on the "images" tab and the image list on the "camera and
lens" tab are kinda redundant.

Autopano-sift already has a nice GUI, why does hugin even need to
recreate it at all? I think maybe the autopano support should be
ripped out of hugin. I just don't like to see this kind of duplication
of effort ;)

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

Well, I'm not sure about the optimizer, but the field of view has a
direct effect on the preview window. preview is usually something you
do right after optimizing, so the settings for field of view could
maybe appear at or before the optimization tab.

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

Well, I think that "projection" and "field of view" are related and
should be kept together ;)

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

Agreed.

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

Well, if I could zoom in on the preview, it wouldn't be a problem ;)

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

I think that's what was meant. 

> This would essentially be a way to move and rotate
> the currently fixed axes in the preview window, and then apply the changes.

Yes.

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

Yes! We could abolish the idea of an "anchor image" entirely (maybe
still use it internally or however you want to implement it, but it
shouldn't be exposed to the user).

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

I haven't tried it in rc1. I just remember it only working with
relatively narrow panoramas (I'd guess 180 degrees or less).

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

I'm not sure about dedicating a window to it, what I'd like to see
more is just proper documentation that could be displayed with the
native Help browser of whichever platform (gnome has a Help Browser,
so does windows, and I'm sure OSX must have something similar).

Eg, open any GNOME app (like, say, gEdit), and then select "Help" ->
"Contents" from the menu, something like that for hugin.

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

You're not suggesting that we have a whole tab with *just* the
projection setting on it, are you?

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

Don't worry so much about flipping back and forth between tabs, just
make sure that related information is kept on the same tab ;)

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

Hmmm, not sure.

-- 
Urban Artography
http://artography.ath.cx