Hi If OpenSurf is legitimately GPL there cannot be a patent problem with SURF. So why not use it? It is the fastest interest point algorithm I know of, and almost if not just as good as SIFT. Both do their job excellently and I can't see much likelihood of Pablo -- or anyone else -- inventing something different that works equally well. Anything is possible, of course, but....
Assume for the moment that Pablo discovers something better than SIFT and SURF for identifying potentially matchable image points. Does that mean the problem of control point finding is solved? If you said 'yes', or even 'maybe', go stitch some panoramas and come back in a year. The fact is that all our CP finders -- even the ones that use SIFT and SURF -- work poorly (and far too slow). They all proceed about as follows: 1] For each image, find many unique-looking interest points (IPs) -- the SIFT/SURF part. 2] For each (feasible) pair of images, find pairs of similar looking interest points, store those as candidate CPs 3] For various subsets of images, weed out candidate CPs whose IP coordinates are incompatible with a consistent physical alignment of the images, and/or have undesirable properties like being in sky or too close to better CPs. 4] Output the surviving CPs. The real action is in step 3], which has nothing to do with how the IPs were found, though of course it will be more successful given better IPs. That is where we really need new strategies and better algorithms. Or, to really think big, perhaps it would pay to abandon this blind one-way sifting procedure in favor of a more intelligent, goal-seeking algorithm. The goal is to align the images. The evidence includes whatever the photographer knows about the correct alignment (normally quite a lot) together with the contents of the images themselves. The route to the goal would be to form and test hypotheses about which parts of which images match under what transformations (meaning projection onto the sphere followed by rotations of the sphere). The tests would involve looking for matching IPs in candidate regions. Yes, that makes CP finding an integral part of the image alignment procedure, including optimization. Which is where it belongs. Although more complex, I believe this way of doing it could be both faster and more robust than the way we do it now. Best, Tom On Feb 10, 4:30 am, Jeffrey Martin <360cit...@gmail.com> wrote: > I'll echo Harry's sentiment: I'm very interested in this! Thanks Pablo > for your continuing efforts :-) > > Jeffrey > > On Feb 9, 10:52 am, Harry van der Wolf <hvdw...@gmail.com> wrote: > > > Hi all, > > > I'd like to start this specific thread again, just because I'm so interested > > in this patent-free control point detector. Actually my questions here are > > for Pablo, but as I think it interests a lot of people I throw it in the > > open. > > > @Pablo: I really don't want to push you, I'm just very interested in it. > > Please consider this as a "gentle" reminder. Not being a C++ programmer I > > depend on those who are. To control my own enthusiasm it would be nice if > > you could give us some clues on how this will proceed and when. > > To be more specific: > > - The mail mentions that a "a small part of the SURF algorithm to estimate > > the orientation of the interest point" is still used. You mention that you > > hope to replace this in the future. Can you give a rough estimate or could > > this be a GSOC 2010 project? > > - Build process: The build process is not very clean yet. I did some > > patching with regard to vigra-impex lib [3]. I don't know whether this works > > correctly on all linuxes, but it did for me on Ubuntu and OSX (off course). > > It's also possible to build against Hugins own internal vigraimpex. I could > > not deduct differences between the external (latest) vigraimpex and the > > internal hugin version. (Again a GSOC2010 project?) > > - OpenSURF: I suppose you have seen the documentation around Opensurf long > > time ago, but in case you didn't (and for others) I provide some links to > > code [0] and notes [1]. It is GPL3 and I can't find patented parts. You > > mention that the panomatic code is clean and modular. Would it be "easy" and > > useful to implement this code as a "module" in panomatic-lib as well? (Again > > possibly a GSOC 2010 project including the previous mentioned topics/steps). > > > [0]:http://code.google.com/p/opensurf1/ > > [1]: opensurf1.googlecode.com/files/OpenSURF.pdf > > [3]:http://groups.google.com/group/hugin-ptx/attach/9d6d35572627940d/find... > > > Hoi, > > Harry > > > 2010/1/3 Pablo d'Angelo <pablo.dang...@web.de> > > > > Hi all, > > > > I have taken some time in the last few days and continued my work on on > > > a patent free control point detection algorithm, which I haven't had > > > time to continue since I started it in March 2009. > > > > I have taken panomatic as base, as it is a relatively clean code base > > > (compared to the others), and implemented a new descriptor based on the > > > geometric blur and DAISY papers. This is a relatively simplistic (and > > > very cheap to compute) descriptor, and its probably not as powerful as > > > the original SURF descriptor. I'm still using a small part of the SURF > > > algorithm to estimate the orientation of the interest point, so it is > > > not 100% patent free yet, but I hope to replace that part in the future. > > > > I have further modularized the panomatic source code and added a new > > > program called keypoints, which can be use to compute the descriptors > > > only (similar to generatekeys from autopano-sift). The main panomatic > > > executable now also supports loading of these files instead of > > > recomputing them based on the images. This is mainly useful for testing > > > and some more advanced control point finding strategies. > > > > The code lives in a bzr repository on launchpad: > > >https://code.launchpad.net/~pablo.dangelo/hugin/panomatic-lib<https://code.launchpad.net/%7Epablo.dangelo/hugin/panomatic-lib> > > > > See the README file on how to build and use it. It is not tested on many > > > panos yet, and might or might not work. > > > > I'm interested in feedback to see how well it works with typical panos. > > > > Note that it can't properly handle fisheye images (like the original > > > panomatic). It might be possible to use it with match-n-shift, but I > > > haven't tried that yet. > > > > ciao > > > Pablo -- 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
