[ptx] Hugin vs. PTGui - some observations

[JD Smith]

On Tue, 2006-08-01 at 12:16 +0200, Mike Runge wrote:

> I posted this one as a reply to panotoolsNG, but I think it belongs to this list. Unfortunately I could not crosspost :-(

Thanks for the useful observations, Mike. 

> A friend of mine bought PTGui - so we were sitting together trying Hugin and PTGui on the same panorama (6 6MP images taken with the Sigma 8mm).
> 
> The main advantage of PTGui I have observed:
> It's dammend easy for beginners. The simple mode developed a good result just clicking a handful of buttons without knowing how panotools are 'ticking' - great!
> This is very remarkable since in the early days of hugin one of Pablo's major targets was to develop an easy to use/learn panorama frontend. I think hugin is stable, comfortable, easy to use, but  it's definitevely not easy to learn.
> 
> Things have changed a lot and meanwhile it's easier than ever to start developing panoramas. Hugin (and PTGui as well) gives you a complete package and straight from downloading and installing you can start - that's really cool.

Its main platform, Linux, still suffers from a complex dependency chain,
but hopefully that will resolve itself once it gets included in various
distributions.

> Using autopano-sift/autopano within hugin is fine. Best results I get using autopano-sift without ransac check. So there are wrong controlpoints I need to filter for. Usually I optimize 2-4 times and delete the points with very large values  using the controlpointlist. That are only a few clicks, but a newbie will stumble on this.

How do you find the speed compared to PTGui's finder?  On OSX at least,
this is the slowest part of the entire workflow.  Relying on the
autopano* is a bit dangerous for Hugin, since they haven't been
supported much lately.

> My recommendations to make Hugin more newby-friendly:
> - A wizard/druid (maybe a range of wizards "Spherical with Fish", "Multirow with Rect", etc..) that triggers autopano/-sift with useful parameters, does basic optimisation and cp filtering, stable post-optimisation, comes up with a preview and shows a short report what you can do next to improve your panorama (or a button "Stitch Now?").

A similar concept is to collapse some of the preferences to something
much simpler to understand.  For instance, the "FineTune" tab has
options: patch width, search area width, local search area width,
correlation threshold, and peak curvature threshold.  Beginners will
have no idea what all this means (even I don't have 100% clarity on all
those options).  They might instead prefer a single slider with
conceptual end points:

Faster <---------------------------> More Accurate

with some carefully pre-chosen settings along that slider, based on
image size, etc.  There are other examples of this overly technical
areas.  The details can be hidden behind an "advanced" pane if
necessary.

> - A bad-cp-filtering-by-optimisation tool would be nice as well for advanced users.

In fact, and button or menu option like "Trim Outlier Control Points"
available after optimization could prompt with "8/168 control points
deviate by 5 pixels or more.  Remove them and re-optimize?"  The "5
pixels" would be variable, based perhaps on the standard deviation of,
or median absolute deviation, of control point residuals.  

> - A basic HTML creation tab (just some fields for author, title, template, etc.) to create a folder with ptviewer, an html file (using a HTML template file), and the equirectangular image in would be a nice goodie for beginners too.  

Very useful idea.

One other issue I see relates to the interface.  At least on OSX, the
default window sizes are horrible.  Preference panes do not show their
entire contents and have to be resized (the traditional OSX method is to
have a minimum size for preference panes).  Column headers for images,
control points, etc., are written in a small font, and are not large
enough to be useful when data are loaded, and the bottom of letters like
"g" are cut off.  

None of these are horrible usability issues, they just contribute to a
certain lack of polish.  Ideally, the column widths would auto-stretch
to match the space available, and the column/frame sizing would start
with sensible defaults, so that all parts of the interface are visible
on startup.  I have some ideas for how to devote much more of the
interface to the image and relevant data, rather than buttons.  For
instance, rather than having an inert "ANCHOR" column, make it a column
of check boxes (or two: one for position, one for exposure).  Move to
the menus items like "adjust anchor spot...".

Hugin is really coming along!

JD