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/02062b42-0859-493b-adac-be36963088f7n%40googlegroups.com.

Reply via email to