Towards a non-patented control point detector
Pablo d'Angelo
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
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
Bruno Postle
>
>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
Harry van der Wolf
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.cpp:35:27: error: vigra/impex.hxx: No such file or directory
/Users/Shared/development/hugin_related/panomatic-lib/keypoints/keypoints.cpp:36:30: error: vigra/stdimage.hxx: No such file or directory
/Users/Shared/development/hugin_related/panomatic-lib/keypoints/keypoints.cpp: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..??
Hoi,
Harry
--
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 hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
Pablo d'Angelo
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.cpp: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.
ciao
Pablo
Bruno Postle
>
>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?
--
Bruno
Harry van der Wolf
use:
bzr branch lp:~pablo.dangelo/hugin/panomatic-lib
That will download the code into panomatic-lib
Harry
Andreas Metzler
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?
cu andreas
Bruno Postle
>
>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?
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.
--
Bruno
Harry van der Wolf
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/findvigra_v3.diff?part=4
Hoi,
Harry
Jeffrey Martin
for your continuing efforts :-)
Jeffrey
> [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>
Tom Sharpless
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
Dale Beams
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: tksha...@gmail.com
> To: hugi...@googlegroups.com
> 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 hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx
Hotmail: Powerful Free email with security by Microsoft. Get it now.
Pablo d'Angelo
Harry van der Wolf wrote:
> - 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.
ciao
Pablo
Pablo d'Angelo
> Hi
>
> 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?
ciao
Pablo
Harry van der Wolf
Thanks a lot! Has anyone ever mentioned that you are important to this Open source project? :-)
Hi Harry,Actually, I have already implemented another orientation estimation algorithm, which seems to work quite well.
Harry van der Wolf wrote:
- 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?
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.
Hoi,
Harry
Harry van der Wolf
One more request. ;-)
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.
Harry
Bruno Postle
>
>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).
--
Bruno
AKS-Gmail-IMAP
exactly what it refers to.
Yuv
> Seriously, the most obvious name is "Pablosmatic". Everyone will know
> exactly what it refers to.
for a short while [0] I thought so too, but I respect Pablo's wish
for it to have another name.
if anybody has good ideas for names, post them here!
Yuv
[0] http://wiki.panotools.org/wiki/index.php?title=Hugin_Compiling_Ubuntu&diff=12146&oldid=12145
Pablo d'Angelo
> 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.
ciao
Pablo
Pablo d'Angelo
>
> 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.
ciao
Pablo
Aron H
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
Aron H
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!
Allan Seidel
Pablo d'Angelo
Aron H schrieb:
> 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:
http://www.eecs.berkeley.edu/~aberg/gb.html
http://cvlab.epfl.ch/~tola/daisy.html
http://cvlab.epfl.ch/~brown/learndesc/learndesc.html
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.
ciao
Pablo
Yili Zhao
does this non-patented control point detector/descriptor
has a formal name? Thus we can add a wiki page at
wiki.panotools.org.
--
Yili Zhao
Aron H
used in the Mac snapshot build. But looking at Pablo's references,
perhaps 'daisy_geoblur' might be better. What do you think, Pablo?
Aron
Bruno Postle
> perhaps 'daisy_geoblur' might be better. What do you think, Pablo?
'daisy' is good, I like 'daisychain', 'daisypicker' or 'upsydaisy'
(hmm, I've been watching too much children's television).
--
Bruno
Daniel Reetz
You know, it might be useful to call it something more informative
than illustrative. Daisy is good, but I'd never search for Daisy if I
was searching for a non-patented control point detector.
If this were my project, I would seriously call it "Patent Free
Feature Detector". And in this perfect world, everyone would use it
because it would be so plain and obvious and clear... and Google-able.
Or "Panotools Patent Free Feature Detector"
Daniel Reetz
Bruno Postle
>>
>> 'daisy' is good, I like 'daisychain', 'daisypicker' or 'upsydaisy'
>You know, it might be useful to call it something more informative
>than illustrative. Daisy is good, but I'd never search for Daisy if I
>was searching for a non-patented control point detector.
It is likely that every installation of Hugin will automatically
have this tool either as a dependency or because it is bundled with
Hugin itself. So the name just needs to be typeable and not the
same as any other software.
--
Bruno
Zoran Zorkic
I vote for "Patent Free Feature Detector" or short: PaFF-D!
Bart van Andel
On 3 mrt, 00:03, Daniel Reetz <danre...@gmail.com> wrote:
> On Tue, Mar 2, 2010 at 6:04 AM, Bruno Postle <brunopos...@googlemail.com> wrote:
> > On 1 March 2010 18:36, Aron H <aron.hel...@gmail.com> wrote:
>
> >> perhaps 'daisy_geoblur' might be better. What do you think, Pablo?
>
> > 'daisy' is good, I like 'daisychain', 'daisypicker' or 'upsydaisy'
> > (hmm, I've been watching too much children's television).
>
> You know, it might be useful to call it something more informative
> than illustrative. Daisy is good, but I'd never search for Daisy if I
> was searching for a non-patented control point detector.
However you'd search for Hugin if you were to find a panorama creation
tool... I don't think this is a strong argument. Why not use a nice
name like Daisy and add a short description, (like Hugin has:
"panorama photo stitcher")? You'd still be able to find it that way.
And to end users such a name is more friendly too. Well, that's my
opinion.
And what about when another patent free feature detector is build?
You'd end up with confusion if you only use a descriptive name, or
you'd have to resort to full descriptive names like scientific papers
often do (ugly!). Remember qtpfsgui? I definitely wouldn't vote for
that one.
> If this were my project, I would seriously call it "Patent Free
> Feature Detector". And in this perfect world, everyone would use it
> because it would be so plain and obvious and clear... and Google-able.
That is, if you know your panorama-creation program should "detect
features" in the source images. It's only obvious once you know what
you should be looking for.
--
Bart
Daniel Reetz
> tool...
No, I wouldn't, I like the friendly sound of "Hugin" but I don't think
it tells you anything else about the project. I think that's
unfortunate.
> That is, if you know your panorama-creation program should "detect
> features" in the source images. It's only obvious once you know what
> you should be looking for.
I had in mind the Panotools philosophy (lots of small tools, bodged
together with a nice GUI, but useful on their own). Fact remains that
if you are part of the larger software/image processing community,
especially as a developer, you can employ these tools on their own.
You might well search for "patent-free feature detector" and "daisy"
will not help in connecting you to it.
But anyway, I'm not deeply invested in this any way it goes. My
project went with SURF, even though it has patent problems. I just
wanted to present an alternate view to "pablo$whatever" and the more
whimsical "daisy*" stuff. And furthermore, since I'm not developing
it, well, I know how much this opinion is worth.
:)
DR
Rogier Wolff
> > If this were my project, I would seriously call it "Patent Free
> > Feature Detector". And in this perfect world, everyone would use it
> > because it would be so plain and obvious and clear... and Google-able.
>
> That is, if you know your panorama-creation program should "detect
> features" in the source images. It's only obvious once you know what
> you should be looking for.
Daisy, the patent free feature detector.
I like it. It also lends itself for a good logo. Two squares, left
square with a tree and a flower in the lower right. right square with
a flower in the top left, and a person. Some features in the flower
marked as corresponding. (e.g. marked A, B, C in both flowers, or
with links shown between them.)
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
Seb Perez-D
<rew-goog...@bitwizard.nl> wrote:
>
> Daisy, the patent free feature detector.
>
We might want to find something a little less common. Although these
softwares are not doing the same thing, it might be better to have
something more unique:
http://en.wikipedia.org/wiki/Daisy_%28software%29
http://en.wikipedia.org/wiki/DAISY_Digital_Talking_Book
http://www.daisydental.com/software/index.shtml
http://www.daisy.com/
http://www.leedberg.com/glsoft/daisy/
http://www.prodigi.com.au/products/daisy.html
to name but a few...
Cheers,
Seb
Bart van Andel
Muninn [1], which stand for thought and memory respectively, are the
ravens who tell Odin how the earth is doing). I think it may be a nice
idea to steal another name there.
So... what about Loki? According to its Wikipedia article [2], "Loki
assists the gods, and sometimes causes problems for them. Loki is a
shape shifter and in separate incidents he appears in the form of a
salmon and a mare.". Certainly a feature detector assists our precious
Hugin, and certainly this sometimes will cause problems (bad matches
etc.). I don't know about the internal working but it might do some
shape shifting too. Anyway afterwards the images (shapes) will be
shifted based on the feature points found.
Besides that, Loki sounds a bit like "localize", which is what it
does, it localizes points which will be used to connect the images.
Of course we could also add a cheesy backronym [3] like "Locally
Oriented Keypoint Indexer" (depending on what it actually does under
the hood this might or might not be correct), or "Localizer of
Orientation independent Keypoints of Interest". Anyone with a cheese-o-
matic can think of even nicer backronyms, if you tune the machine
correctly. ;-)
[0] http://en.wikipedia.org/wiki/Norse_mythology
[1] http://en.wikipedia.org/wiki/Huginn_and_Muninn
[2] http://en.wikipedia.org/wiki/Loki
[3] http://en.wikipedia.org/wiki/Backronym
--
Bart
Harry van der Wolf
I agree with Seb. There are even more "occurrences" like daisy chain(ing) in the traditional, electrical, IT, sexual, networking, etc. meanings.
Why not keep it simple descriptive (in the panotools) tradition and couple it at the same time unmistakably to Hugin and name it "hugin_cp_tool" (with or without the underscores or hyphens (minus signs) or upper/lower characters in the name).
The "tool" appendix describes what it's two purposes: namely descripting and matching.
The keypoints binary can keep it's name AFAIK or anyone wanting to be creative on that one too?
hugin_cp_tool or huginCPtool is not nice, it's not poetic (like something daisy like), but I think it describes unmistakably what it does.
So far my 2 cents.
Harry