<!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>
<br>
I plugged in the fov penalty that I suggested yesterday<br>
&gt; &nbsp;&nbsp; ...&nbsp; scale the errors by 1.0/avgfov<br>
&gt; to correct for the shrinking image size as fov gets smaller.<br>
<br>
It seems to work fine.<br>
<br>
Yesterday I gave this example:<br>
&gt; ...single-row series ... with a [nominal] 105mm lens (fov 12.3).<br>
&gt; It optimizes to average error (as reported by PTGui)<br>
&gt; of 0.446 pixels.&nbsp; When I force fov 10 and reoptimize,<br>
&gt; the average error drops to 0.445 pixels.&nbsp; At fov 5, the<br>
&gt; error is 0.323 pixels.&nbsp; It should be apparent why the<br>
&gt; optimizer wants to push fov to zero in this case.<br>
<br>
With the optimizer mod installed, this panorama now<br>
optimizes to focal length 117mm (fov 11.1)&nbsp; even if <br>
I start from geometries optimized for focal lengths <br>
as far wrong as 20mm (fov 59.1) and 1000mm (fov 1.3).<br>
<br>
Does that sound like what you wanted? <br>
<br>
--Rik<br>
<br>
Littlefields - Rik, Janis, Kyle &amp; Peter wrote:<br>
<blockquote type="cite" cite="mid409097F8.5000603@computer.org">
  <meta http-equiv="Content-Type" content="text/html;">
  <title></title>
Pablo,<br>
  <blockquote>Littlefields - Rik, Janis, Kyle &amp; 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.&nbsp; 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.&nbsp; <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.&nbsp; 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.&nbsp;&nbsp; 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.&nbsp; When I force fov 10 and reoptimize,<br>
the average error drops to 0.445 pixels.&nbsp; At fov 5, the<br>
error is 0.323 pixels.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; But it should make things much more stable<br>
than they are now.&nbsp;&nbsp; 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 &amp; approach?<br>
  <br>
--Rik<br>
  <br>
</blockquote>
</body>
</html>