<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Damien,<br>
<br>
Is your "wavy horizon" a smooth sine curve with one high and one low
spot opposite each other on the 360 degree horizon?&nbsp; Or is it kind of
wiggly, with multiple cycles and/or irregularly spaced high and low
spots?<br>
<br>
If it's a single sine curve, then it's just unlevel, in which case a
couple of well-placed vertical controls really should take care of the
problem.&nbsp; If it's kind of wiggly, with no significant component of a
single-cycle sine wave, then you've probably got the many-small-errors
problem that will be harder to deal with.<br>
<br>
If I remember correctly, the panotools optimizer uses horizontal offset
in the pano as the error value for vertical controls.&nbsp; You should be
able to look at the error report to see how well these are being pushed
to zero.<br>
<br>
>From your email, I can't hear what's going wrong.&nbsp; Perhaps you could
post out an image showing the problem?<br>
<br>
Also, the panotools wiki has a page called "Leveling a Finished Pano"
that talks about several options for leveling.&nbsp; You might read that for
ideas -- most of them apply even when you have multiple input images.&nbsp;
You might also try exactly what's described there, to try straightening
your wavy horizon by remapping the finished pano.&nbsp; That takes all of
your ordinary control points completely out of the problem.&nbsp; See <br>
<a class="moz-txt-link-freetext" href="http://www.panotools.info/mediawiki/index.php?title=Leveling_a_Finished_Panorama">http://www.panotools.info/mediawiki/index.php?title=Leveling_a_Finished_Panorama</a><br>
<br>
--Rik<br>
<br>
Damien Douxchamps wrote:<br>
<blockquote type="cite" cite="mid1145260177.3712.61.camel@localhost">
  <pre wrap="">Hello Rik,

On Sat, 2006-04-15 at 09:46 -0700, Rik Littlefield wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Damien,

I wrote parts of the panotools optimizer, and I think that hugin still 
uses the same approach.

There are two main classes of problems.

Class 1.  Your images stitch together nicely with each other via 
ordinary t0 control points, but the whole panorama happens to come out 
not "level".  In theory, and usually in practice, this can be entirely 
corrected by only two vertical controls, preferably about 90 degrees 
apart.  This is because the error contributed by t0 control points is 
not affected by overall rotation of the sphere.  If you have many 
ordinary control points, then the vertical controls are relatively weak, 
but still they are usually strong enough that the optimizer needs only a 
few of them.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This appears to be my case since the average error is .16 pixels (the
max is .73) for about 270 control points. The panorama looks very well
stitched too (except for the wavy horizon)

  </pre>
  <blockquote type="cite">
    <pre wrap="">Class 2.  Your images do *not* stitch together nicely with each other, 
so it is not enough to just level the whole panorama.  This is often due 
to parallax, misplaced control points, or uncorrected lens distortions.  
It can also be caused by subject motion, such as movement of trees or 
clouds that are often chosen by automatic control point pickers. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
My pano consists mainly in buildings so there is no problem like motion
here. Perspective can be tricky in the near field but carefully choosing
the points is not too difficult in my case.

  </pre>
  <blockquote type="cite">
    <pre wrap="">If you find yourself needing lots of separate vertical controls, then 
you probably have class 2.  That is unfortunate.  Class 2 is very hard, 
because you are trying to force an attractive balance of fairly large 
errors, rather than find parameter values that will push all the errors 
very close to zero like in class 1.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
What I usually do is pick many points, then run the optimized and delete
the ones that yield a bad match. Then re-run the optimizer, ... This way
the bad points a filtered almost automatically.

  </pre>
  <blockquote type="cite">
    <pre wrap="">The best advice is to avoid class 2.  When taking pictures, be sure that 
your camera rotates properly around the "no-parallax point" (entrance 
pupil of the lens).  Avoid placing control points on features that could 
possibly have moved between images.  Be sure that you do not have any 
misplaced control points.  (Study the lists of errors -- individual 
control points that have large errors are likely to be misplaced.)  Do 
not use "straight line" controls (type t3+).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Its seems we do the same thing regarding the lists of errors ;-) With
hugin my control points are all t0 and t1 so I guess I'm not using
t3(+).

No problems with motion given the nature of the panorama.

  </pre>
  <blockquote type="cite">
    <pre wrap="">If you cannot avoid class 2, then there is not a lot that the software 
can do to help you.  As you suggest, the optimizer could be extended to 
include explicit weights.  This would reduce the run time a little, but 
it would not change the underlying problem that class 2 really requires 
optimizing a human judgement "subjective" function (attractiveness) 
rather than a purely computational "objective" one (stitching error and 
leveling).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yeah, being familiar with camera calibration I would not even try to
deal with class 2 in the first place ;-)

  </pre>
  <blockquote type="cite">
    <pre wrap="">The one exception to all this is if you have long skinny panoramas, say 
20 or 30 horizontal frames in a single row.  In that case, small t0 
errors can accumulate to produce significant waves, even when the 
panorama is level overall.  But this is usually handled well by adding 
just one or two vertical controls per image.  From your description, I 
would guess that you don't have this situation.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I have 11 photos (4MP each) in a single row for a 360&deg; panorama. The
vertical FOV for each photo is 36&deg;. So maybe I'm having this problem
after all...

Maybe a solution would be to stitch photos 2 by 2 and then put these
bigger blocks together?

  </pre>
  <blockquote type="cite">
    <pre wrap="">Again, best advice is to avoid class 2.  If you shoot carefully and 
place ordinary control points carefully, you should need only two 
vertical controls..
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I just tried that but it's still wavy. Duh. Is there a way to verify the
adequacy of vertical control points? (for example, which line angle was
detected) 

  </pre>
  <blockquote type="cite">
    <pre wrap="">Hope this is helpful,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Sure, I'm learning every day :-)

  </pre>
  <blockquote type="cite">
    <pre wrap="">--Rik

PS. Just to be sure the basics are covered...  To get proper leveling, 
you must allow the optimizer to adjust pitch, roll, and yaw of all 
images.  You can set the yaw of one "anchor image", but you must 
optimize pitch and roll even for that anchor. 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I first adjust the position/attitude, then everything. The default
setting in Hugin is indeed to fix one yaw, and that's what I'm doing.

Thanks for your help,

Damien

  </pre>
</blockquote>
</body>
</html>