Hi all, I've been lurking for a while, and this is my first post. I frequently do large panoramas with 50 to 150 or more images - see www.manassasconsulting.com for sample images most of which were completed with hugin.
The idea of CP pair matching with prior knowledge of the image order and overlap would be of tremendous value to me. There is of course more than one way to skin a cat. There are at least two ways I can think or about approaching the problem or reducing pair matching search and processing time. In addition to loading the photos in a sort of viewable checkerboard grid where the number of rows and columns are specified such as seen in the gigapan.org stitcher (I can post a screen dump if needed) we can also generate prior knowledge by using sub projects where we choose what photos are loaded in each sub project. So, there is the possibility of running multiple sub projects and merging them. For example, the idea of loading each column of photos as a subproject, processing sub projects and then merging would also reduce processing time. As I understand it there are command line tools for merging multiple projects so this might be an option to pursue as well. I haven't done much progamming since I was working basic in binary with dip switches on a Digital PDP8 except for a bit of java and ajax here and there. However I would be happy and willing to engage in assisting others who want to work on this issue by helping to define needs, features, testing, etc... I am comfortable with terminal and command line language. Battle On Nov 27, 2:09 pm, Tom Sharpless <tksharpl...@gmail.com> wrote: > Hi Nicolas > > On Nov 20, 10:18 pm, Nicolas Pelletier <nicolas.pellet...@gmail.com> > wrote: > > > > > > > Hi, > > > Many questions about panomatic (btw, still targetting to setup and help on > > windows, but this itched a little more) > > > First, is there a reason that the panomatic project on SF has files but no > > source? > > > Second, if I don't want to get into trouble with patent... where is the > > limit? > > - Publishing the source? > > - Contributing a new version? > > - Uploading\encouraging people to use it? > > > I'm asking because I was limited on the 32 bit version because of the memory > > limit (only 1 or 2 thread running) so I recompiled a 64 bit version. I'm all > > for sharing, but don't want any trouble. > > > As I'm testing the result, I'm hitting one problem. My benchmarks are > > running, but here is the preliminary: > > DL version (binary for windows) runs a test in 350 seconds > > Compiled 32 version (in release, fully optimized) runs the same test in 895 > > seconds. > > > This is baffling me. Anybody has any clue? Does the source actually match > > what was used to build it? (I may have done a dumb mistake, worked on this > > instead of sleeping... but I typically know what I'm doing with code...) > > These results are king of killing the purpose of building a faster > > version... If the original is still 2-3 times faster, tough to beat! > > > Also, this is more technical, but here we go. > > Panomatic seems to have 2 phases in the same way that Sift does; 1st find > > control points. 2nd, match points between images and purge everything else. > > In Panomatic, the 2nd phase is awfully long, taking over 90% of the > > processing time. It seems that one major difference between sift and surf in > > their classic impementation is that in sift, it is done single thread and in > > one global run, while for surf, it is done per pair of images, multi thread. > > The pair thing is killing me since I typically shoot 51 images per pano. > > > Now, the question for the experts. Is that second phase the > > same\similar\completely different between autopanoSIFT-c and Panomatic? > > Could the second one be improved with the way the first one was coded? > > I last looked at Panomatic about a year ago, so my opinion may be > stale or faulty, but I seem to recall that the interest point matching > phase tried every pair of images as a separate operation. That would > lead to a big slowdown as the number of images increases, because the > number of pairs grows as the square of the number of images. Autopano- > sift-c, on the other hand, matches each image once against a pool of > all interest points. So the slowdown factor is much smaller, but the > memory requirement is much bigger. > > Neither approach is optimal. The right way to handle big image sets > would be to use prior knowledge of how they are layed out -- the > photographer almost always knows that -- to limit pairwise matching > just to the pairs that have some chance of overlapping. > > It would not be hard to change Panomatic to do pooled matching. That > would make it faster than autopano-sift-c, since it finds interest > points considerably faster. I almost did that back when I was working > on APSCpp, but was not sure about Anael's feelings about foreign > branches, so I didn't. > > Also, being a perfectionist, I really wanted to wait until we were in > a position to do layout-based matching, that is, until Hugin (or any > other front end, for that matter) was able to routinely capture > nominal image positions and pass those to the CP finder. I am not > sure if that day has arrived yet, but if it has, it would be good if > someone would add layout-based matching to Panomatic and APSCpp both. > > Regards, Tom > > > > > > > nick -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
