I don't think you read my comment, cpfind knows how to only try and match overlapping photos, but somebody needs to write the code to expose it as a separate option.
Again, using an additional configuration file to specify which photos you think overlap is excessive and unnecessary, surely it is much simpler to specify where you think the photos should be placed and let the software figure-out which photos should then overlap. This way you can write a tool to suit your shooting arrangement, or a converter to read the log file from a robot head (see papywizard), or just drag the photos in the preview and send this layout to cpfind to match. We have a framework for this, this is why cpfind uses a PTO project as input, since this way we can specify every kind of hint that a control point generator could possibly need. Nobody is saying that cpfind is perfect and can't be improved, clearly it has a long way to go. The multirow option exists not because we think it is the best way to match a panorama, but because comparing every photo with every other photo doesn't scale, multirow makes a 400 photo panorama practical because the multirow algorithm scales linearly with the number of photos, whereas the default really doesn't. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/936090 Title: cpfind does not handle "matrixmode" correctly. Status in Hugin - Panorama Tools GUI: Triaged Bug description: I'm shooting panoramas in matrix mode. So I do a row, move to the next row and then move along the row again. for example 16 pictures might be taken as follows: 0 1 2 3 7 6 5 4 8 9 10 11 15 14 13 12 I use the "snake" algorithm to reduce the amount of movement of the camera. This means that every picture "n" is adjacent to picture "n+1", but also to some picture in the next row. I haven't managed to get cpfind's matrixmode to analyse the correct image pairs. Determining which images overlap with what others is something that cpfind shouldn't be bothered with. I suggest cpfind implements "linear" and "all" modes, but nothing else. I have implemented a "--checkmatchesfile" option. If specified cpfind will load the image pairs to check from the file. For now I "manually" created the pairs-file with a simple shell script. However the hugin fast preview layout window also "knows" what image pairs overlap. It can easily be modified to output this file! In my case I've also written a script that will create an initial layout for an empty PTO file. The fast preview/layout window will then know "instantly" which images overlap, and should be able to output a nice checkmatchesfile for me. The improvement in quality of the resulting layout is enormous! (it also seems that my checkmatches list is much shorter than the matrix mode default, so it runs faster too. ) I must admit that my C++ skills are a bit lacking. The ugliest part is in PanoDetector::prepareMatches . There I mostly use C to read the checkmatches file. Someone fluent in C++ can easily translate that to C++. The patch also corrects a typo in RANSACOptimizer::Mode getRansacMode . (the name was "setRan...") To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/936090/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~hugin-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
