Stitcher parameters affect Optimizer result?

[johnfi...@gmail.com]

If I missed something in the documentation related to this, I'd appreciate being told where that is.

How do the Stitcher parameter values modify the action of the Optimizer?

In experimenting with how well certain actions made a project fit, I was confused over what seemed to be wildly inconsistent results when I thought I had repeated the same test.  By comparing .pto files I found out which step was different.  But that leaves me not understanding why that step has this effect.

So far as I understand, the difference between a.pto and b.pto (both attached) is just values set on the Stitcher tab.  But the optimize results are slightly different and the report from optimize very different.

vs.

The first is quite misleading because stitching shows the fit is pretty good, but not nearly as good as reported.  The actual fit seems to be a bit better in the second where the optimize result is reported as terrible.

[Luís Henrique Camargo Quiroz]

  Hi John!

  the cause is the final output:

  -- a.pto has the default size of 3000x1500 pixels, as you see in the 3rd line of the project: p f2 w3000 h1500 v360  k4 E9.50383 R0 n"TIFF_m c:LZW r:CROP"

  -- b.pto has probably the maximal output: p f2 w21686 h8552 v71  k4 E9.50383 R0 n"TIFF_m c:LZW r:CROP"

  Once I had your same doubts about "sudden" variations in the errors, then I realized the error depends of the output size. Now I ever use the default 3000x1500 when I take notes of my results while optimizing my panoramas.

  I am glad you are trying to improve Hugin. I don't know (yet?) how to program in C++   :(

  regards,

   Luís Henrique

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/d9be3fd1-e9d6-4c1c-81b2-bfc0decb3d79n%40googlegroups.com.

--

--
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.net/

[Jeff Welty]

In addition to the output size being different, the horizontal field of view is different -- for a.pto it is 360.  For b.pto, it is 71.  That is probably making a big difference in the final optimized minimum.

[johnfi...@gmail.com]

On Monday, February 21, 2022 at 6:26:54 PM UTC-5 eljef...@gmail.com wrote:

In addition to the output size being different, the horizontal field of view is different -- for a.pto it is 360.  For b.pto, it is 71.  That is probably making a big difference in the final optimized minimum.

I know that you mean the Stitcher parameter, output horizontal field of view, rather than the optimizer parameter lens Hfov (Horizontal field of view), but I thought that needed to be explicitly said to avoid confusing others reading this.

[Jeff Welty]

John, yes indeed I did mean the output horizontal field of view.  I did a diff on the two files -- and literally the only differences are in the output size (h.... w...) and v....   I am assuming the fov represented by v should be the same regardless of final output resolution, so that seemed to be a clue that was the cause of the difference in optimized results, because it is different, and may  be possible starting point in the optimization?  It is just a guess -- I am not familiar at all with the optimization code in hugin.   As an experiment, I'd take the a.pto, change the output field of view to 71, and see what happens to the optimization.

[Jeff Welty]

Okay, I just did that test.  I have a different explanation -- the output results from the optimization report errors relative to the output horizontal field of view.   I took a pto file, ran the optimization (but did not save the results).   The max error was 3.023, then I made a copy of the pto file, and multiplied the output horz fov by 3, and the optimization max error becomes 9.069 -- exactly different by the factor of 3.   So the optimization itself got to the same result, it's just the scale of reported result changed because of the value of the output horz fov.

[johnfi...@gmail.com]

On Monday, February 21, 2022 at 7:50:20 PM UTC-5 eljef...@gmail.com wrote:

Okay, I just did that test.  I have a different explanation -- the output results from the optimization report errors relative to the output horizontal field of view.   I took a pto file, ran the optimization (but did not save the results).   The max error was 3.023, then I made a copy of the pto file, and multiplied the output horz fov by 3, and the optimization max error becomes 9.069 -- exactly different by the factor of 3.   So the optimization itself got to the same result, it's just the scale of reported result changed because of the value of the output horz fov.

Thanks for doing that test.  That seems to be most of my answer:  The initial report of the error in my example was so unrealistically low because in the normal work flow you compute the alignment before knowing the correct output field of view, so it gets reported based on a default field of view.

But, in my comparison, the optimization result also changed, not just the scaling of the report of the result.  So I expect the other Stitcher parameters also impact the Optimizer.