[ptx] Re: how to improve HFOV optimization?

Littlefields - Rik, Janis, Kyle & Peter rj.littlefield at computer.org
Fri Apr 30 05:10:42 BST 2004


Pablo,

I plugged in the fov penalty that I suggested yesterday
 >    ...  scale the errors by 1.0/avgfov
 > to correct for the shrinking image size as fov gets smaller.

It seems to work fine.

Yesterday I gave this example:
 > ...single-row series ... with a [nominal] 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.

With the optimizer mod installed, this panorama now
optimizes to focal length 117mm (fov 11.1)  even if
I start from geometries optimized for focal lengths
as far wrong as 20mm (fov 59.1) and 1000mm (fov 1.3).

Does that sound like what you wanted?

--Rik

Littlefields - Rik, Janis, Kyle & Peter wrote:

> 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/20040429/8ca160cb/attachment.htm


More information about the ptX mailing list