Why is it called "Optimiser" and not "Alignment"?

[Markkk]

Hi

First: many thanks to all the contributers of hugin and tools. Great
achievment!

Just a small usability issue: it took me a long time to figure out,
which of the tabs corresponds to the "2. Align..." step of the
Assistant.

From my [foreign language] understanding, the word "optimise" denotes
"further refinement". An act of improving an otherwise complete
result. A step that could even be left out for a crude first look
(which obviously is not the case here).

Kepts dismissing that tab as "yeah, we can optimise later, where the
heck is alignment?" ;-)


-Mark

[Tom Sharpless]

Hi Mark

You have put your finger on a major weakness in Hugin's stitching
flow.

There should be an "alignment" tab that lets you see and adjust the
layout of photos, whether or not it has been "optimized".
And there should be some alignment procedures in the software, that
operate at a higher level than just minimizing the average squared
distance for all control points.

Some progress is being made on these needs, but it has not yet come
together as a complete package offering a smooth user experience.
There is a new graphical "layout" facility, and eventually the
"panomatic" control point finder will use layout information to
improve the quality of its control points. But I don't think anybody
is working on high level alignment algorithms at present.

It would be nice if Hugin could do automatic alignment as well as
PTGui does. I don't know what is inside, but it is clear from the
outside that PTGui's alignment algorithm has 4 or 5 major steps, the
last of which is optimization. However PTGui doesn't offer the user
any control over this procedure, or allow one to specify the starting
layout. Both of which could ultimately make for quicker and better
alignments.

Cheers, Tom


Some progress

[Aron H]

I definitely agree here. The Gigapan robot and it's Stitcher software
show how easy it can be to get that initial layout with constraints -
it always takes pictures on a grid, so you just have to specify how
many rows there are, and suddenly you can preview the shape and
content of your panorama from a grid of thumbnails.

I realize this is too constrained for many applications, but if you
are taking pictures on a Nodal Ninja or other panorama head, the user
could specify rows/columns and spacing fairly easily, to get started.
Next, we might add the ability to have rows of different lengths, and
a separate spot to put 'free' pictures like an overhead/straight down
shot.

Then, the control point generators could look only at overlapping
pictures, and avoid the swirling knots that sometimes result from
totally 'free' alignment.

As a user, the way I work around this right now is using template
projects. For a particular shooting pattern, I type in the orientation
of each of the photos, and save the project as a template...

Regards,
Aron

[Dale Beams]

type in the orientation & position? how?

i'm interested.

Dale

[Bruno Postle]

On Tue 22-Jun-2010 at 08:54 -0700, Aron H wrote:
>
>I realize this is too constrained for many applications, but if you
>are taking pictures on a Nodal Ninja or other panorama head, the user
>could specify rows/columns and spacing fairly easily, to get started.
>Next, we might add the ability to have rows of different lengths, and
>a separate spot to put 'free' pictures like an overhead/straight down
>shot.
>
>Then, the control point generators could look only at overlapping
>pictures, and avoid the swirling knots that sometimes result from
>totally 'free' alignment.

I'd really like to see some testing of the existing 'multi-row'
control point generation feature in the current trunk.

This is not going to be fast because it currently uses the
generatekeys/autopano pair from autopano-sift-C, it also doesn't
work well with wide-angle photos for the same reason.

It should however deal with the multi-row problem without resorting
to complex new GUIs.

--
Bruno

[Emad ud din Butt]

Hugin is on top of all softwares when it comes to PICTURE QUALITY. nobody matches its final picture output. But its slow and sometimes confused into making first proper layout. I am referring to my 150 (5 rows) picture panoramas. So I have to load it first in Autopano pro trial. It give me my first layout and it exports pto file with 3 cps. But layout is intact when i load it in hugin. I Generate extra CPs, optimize and thats it. Autopano takes 10 minutes whereas Hugin takes almost 1 hour for first layout. 

Grid idea is really nice and handy. If we have option to define a grid layout ourselves and than hugin connects overlaps. For example  30 x 5 grid for my panorama. Or 1 x 20 grid for linear panorama. It can increase speed. Grid can make things simpler. Even for a linear panorama.

But Bruno you know how things are made and you can better judge that its possible in hugin or another Patent free item is going to pop up :)

--
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

--
_________________________________
Emaad
www.flickr.com/emaad

[Erik Krause]

Am 22.06.2010 15:31, schrieb Markkk:
> From my [foreign language] understanding, the word "optimise" denotes
> "further refinement". An act of improving an otherwise complete
> result. A step that could even be left out for a crude first look
> (which obviously is not the case here).

This is a legacy from the mathematical background of panotools.
Optimization in this context describes the iterative process of altering
the parameters such that the control point distance finds an optimal
minimum. The mathematical algorithm is called Levenberg-Marquard
optimization:
http://en.wikipedia.org/wiki/Levenberg%E2%80%93Marquardt_algorithm

--
Erik Krause
http://www.erik-krause.de

[paul womack]

Erik Krause wrote:
> Am 22.06.2010 15:31, schrieb Markkk:
>> From my [foreign language] understanding, the word "optimise" denotes
>> "further refinement". An act of improving an otherwise complete
>> result. A step that could even be left out for a crude first look
>> (which obviously is not the case here).
>
> This is a legacy from the mathematical background of panotools.
> Optimization in this context describes the iterative process of altering
> the parameters such that the control point distance finds an optimal
> minimum.

(cough)*local* minimum(/cough)

BugBear

[Erik Krause]

Am 24.06.2010 10:00, schrieb paul womack:
>> > Optimization in this context describes the iterative process of altering
>> > the parameters such that the control point distance finds an optimal
>> > minimum.
> (cough)*local* minimum(/cough)

Gesundheit!

Sorry, you are absolutely right. However, isn't there a technique
implemented that tries other start values in order to find a better
neighboring minimum? I must admit that I don't know much about the
internal workings of the optimizer.

[Aron H]

On the Assistant tab, I load my images. Then on the Images tab, I
select each image, and in the Image Orientation entry at the bottom, I
type in my estimate of where the image should go. For a Nodal-Ninja,
the Roll is always -90, and the Pitch can be read off the upper-most
rotation knob for a row. The Yaw will correspond with 'clicks' if you
use the detente-plates that some models come with, for instance 30
degree increments.

I can do that once, then save that shooting pattern as a template. I
think it works well with 2 or 3 row panoramas.
Aron

On Jun 22, 12:01 pm, Dale Beams <drbe...@hotmail.com> wrote:
> type in the orientation & position?  how?
>
> i'm interested.
>
> Dale
>
> On Tue, 2010-06-22 at 08:54 -0700, Aron H wrote:

> >[....]