A matching program that might work just as well is one that deals with "edges or lines" and "common areas or colors". For example gimp has a program that will find edges, and give you a "line" drawing. Matching unique lines seems that it would be an easier process. If I was lining up two images by hand, in gimp, I don't look at points, I look at edges, and colors & area. Yes, being able to assign number order to images would be nice as well.
> Date: Wed, 10 Feb 2010 07:35:00 -0800 > Subject: [hugin-ptx] Re: Towards a non-patented control point detector > From: tksharpl...@gmail.com > To: hugin-ptx@googlegroups.com > > 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 _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/ -- 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
