This may or may not be helpful -- but in the SkyFill program I found a version of levenberg marquardt that will fit with constraints on the parameters. I *think* it is derived from the source code hugin has (lmdir.c), so functionally might be quite close to what it in hugin. You can find it at: http://cow.physics.wisc.edu/~craigm/idl/cmpfit.html
It's set up so any parameters can have an upper or lower constraint (or both, or neither). So the user could request the FOV (if it is a parameter in the fit) have a final fit value between the upper and lower constraint. In the little bit of testing I have done it seems to help avoid falling into a local minimum for the optimization. Jeff On Sunday, February 13, 2022 at 4:11:27 AM UTC-8 [email protected] wrote: > I think that problem is important and ought to get some attention and can > be solved. > > But I think your suggested solution would not be effective. Either the > user would need to know enough in setting the limits that they might as > well just set the value and not optimize the variable, or automatically set > limits would do more harm than good in other cases. > > Based entirely on use, without yet even looking at the relevant part of > the code, I'm guessing both sources of a control point are projected into > their theoretical positions and compared there. That approach would be > inherently unstable and lead to finding wrong solutions that have lower > "error" than the right solution. That fits the observed behavior, thus my > guess. > > Projecting one point to its theoretical position and then back to the > other image (and computing the error there) would be inherently much more > stable. But given varying zoom level across the input, that could > inappropriately weight control points. Effective zoom level could vary > within an image due to the original lens distortion as well as varying > original zoom in the images. But my guess is that the weight problem could > be solved more easily than other approaches to fixing the original problem. > > I might be 100% wrong about all of this. I hope to find time to look at > that part of the code and really understand why optimize is so likely to > find wrong answers. But in working on many other optimize problems in many > other domains, my experience tells me that stricter limits are likely to be > a bad cover up for a problem that needs to be fixed elsewhere. > > -- 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/8fca6d62-2eb1-49dd-8b87-3a76887927c0n%40googlegroups.com.
