[ptx] stitching multirows using hugin and autopano

[Mike Runge]

Somebody around here using the combination of autopano and hugin to stitch
large multirows?

I tried autopano several times before, but all the times I was nearly unable
to get good results. Why is that? Is it autopano? Obviously not - a lot of
people are using autopano very successfully. Hugin? I tried autopano on
projects I already finished using hugin. Something special about my images? I
don't think so. I'm taking images with a Fuji S602Z using a selfmade
panohead. Overlap is usally between 20-40 %. The kind of panorama I mostly
try to create is a multirow. Usually I take 4-8 images in a row, 3-4 rows.
(Image setup looks like this:
http://www.trozzreaxxion.net/ut/gallery/multirowpano/abl ).

Yesterday I tried the fresh autopano v1.03beta2 and the really first time
autopano recognized all images belonging to panorama without playing around
with the settings - kudos Alexandre. I loaded the pts-file into hugin, set
the lens parameters and it was still a bit tricky to optimize it.

Just running pairwise optim. results in a very strange result. There was
nothing about using controlpoints distances to fiddle out some misplaced
points. 80% of the controlpoints had delta values higher than 100, some of
them reported a value of more than 1000! Average after optimisation was about
  70.

Just optimising yaw and pitch failed as well - totally crowded panorama. It
was easy to just look at the yaw/pitch table to recognize, that the
optimisation results were totally useless.

I already recognized that hugin has no possibility to to temporary disable
some controlpoint constraints (like some other UI's can). So it's nearly
impossible to optimize a 5x3 multirow with hundreds of points from scratch
(all values are 0, all points are set). While optimising only one row the
single images get hold on position by the images of the row above/below.
Trying to optimize all together fails (due to complexity?!) It seems to be,
that the optimisation runs well sometimes, but fails often because it stucks
within a local minimum (or so)?! 

So the trick seems to be to give the optimiser a short kick into the right
direction. How to do that?
I resetted all values to zero. I specified just pitch values for some images
by hand.
- pitch for all images of row 0 (0-6) to 0
- pitch for all images of row 1 (7-13) to 20
- pitch for all images of row 2 (14-20) to 40

Theses values are not precise, just a very! unprecise guess. I will end up
with a pitch of ~30 for row 1 and about ~56 for row 2!
Then I optimised (Custom optm.) yaw, pitch and roll and everything worked
fine :-))))))

Before the latest autopano version, I struggled with setting yaw-values by
hand as well, just optimimising yaw, then pitch and so on. Sometimes only 2
or three misplaced points crowded the whole project. In the end it was nearly
the same time than picking the points by hand plus digging in the dark how to
solve that autopano-optimisation-puzzle ;-) It much easier for PTGUI users,
because they can specify a starting position for the individual images
graphically. Once the position is ~ specified, optimisation is no problem.

Thanks a lot Alexandre for the great work. It's really fun now to create
multirows :-)

best, mike