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.
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.
On Sun 03-Jan-2010 at 00:52 +0100, Pablo d'Angelo wrote:
>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.
Great, need to get bazaar installed.
>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.
I removed the internal stereographic stuff from match-n-shift in 0.24 as autopano-sift-c now does it natively, is much faster and gave equivalent results. Though this should be easy enough to put back into another wrapper if necessary.
Many thanks for this achievement. Even though the current autopano-sift-c and panomatic doe their job very nicely, it is really getting a pain in the backside to have to deal with this patent/license circumstances.
I've tried to build it but it breaks on [ 23%] Building CXX object keypoints/CMakeFiles/ keypoints.dir/keypoints.cpp.o /Users/Shared/development/hugin_related/panomatic-lib/keypoints/keypoints.c pp:35:27: error: vigra/impex.hxx: No such file or directory /Users/Shared/development/hugin_related/panomatic-lib/keypoints/keypoints.c pp:36:30: error: vigra/stdimage.hxx: No such file or directory /Users/Shared/development/hugin_related/panomatic-lib/keypoints/keypoints.c pp:37:39: error: vigra/stdimagefunctions.hxx: No such file or directory
When installing vigra it works OK, but vigra is not part of this bazaar branch.
Did you intend this to be or become part of hugin. If so, do I need to or can I put this panomatic-lib somewhere in the hugin tree?
Next to this I get a lot of errors about: -- Performing Test boost_python_/usr/lib_/usr/include/python2.5_boost_python-gcc-mt_compile -- Performing Test boost_python_/usr/lib_/usr/include/python2.5_boost_python-gcc-mt_compile - Failed -- Performing Test boost_python_/usr/lib_/usr/include/python2.5_boost_python-mt_compile -- Performing Test boost_python_/usr/lib_/usr/include/python2.5_boost_python-mt_compile - Failed (and many more lines) It creates the build files though and everything is compiled fine as well (after installing vigra). Is this python_boost "thing" a requirement? And what does it do?
Finally when starting panomatic it displays the normal help screen but ends in: ThreadQueue waiting on remaining threads... Reference thread created. 1 reference-thread added. pollUserThreads() pollReferenceThreads() Thread destroyed. 1 reference-thread reclaimed. ThreadQueue destroyed
Is this normal or is it something from OSX or boost-python or..??
> On Sun 03-Jan-2010 at 00:52 +0100, Pablo d'Angelo wrote:
> >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.
> Great, need to get bazaar installed.
> >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.
> I removed the internal stereographic stuff from match-n-shift in > 0.24 as autopano-sift-c now does it natively, is much faster and > gave equivalent results. Though this should be easy enough to put > back into another wrapper if necessary.
> -- > Bruno
> -- > 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+unsubscribe@googlegroups.com<hugin-ptx%2Bunsubscribe@googlegroups .com> > For more options, visit this group at > http://groups.google.com/group/hugin-ptx
On 3 Jan., 13:08, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Hi Pablo,
> Many thanks for this achievement. Even though the current autopano-sift-c > and panomatic doe their job very nicely, it is really getting a pain in the > backside to have to deal with this patent/license circumstances.
> I've tried to build it but it breaks on > [ 23%] Building CXX object keypoints/CMakeFiles/ > keypoints.dir/keypoints.cpp.o > /Users/Shared/development/hugin_related/panomatic-lib/keypoints/keypoints.c pp:35:27: > error: vigra/impex.hxx: No such file or directory > When installing vigra it works OK, but vigra is not part of this bazaar > branch.
Yes, it requires an external vigra lib.
> Did you intend this to be or become part of hugin. If so, do I need to or > can I put this panomatic-lib somewhere in the hugin tree?
Currently it is not part of hugin. I'm still undecided if I should keep it as a separate program, or embed it directly into hugin. For the moment it is really a first test and not meant for shipping as a default control point generator.
> Next to this I get a lot of errors about: > -- Performing Test > boost_python_/usr/lib_/usr/include/python2.5_boost_python-gcc-mt_compile > -- Performing Test > boost_python_/usr/lib_/usr/include/python2.5_boost_python-gcc-mt_compile - > Failed > -- Performing Test > boost_python_/usr/lib_/usr/include/python2.5_boost_python-mt_compile > -- Performing Test > boost_python_/usr/lib_/usr/include/python2.5_boost_python-mt_compile - > Failed > (and many more lines) > It creates the build files though and everything is compiled fine as well > (after installing vigra). Is this python_boost "thing" a requirement? And > what does it do?
It is not required, but can be used (in the future...) to call the core detection routines from python. This is useful for further parameter tweaking scripts. Currently this is an untested features.
> Finally when starting panomatic it displays the normal help screen but ends > in: > ThreadQueue waiting on remaining threads... > Reference thread created. > 1 reference-thread added. > pollUserThreads() > pollReferenceThreads() > Thread destroyed. > 1 reference-thread reclaimed. > ThreadQueue destroyed
> Is this normal or is it something from OSX or boost-python or..??
I also get that message, it could be that I enabled a debug flag in March 2009, but forgot about it. Its not serious.
> Can anyone give me a command-line that I can use with bazaar-1.4.2 > to download this code? ..or create a tarball snapshot?
> -- > Bruno
> -- > 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+unsubscribe@googlegroups.com<hugin-ptx%2Bunsubscribe@googlegroups .com> > For more options, visit this group at > http://groups.google.com/group/hugin-ptx
Bruno Postle <br...@postle.net> wrote: > On Sun 03-Jan-2010 at 00:52 +0100, Pablo d'Angelo wrote: >>The code lives in a bzr repository on launchpad: >>https://code.launchpad.net/~pablo.dangelo/hugin/panomatic-lib > Can anyone give me a command-line that I can use with bazaar-1.4.2 > to download this code? ..or create a tarball snapshot?
The command listed on the webpage
bzr branch lp:~pablo.dangelo/hugin/panomatic-lib
works for me with bazaar 1.5.1. (Debian package bzr)
Bazaar 1.4.2 is the ancient (non-python) implementation (last release 2005). Aren't you able to upgrade?
>works for me with bazaar 1.5.1. (Debian package bzr)
>Bazaar 1.4.2 is the ancient (non-python) implementation (last release >2005). Aren't you able to upgrade?
centos4 here, there is a 'baz' command but no 'bzr', I'll have to build a new one. Though I seem to remember panomatic needs a newer boost than 1.32, so I'm going to struggle a bit.
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).
> 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.
> 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.
> 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).
> > 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.
> > 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.
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).
> > 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.
> > > 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.
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).
> > > 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.
> > > > 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+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/hugin-ptx
> - 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?
Actually, I have already implemented another orientation estimation algorithm, which seems to work quite well.
> - 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?)
For our purposes, there shouldn't be any differences between the official vigraimpex and the hugin internal vigraimpex, so using either one is fine. As it builds fine under linux now, I'd be happy to accept patches that make it easier to build, especially on windows.
> - 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.
I didn't know about that, but from what I see when reading their "Notes on the OpenSURF library", it is only a slight modification of the patented SURF algorithm, if any at all, and it would probably qualify as an reimplementation of SURF. A closer look at the source code is required.
> If OpenSurf is legitimately GPL there cannot be a patent problem with > SURF. So why not use it?
From what I have seem, it pretty much uses the algorithm as it is described in the SURF patent, so I doubt that it is a safe alternative in that sense.
> 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....
The primary goal is not to create a superior algorithm to SIFT or SURF, but to have something that allows us to stitch panoramas without having worrying too much about patents.
The matching software that we currently have, with the extensions done by Bruno and Thomas lately should pretty much allow matching of most types of panoramas for the most common usecases. Of course there will aways be panoramas which can't be matched automatically.
The problem with using prior information is that it needs to be specified to the computer program. Some expert users might want to do this, but the 95% of our users probably won't want to do any of that, they just want to press one button and have a nice panorama (and most of them don't actually care if it has one or two smaller errors left, people also by cheap and crappy cameras...).
A better integration of the RANSAC step with the alignment model we use might be a good improvement, too.
Btw. what happened to the matching software you were developing?
> - 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?
> Actually, I have already implemented another orientation estimation > algorithm, which seems to work quite well.
Shame on me: I didn't check the repository lately. I will start testing asap.
Does this means that "we" now have a fully patent-free CP detector and one that works with Thomas' multi-step CPdetector setup as well? The latter due to the fact that we can use the keypoints binary (also patent-free I assume?) for these more complicated setups?
If so, it means that "we" can now release Hugin on all platforms with a CP detector without having to be affraid of any patent/license issues.
I'm not totally happy with the name panomatic is that is already an existing name for an existing CP matcher/detector. Can't we call the panomatic binary something like "cp_matcher" or "hugin_matcher" or "hugin_cp_matcher" or anything else logical, not interfering and confusing with an existing program. "keypoints" and "liblocalfeatures.<lib extension>" is fine off course.
>> - 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?
>> Actually, I have already implemented another orientation estimation >> algorithm, which seems to work quite well.
> Shame on me: I didn't check the repository lately. I will start testing > asap.
> Does this means that "we" now have a fully patent-free CP detector and one > that works with Thomas' multi-step CPdetector setup as well? The latter due > to the fact that we can use the keypoints binary (also patent-free I > assume?) for these more complicated setups?
> If so, it means that "we" can now release Hugin on all platforms with a CP > detector without having to be affraid of any patent/license issues.
On Thu 11-Feb-2010 at 09:18 +0100, Harry van der Wolf wrote:
>I'm not totally happy with the name panomatic is that is already an existing >name for an existing CP matcher/detector. Can't we call the panomatic binary >something like "cp_matcher" or "hugin_matcher" or "hugin_cp_matcher" or >anything else logical, not interfering and confusing with an existing >program.
'panomatic' is ok so long as it replaces the existing panomatic, and the panomatic webpage indicates this.
..but I think that ultimately this needs to be merged into Hugin and built as a Hugin tool, for two reasons:
1. The best interface we have for specifying parameters is a .pto project, this works very well for autopano-sift-c and the various wrappers in Panotools::Script. So the control point generator may as well use the Hugin model and parser for this.
2. Feature classification really needs to be done with re-projected data, again the Hugin libraries are best placed to do this (the approach that the old match-n-shift wrapper took to create temporary stereographic files with PTmender had lots of problems).
> I'm not totally happy with the name panomatic is that is already an > existing name for an existing CP matcher/detector. Can't we call the > panomatic binary something like "cp_matcher" or "hugin_matcher" or > "hugin_cp_matcher" or anything else logical, not interfering and > confusing with an existing program. > "keypoints" and "liblocalfeatures.<lib extension>" is fine off course.
Bruno Postle wrote: > On Thu 11-Feb-2010 at 09:18 +0100, Harry van der Wolf wrote:
>> I'm not totally happy with the name panomatic is that is already an >> existing >> name for an existing CP matcher/detector. Can't we call the panomatic >> binary >> something like "cp_matcher" or "hugin_matcher" or "hugin_cp_matcher" or >> anything else logical, not interfering and confusing with an existing >> program.
> 'panomatic' is ok so long as it replaces the existing panomatic, and the > panomatic webpage indicates this.
Currently, it should be a drop in replacement. A new name would be nice.
There is no way to build my extended package without the SURF descriptor, so its not yet suitable for general redistribution, some more small modification to the build scripts are necessary.
> ...but I think that ultimately this needs to be merged into Hugin and > built as a Hugin tool, for two reasons:
Indeed, this is why I made the detector and descriptor as a separate library, which could be easily linked to any program.
> Currently, it should be a drop in replacement. A new name would be nice.
> There is no way to build my extended package without the SURF > descriptor, so its not yet suitable for general redistribution, some > more small modification to the build scripts are necessary.
I just changed the build configuration, so that by default, the SURF descriptor is not compiled. See the README if you want to build with support for SURF.
I've just been successful in building on Win XP with VS 2005, and started playing with panomatic_nopatent :). With the default settings from the readme, on a 2 row, 360 panorama, I'm finding a number of false matches. I'd like to provide helpful input, or other help, however I can.
I'm particularly interested in the case of pictures taken on a panoramic head, so they are known to be spaced on a phi/elevation grid.
What kinds of cases is this algorithm suited for? What would give it problems? My problem panorama has varying white balance and exposure, for example. I think you mentioned some research papers about the algorithm - can you point me to them?
Thanks, Aron
On Feb 12, 9:24 am, Pablo d'Angelo <pablo.dang...@web.de> wrote:
> > Currently, it should be a drop in replacement. A new name would be nice.
> > There is no way to build my extended package without the SURF > > descriptor, so its not yet suitable for general redistribution, some > > more small modification to the build scripts are necessary.
> I just changed the build configuration, so that by default, the SURF > descriptor is not compiled. See the README if you want to build with > support for SURF.
Pablo, there are two changes below which you might be able to incorporate, to FindVIGRA.cmake and making localfeatures a static library. On Feb 24, 3:16 pm, Aron H <aron.hel...@gmail.com> wrote:
> I've just been successful in building on Win XP with VS 2005, and > started playing with panomatic_nopatent :).
Since I'd love to start getting other windows users started using this new feature detector, I thought I could share my steps. I'm using VisualStudio 2005 on Win XP. I also have cygwin installed. -First, I grabbed the 'bzr' package for cygwin, so I could run the bzr command: bzr branch lp:~pablo.dangelo/hugin/panomatic-lib Changes: Pablo, there seems to be a typo in the CMakeModules/ FindVIGRA.cmake, line 21 FIND_LIBRARY( VIGRALIBRARIES needs to change to FIND_LIBRARY( VIGRA_LIBRARIES
-Get Vigra 1.6, pre-compiled for VS 2005, which simplifies things In the lib/ directory, copy vigraimpex.dll.lib to vigraimpex.lib
-Get boost, I used 1.39.0 -Get gui version of cmake, run it: source: C:/..../panomatic-lib build binaries: C:/..../panomatic-lib/build_release -click Configure, choose Visual Studio 8 2005 It will ask you to find several libraries. TIFF, JPEG, PNG, ZLIB can all be found in the Vigra directory, pre-built, so for instance: ZLIB_INCLUDE_DIR C:\downloads\Vigra 1.6\include\external ZLIB_LIBRARY C:\downloads\Vigra 1.6\lib
Once you've gotten rid of the error/red/objections, you can click Generate to get VS a project file inside the build_release/ folder. open panomatic.sln. Inside Visual Studio, right click localfeatures, click Properties. Under Configuration Properties, General, change the Configuration Type to Static Library (.lib)
Then everything should compile and link, even though there are many warnings about MS secure libraries. Please post any changes or updates you find!
> On Feb 12, 9:24 am, Pablo d'Angelo <pablo.dang...@web.de> wrote:
> > Pablo d'Angelo wrote:
> > > Currently, it should be a drop in replacement. A new name would be nice.
> > > There is no way to build my extended package without the SURF > > > descriptor, so its not yet suitable for general redistribution, some > > > more small modification to the build scripts are necessary.
> > I just changed the build configuration, so that by default, the SURF > > descriptor is not compiled. See the README if you want to build with > > support for SURF.
On Thu, Feb 25, 2010 at 11:24 AM, Aron H <aron.hel...@gmail.com> wrote: > Changes: > Pablo, there seems to be a typo in the CMakeModules/ > FindVIGRA.cmake, line 21 > FIND_LIBRARY( VIGRALIBRARIES > needs to change to > FIND_LIBRARY( VIGRA_LIBRARIES
> I've just been successful in building on Win XP with VS 2005, and > started playing with panomatic_nopatent :). With the default settings > from the readme, on a 2 row, 360 panorama, I'm finding a number of > false matches. I'd like to provide helpful input, or other help, > however I can.
It currently is more sensitive to distortions than the other descriptors. I hope to improve this (and add a better ransac model for outlier checking). Unfortunately, I have been rather busy with some other stuff lately.
> What kinds of cases is this algorithm suited for? What would give it > problems? My problem panorama has varying white balance and exposure, > for example. I think you mentioned some research papers about the > algorithm - can you point me to them?
Hmm, the algorithm is not really based on a published approach, just on some ideas that are mentioned in a few of them, and its currently simpler than any of them:
The descriptor is basically just x and y gradient strength computed in a daisy like layout, where the radius of the circles define the scale of the gradient filter.
The code is relatively simple: localfeatures/CircularKeyPointDescriptor.cpp
I did some quick evaluation and parameter tuning using two panoramas, to learn the best radi and scales, but probably some kind of aggregation of the gradients is needed to really improve the performance.
I have also fixed the typo you mentioned in a later mail, and liblocalfeatures will be build as a static library on windows now.
