Bruno & others, I've decided to make a low-res (because of data-size reasons) version of my project available.
At http://prive.bitwizard.nl/demo.zip you can find a 78Mb file that contains 380 pictures I took. (I took about double that amount, this is just the run until the battery ran out. I now know I need to start out with a full battery). There is a "doit" script that shows how I generated the test_pre.pto, test_pre2.pto and test.pto. Treasure that test.pto, as I've made it with my patched cpfind. I'm NOT asking you to do my work. What I want is to be able to stitch this type of project with reasonable amounts of human intervention time using hugin. I hereby invite you to run this project through hugin and see how you evaluate the experience. It is not about the resulting stitch. It is about the process of generating that stitch. This is just a test-shot that I took to test the hugin stitching process. If you find that this is possible with hugin at this time, please document the process for me. I'll try to expand your notes into the documentation wiki for others to use. Please note that with the current layout that is generated by my "blind estimation" script, the horizon is generally straight, but has a small step at the edge of each image. The results I get often have the horizon shaped into an S-shape. This is not realistic. -- 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
