<!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">
Pablo,<br>
<blockquote>Littlefields - Rik, Janis, Kyle & Peter wrote:<br>
<br>
Pablo d'Angelo wrote:<br>
<blockquote type="cite" cite="mid20040426212017.GA873@svalbart">
<pre wrap="">
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.
</pre>
</blockquote>
I regularly use HFOV optimization for partial panos, but yes, there are
lots<br>
of pits to fall into. We should split this topic off to a separate
thread.<br>
<br>
</blockquote>
Now is probably a good time to talk about fov optimization.<br>
<br>
In the current Panorama Tools optimizer, what gets <br>
optimized is the angular distance between control points.<br>
<br>
If you have a wide-angle lens, and lots of overlap between<br>
images, and lots of control points defined, then the fov<br>
is strongly defined by the geometry, and I would expect that<br>
you could optimize fov without any problems.<br>
<br>
For example, I just ran a test with a 2x12 array of images<br>
shot with a nominal 55mm lens, about 200 degrees total width. <br>
For the test, I claimed that the lens was 40 mm and reoptimized,<br>
yielding a (rather distorted) panorama of 280 degrees total<br>
width. Then I enabled fov optimization, ran the optimizer<br>
again, and the thing popped right back to 55mm.<br>
<br>
However, if you do not have so much information, then<br>
optimization is not so trustworthy. For example I have a<br>
single-row series of shots with a 105mm lens (fov 12.3).<br>
It optimizes to average error (as reported by PTGui)<br>
of 0.446 pixels. When I force fov 10 and reoptimize,<br>
the average error drops to 0.445 pixels. At fov 5, the<br>
error is 0.323 pixels. It should be apparent why the<br>
optimizer wants to push fov to zero in this case.<br>
<br>
But of course what is going on is that the image area<br>
occupied by my panorama is also shrinking. In fact<br>
the dimensions shrink first to a factor of 10.0/12.3,<br>
and then to a factor of 5/12.3. Thus the control point<br>
errors measured *with respect to the rendered image size*<br>
are actually getting larger as fov gets smaller.<br>
<br>
I am thinking that to attack the fov problem, it would<br>
be appropriate to simply scale the errors by 1.0/avgfov<br>
to correct for the shrinking image size as fov gets smaller.<br>
<br>
This would not completely eliminate the problem, <br>
since for some sets of control points, the "best" solution<br>
could be to push fov to zero even with the scaling in<br>
place. But it should make things much more stable<br>
than they are now. I don't see why the scaling<br>
should need to be optional -- if you're optimizing fov<br>
then it's appropriate, and if you're not then it's harmless.<br>
<br>
What are your thoughts on this problem & approach?<br>
<br>
--Rik<br>
<br>
</body>
</html>