[ptx] Hugin vs. PTGui - some observations

[Mike Runge]

Hi JD,

please see my remarks between the lines.

JD Smith wrote
>   
>> 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.
>   
Hard to tell. My PC is a bit faster and has twice the memory the one of 
my collegue has. Altough  PTGui's finder was faster.
>   
>> 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.
>   
Probably more complex to develop, but better for the users. That's the 
way PTGui goes too.
>   
>> - 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.
Whatever solution will filter for bad points: It should use the 
optimization process  and it should be possible to set a kind of 
effectivity like "more than 40% above average  or so."
>   
>
>   
>> - 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.
>   
It's clear, that it is not the main task of Hugin to develop panorama 
web presentations. But I think it will help beginners a lot.
I met a friend in cologne a few weeks ago and he had a laptop with WLAN 
and was interested in panoramas. We just shot some images with my 
camera, downloaded the hugin package, installed it an developed a 
360x180deg panorama. Just within 20 minutes we were able to watch our 
own sperical (in panoglview). My friend was very impressed. I would like 
this "Just 30 minutes from a fresh PC to your own pano on the web" thing ;-)
> 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...".
>   
Sorry - I have no experiences with OSX. On windows the most suffering 
thing is the "You need to hit Enter/Tab after keyin in a value" thing.
I would like to keyin values for y, p, r, etc. directly in the rows 
(idealy in the optimizer), but I still need the possibility to handle 
multiple rows at once. Any ideas?!
Sensible defaults are a very, very good idea!

One thing about the new de-vignetting functionality:
- can we save/load a calculated polygon curve?
- can we influence a calculated/loaded polygon/faltfield file by a 
simple slider (brighter/darker). E.g. connected to the used apperature?
> Hugin is really coming along!
>   
YEP! I love Hugin :-)

best, mike
> JD
>
>
>
>