On 17 August 2010 22:46, Yuval Levy <[email protected]> wrote: > Some sort of control point detection should be run before even considering > type of lens, focal distance, crop factor, to validate such inputs / defaults.
When the type of lens is unknown, it would be useful to rerun the optimisation using a different lens type and compare the error distances. This could be done automatically, though ideally we would have a nice lens database that just knew all this stuff. > At the detection level detect first for time-adjacent pictures rather than > blindly across the board. This will yield more information to make better > estimates: > - if there are groups of disconnected pictures, it is likely to be a multi-row > project with "carriage return" between rows (but it could also be multiple set > of unrelated panoramas) > - if the sequence is all connected, it is likely to be either a single-row > project or a "snake pattern" multi-row > Same thing with the optimizer: an "auto" mode should not just make a single > optimization run, but rather a multi-staged approach: first optimize for > positions only. Then check if the images at one end overlap images at the > other end. These are approximately the steps of the existing 'multi-row' control-point detection, it is slow at the moment because it relies on the XML keypoint-file caching of autopano-sift-C. The new panomatic code will be more efficient with this caching. -- Bruno -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
