Hi John, without the images Hugin asks for loading them. I took some dummy image. Hugin++ said that there were invalid CPs, probably due to other image dimensions. Optimization ran fast for me, but I think I know where there is the problem.
First I assume: ** You took the images in a "standard way", i.e. by rotating the camera around a tripod or panoramic head. ** You just want so see how the optimizer works when you select nearly all variables to be optimized. The problem is that you select both rotation and translation to be optimized. Normally, you should only optimize for yaw, pitch and roll, but not for trannslations - if you rotated the cammera but didn't perform bigger translations. Instead if you kept the orientation of the camera the same and translated it for the different photos, then you should optimize for translations, but not for yaw, pitch and roll. The reason is the following: Suppose you have a FOV that is not big (like you have). Imagine first you rotate the camera a bit horizontally. Then you rotate it back to the original position and trannslate it a bit horizontally. If the amout of rotation and translation have an appropriate ratio, then the control points will move in a similar way (not much difference) in the image both by rotation and by translation. So the optimizer cannot decide whether you rotated or translated the camera. In some cases you can determine both rotation and translation of the camera, but these cases are usually not relevant for panorama photography: Assume for simplicity you have an ideal (pinhole) camera (no lens distortion). Assume you have 5 (or better 8) points in 3D space that will get control points in the photos. You take two photos of these points by both rotating and translating the camera between these photos. Then there are mathematical algorithms with that you can determine both the relative rotation and the relative translation of the camera. But there are at least two cases in that the algorithms fail or yield bad results (big errors): 1. There is no or little translation in the camera position between the two photos 2. All the points in 3D space are on a plane (e.g. on the wall of a house or on the flat ground plane) In your case you had probably little or no translation of the camera. The optimization problem is mathematically ill-conditioned. Probably the optimizer tries to change the parameters in some direction, but the error changes equally in several directions, so the optimizer cannot find parameters with a minimal error. So, I can image that the optimizer runs for a long time or yields nonesense results. [email protected] schrieb am Samstag, 6. August 2022 um 23:18:33 UTC+2: > I'm getting terrible optimize results (on the one .pto I tested) > Operating System: Windows 10 (build 19043), 64-bit edition > Hugin Version: 2021.0.0.52df0f76c700 built by Thomas > > Is there some option or control in the UI for how hard Hugin tries when > optimizing? > > I set out to get some baseline comparisons of optimization speed, before > trying some ideas I have for making it faster. I tested a bunch of hugin > and hugin++ builds, including > 2020.0.0.2f576e5d5b4a built by Thomas > and > 2021.0.0.52df0f76c700 built by Thomas > > All the others had newer source code from the four repositories built in > various ways. > > The 2020 version had vastly slower optimize but slightly better results > than the cluster of others. > The 2021 version had vastly worse results than all the others and the > second fastest time. I know enough about what is under the hood to know it > can't have timing nearly as good as any of the hugin++ builds I tried via > anything other than just stopping too soon. Stopping too soon is also > consistent with the terrible results. But I don't know why it would be > stopping too soon (compared both to older and newer source code). Was > something changed and then changed back, which explains this? > > Is there some setting I might use to get different builds to do the same > amount of optimization so I can get a more meaningful comparison of various > aspects of algorithm speed and compilation quality? > > I don't yet know whether all this is specific to my example (attached). > I want to do performance comparisons with more than an average number of > images, but don't have many such examples handy. > > I don't have decent explanations for any of the differences between > versions and hope to understand most of those. But the 2021.0.0 results > are just much further outside the pattern. > > My own mingw64 build of the latest hugin++ repository contents is the > fastest, twice as fast as > Huggin++ Pre-Release 2021.1.0.44f97ebcb075 built by Florian Königstein > but with slightly worse results. > I thought I understood all the source code differences and build > differences between Florian's build and mine. But all of that is in other > parts of the code and should not affect optimization. I don't know any > reason the results should differ at all nor any way the performance > difference should be two to one. > > I am also testing my own builds of the current contents of the > hugin/libpano13 repositories with and without the sparse lev-mar build time > option. But trying to interpret those results is pretty useless without > understanding the more basic discrepancies. > > My example has 26 images and a total of 10591 control points, many of > which were accidentally created duplicates that I don't know how to clean > up. But all that trash ought to make it a decent stand-in for a bigger > example. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/d163ccdd-71c3-4411-920b-dc8bf47394a9n%40googlegroups.com.
