I don't understand why matrixmode works so horribly then. There is a tendency to say: "Oh, but this program can do that too". This results in complex programs that work when the programmer was thinking of exactly what you want, and that it won't do what someone else wants when he wants something slightly different.
So, in my "big" shot, I can currently (with my patch) tell cpfind to only do detections on the direct neighbours. Just horizontal and vertical. I can also tell it to do also the diagonal neighbours. All this is external to cpfind, and making additional choices is easy. This "make one program do everything" attitude is exactly what hugin should not be about. If we follow the unix strategy of making small programs that "do one thing and do it well", then we have building blocks that allow us to build great things. cpfind is the control point finder. THAT is the one thing it should be built to do, and THAT is what it should do. Suggestions like: just call it with two files, then it will just read the cached keypoint files and match between those two files. Well great! But then you incur the cost of starting up cpfind multiple times. But also the reading of the cache-keypoint-files. In my case, every keypoint file would then have to be loaded twice. If I want the diagonal matches as well, this becomes "four times". I was told that reading the keypoint file is almost as expensive as doing the keypoint detection again. Now, when I get my way, and we would separate the overlap-detection into a separate program, then it would be easy to build a "multirow" mode again. Just run cpfind, run a quick optimize, run the overlap detection and run cpfind on the image pairs we haven't done before. Simple. If however something goes wrong, or needs adjusting in the middle, there is an "interface" available where another program can be made that does the adjusting. Or the user might adjust manually. With the current situation there is simply NOTHING you can do when it doesn't work properly. Even debugging is difficult. Now, take my "big pano" for instance. I have put all the images on a "regular grid". There is almost 50% overlap in each direction. Image 0 overlaps with image 1, and with image 19. Image 1 then overlaps with image 0 and 2, and in the next column with 17, 18, and 19. If you claim that this is detected by cpfind, then there is something horribly wrong: I feed cpfind this "default layout" where there is exactly the same amount of overlap. When I run --multirow, after checking 1-2, 2-3 etc up to 378-379, I get: --- Find matches in images groups --- i0 <> i8 : Found 0 matches i0 <> i9 : Found 0 matches i0 <> i10 : Found 0 matches i0 <> i11 : Found 0 matches i0 <> i28 : Found 0 matches i0 <> i12 : Found 0 matches i0 <> i29 : Found 0 matches i0 <> i30 : Found 0 matches i0 <> i31 : Found 0 matches i0 <> i32 : Found 0 matches i0 <> i33 : Found 0 matches i0 <> i46 : Found 0 matches i0 <> i47 : Found 0 matches i0 <> i48 : Found 0 matches i0 <> i50 : Found 0 matches i0 <> i49 : Found 0 matches i0 <> i51 : Found 0 matches i0 <> i52 : Found 0 matches i0 <> i53 : Found 0 matches i0 <> i66 : Found 0 matches i0 <> i67 : Found 0 matches i0 <> i68 : Found 0 matches i0 <> i69 : Found 0 matches i0 <> i70 : Found 0 matches i0 <> i72 : Found 0 matches i0 <> i73 : Found 0 matches i0 <> i88 : Found 0 matches i0 <> i89 : Found 0 matches i0 <> i90 : Found 0 matches i0 <> i130 : Found 0 matches i0 <> i131 : Found 0 matches i0 <> i148 : Found 0 matches i0 <> i149 : Found 0 matches i0 <> i150 : Found 0 matches i0 <> i168 : Found 0 matches i0 <> i151 : Found 0 matches i0 <> i169 : Found 0 matches i0 <> i171 : Found 0 matches i0 <> i188 : Found 0 matches i0 <> i172 : Found 0 matches i0 <> i189 : Found 0 matches i0 <> i190 : Found 0 matches i0 <> i191 : Found 0 matches i0 <> i208 : Found 0 matches i0 <> i192 : Found 0 matches i0 <> i209 : Found 0 matches i0 <> i210 : Found 0 matches i0 <> i211 : Found 0 matches i0 <> i212 : Found 0 matches i0 <> i213 : Found 0 matches i0 <> i228 : Found 0 matches i0 <> i229 : Found 0 matches i0 <> i230 : Found 0 matches i0 <> i231 : Found 0 matches i0 <> i271 : Found 0 matches i0 <> i328 : Found 0 matches i0 <> i272 : Found 0 matches i0 <> i329 : Found 0 matches i0 <> i330 : Found 0 matches i0 <> i368 : Found 0 matches i0 <> i370 : Found 0 matches i0 <> i369 : Found 0 matches i0 <> i371 : Found 0 matches i8 <> i9 : Found 0 matches i0 <> i379 : Found 0 matches i8 <> i10 : Found 0 matches i8 <> i11 : Found 0 matches So it checked 63 pairs that are COMPLETELY BOGUS. It needed to check 0-19 (about 45% overlap) and 0-18 (about 22% overlap). It didn't check the correct pairs, and it checked 31 times more unnecessary pairs. And it checked more than 60 times more pairs than I would have wanted it to do. (I think the layout should become sufficiently "stiff" with the diagonal matches left out). Next it doesn't check 1-18 nor 1-17 and 1-19. Similarly it skips some 20 more overlapping images and continues with 8-9. This match has already been tried. Then it tries 8-10. These two overlap for almost 25%. 0 matches is probably correct, because both images are mostly sky. 8-11. Good choice. Alas only sky this time. Then it continues.... i8 <> i12 : Found 0 matches i8 <> i28 : Found 0 matches i8 <> i29 : Found 0 matches i8 <> i30 : Found 0 matches i8 <> i31 : Found 5 matches i8 <> i32 : Found 0 matches i8 <> i33 : Found 0 matches i8 <> i46 : Found 0 matches i8 <> i48 : Found 0 matches i8 <> i47 : Found 0 matches i8 <> i49 : Found 0 matches i8 <> i50 : Found 0 matches and finds matches that are bogus. If I can reliably tell it NOT to search for matches in images that do not overlap these accidents would not happen. So far, in trying to stitch my pano, hugin only makes things worse. There is apparently some play in my mechanics. The odd columns (going up) are offset a bit from the even ones (going down). That is easily visible. However in general the layout is WAY better than was I get after letting cpfind and hugin have their way. -- 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
