[ptx] how to improve HFOV optimization?

[Littlefields - Rik, Janis, Kyle & Peter]

Pablo,

    Littlefields - Rik, Janis, Kyle & Peter wrote:

    Pablo d'Angelo wrote:

>Sounds very interesting. I'm still thinking about adding a (optional)
>penalty for the HFOV optimisation, so that it becomes possible to optimise
>it for partial panos as well.
>  
>
    I regularly use HFOV optimization for partial panos, but yes, there
    are lots
    of pits to fall into.  We should split this topic off to a separate
    thread.

Now is probably a good time to talk about fov optimization.

In the current Panorama Tools optimizer, what gets
optimized is the angular distance between control points.

If you have a wide-angle lens, and lots of overlap between
images, and lots of control points defined, then the fov
is strongly defined by the geometry, and I would expect that
you could optimize fov without any problems.

For example, I just ran a test with a 2x12 array of images
shot with a nominal 55mm lens, about 200 degrees total width. 
For the test, I claimed that the lens was 40 mm and reoptimized,
yielding a (rather distorted) panorama of 280 degrees total
width.  Then I enabled fov optimization, ran the optimizer
again, and the thing popped right back to 55mm.

However, if you do not have so much information, then
optimization is not so trustworthy.   For example I have a
single-row series of shots with a 105mm lens (fov 12.3).
It optimizes to average error (as reported by PTGui)
of 0.446 pixels.  When I force fov 10 and reoptimize,
the average error drops to 0.445 pixels.  At fov 5, the
error is 0.323 pixels.  It should be apparent why the
optimizer wants to push fov to zero in this case.

But of course what is going on is that the image area
occupied by my panorama is also shrinking.  In fact
the dimensions shrink first to a factor of 10.0/12.3,
and then to a factor of 5/12.3.  Thus the control point
errors measured *with respect to the rendered image size*
are actually getting larger as fov gets smaller.

I am thinking that to attack the fov problem, it would
be appropriate to simply scale the errors by 1.0/avgfov
to correct for the shrinking image size as fov gets smaller.

This would not completely eliminate the problem,
since for some sets of control points, the "best" solution
could be to push fov to zero even with the scaling in
place.  But it should make things much more stable
than they are now.   I don't see why the scaling
should need to be optional -- if you're optimizing fov
then it's appropriate, and if you're not then it's harmless.

What are your thoughts on this problem & approach?

--Rik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.email-lists.org/pipermail/ptx/attachments/20040428/31ad6df9/attachment.htm