Jump to: navigation, search

Talk:Autopano Lite Talk


Nice comment, added some of those in the page itself.

GURL 17:07, 19 February 2007 (CET)

AutoPano Lite must be easy and fast?

Here is an easy and fast way to specify it ...where the criterions I used are more important than the suggested items (as an example if a very fast RAW converter is available I don't see any reason not to use it and dito for the Links Editor if it evolves in such a way that optimization or lens distortions have no more to be understood to use it.

1) Fast speed

This is the easiest part: no giant mosaic allowed, 60" x 20" at 250 DPI (150 x 50 cm at 100 dots per cm) roughly corresponds to a 75 MP final image.

- Ten 10MP shots or fifteen 6MP shots are allowed and no more.

- No RAW.

2) Easy use


This will decide of the percentage of possible users who will buy the product after one or several attempts at using the trial version. It's clear for me that a photographer who is able to read APP documentation about program settings, projection modes and Links Editor should rather buy the Pro version.

  • No Layer editor: I firmly believe that using Photoshop (or any other) layers is easy but layers being difficult to grasp and being reserved to - advanced peoples is a widely accepted opinion... No PSD/PSB
  • No program setting. If the default detection quality results in a scrambled pano in the preview the only possible option is a "try harder" button where the user is warned this will be much slower (BTW the corresponding settings could be derived by APL from source images amount and size, processor speed and available memory and disk space because High Detection Quality for a two 6MP shots pano on a recent computer is probably faster than Standard Detection Quality for a ten 10MP shots pano on an old laptop.)
  • No Links Editor (obvious).
  • Projection modes: preview use spherical projection like APP, but
 if vertical FOV is such that it's both lower than 45 degrees above the horizon and lower than 45 degrees under the horizon then
if horizontal FOV is lower than 90 degrees then a planar option is shown as a second preview else a cylindrical option is shown as a second preview endif endif

(user selects the one he/she prefer.)

  • No HDR: if this is needed (exposure difference larger than 2 or 3 EV ?) the user is warned that the resulting pano needs advanced processing using the Pro version.
  • No Levels tool: black point and white point can be set automatically so that a manual setting is not mandatory. This is not an obvious decision: many photographers know of brightness and contrast and many point and shoot cameras have provisions to change them. As a matter of fact, one criterion to define APL versus APP could be the boundary between "Histogram literate photographers" and "Curves literate photographers"...
  • Crop tool: this is a very popular tool among photographers. Experience shows that some users find difficult to find out how to validate the crop but any software must have some not so obvious trick reviewers are happy to explain to their readers. About the "Uncrop" tool: either forget this one or change its icon (which should be identical to the Crop tool icon but overlaid by a red check-off cross.)

Before getting into the next paragraph, here is a summary derived from APP Editor tool-box:

APL tools.jpg

3) Two unanswered issues

a) Which blender ?

For most panoramas Smartblend is better but:

  • no Smartblend preview is available
  • Smartblend is slower than Multiband
  • sometimes Multiband output is better

b) The horizon...

When using a tripod or pano-head where the vertical axis of rotation is vertical enough, the horizon placement is easily cured by APP.

For hand-held panoramas or poorly adjusted tripods this is not true and, as far as I know, no automatic stitcher tool using images contents has been used until now. My guess is that this should work for an unknown percentage of architectural panos, should seldom work for landscape panos, etc...

My opinion about present APP tools like Set Center Point or Set Verticals is that they are to difficult to explain in their existing form to meet the above requirements but that large improvements are possible if the main goal is "no documentation is needed to get a panorama which don't lean to the left or the right and where the horizon line (if present) is not curved."

4) Note about interface design

This is another subject. Questions like having an optional panorama editing step between Detection and Rendering or automatically calling a viewer to display the final result should be discussed...