Tests for Pablo's (almost) patent free CP detector (was: Towards a non-patented control point detector)
Harry van der Wolf
After Pablo's announcement[0] (3 January) of the almost patent free CP detector I built it on OSX, but due to other priorities I had set myself, I did not have the time to do tests (sorry Pablo [1]).
This is only a mail to share some first test results. I need to do more tests, so don't expect graphical and statistical test results.
== This mail is also to "invite" other users to test as well ==
(but I have to admit that I did not create a portable plugin binary yet to be delivered with Hugin for OSX).
(My) General conclusion: Based on this prelimiary results and even as it is now (but that was Pablo's own comment in his mail[0]), I think it does a good job and I think it is suitable for use with Hugin but in combination with celeste and cpclean. It needs some further tweaking.
Note: I only have partial panorama's based on a lineair lens. I compared 6 linear lense partial panos.
I have only one 360x180 fish-eye pano set. Yuval "released" a "hugin_6aroundtilted_testcase" somewhere end of 2007/early 2008. This is my only but always fisheye 360x180 testcase for hugin builds, including now with the new CPdetector.
For now I only tested with Pablo's suggested parameters: --grad --sieve1size 100 --sieve2size 3 -o %o %i
Results/Remarks:
- The new CPdetector detects/generates a huge amount of Control Points.
Pano's having approx. 30-40 CPs now have approx. 150-180 CPs. Pano's with approx. 60-70 CP's now have 220-230 CP's. Yuv's pano now generates 354 CP's (forgot to note the original number for this mail). After running Celeste and cpclean generally 25-50% of CP's are removed, which still means that you have a lot of CP's but the optimizer can easily deal with that.
- The spread of CP's over the overlapping areas is OK, but this might also be due to the huge amount of CPs. Now is this good, having a good spread of CP's, or is this bad, having so many CPs?
- Both celeste and cpclean should always be run on the result IMO. Most of the time I run cpclean 2-3 times (but I also do that when using the original panomatic and/or autopano-sift-c).
- Speed seems to be comparable with the original panomatic, but I didn't do stopwatch measurements as I don't care about optimal speed right now. It is definitely perfectly acceptable :-)
So far, so good.
I'm very interested in test results from others.
Apart from the fact that panomatic and autopano-sift-c do a good job, the license restrictions are by now a real pain. The sooner we have a patent-free CPdetector the better.
bruno.postle
>
> After Pablo's announcement[0] (3 January) of the almost patent free CP
> detector I built it on OSX, but due to other priorities I had set myself, I
> did not have the time to do tests (sorry Pablo [1]).
Just adding that it builds on fedora F12 with no problems, but I
haven't had a chance to run it yet.
--
Bruno
allard
I'll give it a go.
Allard
Nathan Gutman
Nathan
skip
> [0]:http://groups.google.com/group/hugin-ptx/browse_thread/thread/d9c0558...
> [1]:http://www.mail-archive.com/hugi...@googlegroups.com/msg07614.html
Can someone post the right instructions for downloading the branch? I
installed bazaar using MacPorts, and the command:
baz branch lp:~pablo.dangelo/hugin/panomatic-lib
results in an error: branch: could not determine source revision from
directory: /Users/sgaede/development
Thanks,
--skip
allard
successful. Let me describe the steps.
-Downloading and installing bazaar from their webpage and getting the
trunk trough their GUI went smooth.
-I ran CMake (i use 2.8.0 RC5 GUI), which went smoothly except that I
had to point it to some libraries directories, but I'm used to that
from the hugin builds (boost, wxtiff, jpeg, png and zlib).
-I opened the 'panomatic.sln' MSVC++ solution (I'm on the 2008 express
edition) and pressed 'build'. Many 'file not found' errors came up,
which were related to the fact that the boost directory and the vigra
directory were not added to the 'additional include directories'. I
was a bit surprised about the boost directory as this was certainly in
the cmake cache file.
-I added the directories through the 'properties/C++' tab of MSVC and
rebuilt. This time there were errors in
CircularKeyPointDescriptor.cpp , related to M_PI not being defined.
Fortunately, some googling told me this is a known problem and that
this can be solved by adding '#define _USE_MATH_DEFINES' and '#include
<math.h>' at the top of the file
-I rebuilt. This time two more errors came up that I couldn't solve.
These were:
error C4716: 'PanoDetector::LoadKeypoints' : must return a value' in
panodetectorlogic.cp, line 110
and
LINK : fatal error LNK1181: cannot open input file '..\localfeatures
\Release\localfeatures.lib'
Could that last one have something to do with the fact that on
windows, the output of 'localfeatures' is a .dll, not a .lib? Just
guessing.
Anyway, thank you Pablo for the effort, I'd really like to see this
work.
allard
On Jan 13, 3:02 pm, skip <sga...@comcast.net> wrote:
> On Jan 13, 6:55 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
>
>
>
> > All,
>
> > After Pablo's announcement[0] (3 January) of the almost patent free CP
> > detector I built it on OSX, but due to other priorities I had set myself, I
> > did not have the time to do tests (sorry Pablo [1]).
>
> > This is only a mail to share some first test results. I need to do more
Harry van der Wolf
Can someone post the right instructions for downloading the branch? I
installed bazaar using MacPorts, and the command:
baz branch lp:~pablo.dangelo/hugin/panomatic-lib
results in an error: branch: could not determine source revision from
directory: /Users/sgaede/development
Pablo d'Angelo
> I did a first attempt to build on Wndows XP and that was not
> successful. Let me describe the steps.
>
> -Downloading and installing bazaar from their webpage and getting the
> trunk trough their GUI went smooth.
>
> -I ran CMake (i use 2.8.0 RC5 GUI), which went smoothly except that I
> had to point it to some libraries directories, but I'm used to that
> from the hugin builds (boost, wxtiff, jpeg, png and zlib).
>
> -I opened the 'panomatic.sln' MSVC++ solution (I'm on the 2008 express
> edition) and pressed 'build'. Many 'file not found' errors came up,
> which were related to the fact that the boost directory and the vigra
> directory were not added to the 'additional include directories'. I
> was a bit surprised about the boost directory as this was certainly in
> the cmake cache file.
Oh, if forgot to add a check for the vigra stuff. The boost include path
should be picked up now.
> -I added the directories through the 'properties/C++' tab of MSVC and
> rebuilt. This time there were errors in
> CircularKeyPointDescriptor.cpp , related to M_PI not being defined.
> Fortunately, some googling told me this is a known problem and that
> this can be solved by adding '#define _USE_MATH_DEFINES' and '#include
> <math.h>' at the top of the file
Fixed in bzr
> -I rebuilt. This time two more errors came up that I couldn't solve.
> These were:
> error C4716: 'PanoDetector::LoadKeypoints' : must return a value' in
> panodetectorlogic.cp, line 110
This was an error in the source, I just commited a fix.
> and
> LINK : fatal error LNK1181: cannot open input file '..\localfeatures
> \Release\localfeatures.lib'
Maybe these are related? Could you update and try again.
ciao
Pablo
skip
Well, not knowing the difference, I installed bazaar, and the command
was baz. Just looked in the devel tree and found bzr, bzr-gtk, and two
more. I guess I know what to do next. Thanks for the clarification :)
>
> Harry
Pablo d'Angelo
> Results/Remarks:
> - The new CPdetector detects/generates a huge amount of Control Points.
> Pano's having approx. 30-40 CPs now have approx. 150-180 CPs. Pano's
> with approx. 60-70 CP's now have 220-230 CP's. Yuv's pano now generates
> 354 CP's (forgot to note the original number for this mail). After
> running Celeste and cpclean generally 25-50% of CP's are removed, which
> still means that you have a lot of CP's but the optimizer can easily
> deal with that.
> - The spread of CP's over the overlapping areas is OK, but this might
> also be due to the huge amount of CPs. Now is this good, having a good
> spread of CP's, or is this bad, having so many CPs?
Its bad if they are very badly distributed, and if you need to find bad
points by hand.
If you set --sieve2size 1 (or dont set it at all), then you should get
roughly the same number of control points as the original panomatic. Due
to the weaker descriptor, I feared that we would get more missmatches,
and cpclean should work better if more points are found.
Originally, I planned to use a set of diverse test panoramas for testing
and further parameter and algorithm tuning, but I haven't had the time
to screen my panos for good candidates.
For this test, I need some very well fitting panos (no parallax errors,
very well calibrated lens, no scene movement) for different focal
lengths and sceneries.
ciao
Pablo
skip
> [0]:http://groups.google.com/group/hugin-ptx/browse_thread/thread/d9c0558...
> [1]:http://www.mail-archive.com/hugi...@googlegroups.com/msg07614.html
I need more help. I installed vigra and bzr, but I don't know cmake.
How do I tell cmake that the vigraimpex library is in /opt/local/lib ?
Thanks,
--skip
Harry van der Wolf
cmake supports builds outside the "root" of the source tree (I forgot the name for it).
- cd inside the panomatic-lib source directory (not src)
- make a build directory like "mkdir build"
- cd build;
- issue the following commands to set CFLAGS and so on correctly:
export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
export CFLAGS="-I/opt/local/include -L/opt/local/lib"
export CXXFLAGS=$CFLAGS
- still inside the build directory issue the command "cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo .." or simply "cmake .."
- make
- (sudo) make install does not work yet, so simply copy from the build directory the panomatic executable to the appropriate place for the bundle (remind that you might have the original panomatic there, so you might copy that out of the way or rename the new panomatic or so)
issue the command from build: "cp panomatic/panomatic ~/Library/Application\ Support/Hugin/Autopano/patfreepanomatic" (I renamed it for the time being).
Inside your Hugin bundle in preferences for CPDetectors select patfreepanomatic (if you renamed it) and set the parameters to: "--grad --sieve1size 100 --sieve2size 1 -o %o %i" or "--grad --sieve1size 100 --sieve2size 3 -o %o %i".
Note: do not delete your build directory yet. Inside "build/localfeatures/" resides "liblocalfeatures.dylib" which is needed by the new panomatic. I did not spend time yet to modify settings like install_name_path.
Harry
Tduell
On Jan 15, 6:24 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
[snip]
> - cd inside the panomatic-lib source directory (not src)
> - make a build directory like "mkdir build"
> - cd build;
> - issue the following commands to set CFLAGS and so on correctly:
> export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
> export CFLAGS="-I/opt/local/include -L/opt/local/lib"
> export CXXFLAGS=$CFLAGS
[snip]
Thanks for that advice, I used a suitably edited version to build on
Fedora 12.
I have done a couple of tests and it seems to do a good job thus far.
Cheers,
Terry
allard
A few steps further already, the changes Pablo made worked out, except
that the "ifdef MSVC" around the USE_MATH_DEFINES was not picked up
somehow, I had to comment it.
I also had to download pthread and use NODEFAULTLIB on msvcprt.lib,
LIBCMT.lib and libcmpt.lib to avoid conflicts with vigraimpex and each
other.
But now I get a load of unresolved external symbol errors. I think the
last two things have something to do with the vigraimpex.lib. I tried
the downloaded release and the one from my hugin builds but neither
would work.
Any suggestions?
Harry van der Wolf
I can't get it to work yet.
A few steps further already, the changes Pablo made worked out, except
that the "ifdef MSVC" around the USE_MATH_DEFINES was not picked up
somehow, I had to comment it.
I also had to download pthread and use NODEFAULTLIB on msvcprt.lib,
LIBCMT.lib and libcmpt.lib to avoid conflicts with vigraimpex and each
other.
But now I get a load of unresolved external symbol errors. I think the
last two things have something to do with the vigraimpex.lib. I tried
the downloaded release and the one from my hugin builds but neither
would work.
I created a patch that searches for vigra. It means that you no longer need to use CFLAGS/CXXFLAGS.
I patched the CMakeLists.txt and added a FindVIGRA.cmake module in CMakeModules.
It works for OSX and should work on all linuxes (but untested). As I know absolutely nothing of windows it is only an "educated guess" for that platform.
I hope Pablo improves the win32 stuff of the FindVIGRA.cmake module.
Inside panomatic-lib do "patch -p0 < findvigra.diff"
Harry
Harry van der Wolf
allard
I'm at a loss here. Does this require other files from vigra than a
build of hugin? The cmake patch does not find the vigra package. I've
tried downloading vigra 1.6 and building the library (changing it to a
static lib, no clue if that works the way I did it), but CMake won't
tell me it has found vigra. I tried overriding the package finder and
putting the paths in manually but that doesn't work either, at least I
get tons of error messages, which seem to be related to vigra if I use
the (renamed) huginvigraimpex.lib from my hugin build or unrelated to
vigra if I use the renamed vigraimpex_dll.lib that I built from the
downloaded source.
As usual I'm just touching around in the dark, could somebody give me
a hint?
Allard
On Jan 15, 5:31 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Hi guys,
>
> I'm sorry. I went much too fast. I made the Find module as a lunch
> "practice" and that part works, but I completely forgot to modify the
> CMakeLists.txt files to use the results from my module.
> Please find attached the "version 2" patch.
>
> Harry
>
> 2010/1/15 Harry van der Wolf <hvdw...@gmail.com>
>
> > Hi all,
>
> > 2010/1/15 allard <a...@allardkatan.net>
>
> > I can't get it to work yet.
> >> A few steps further already, the changes Pablo made worked out, except
> >> that the "ifdef MSVC" around the USE_MATH_DEFINES was not picked up
> >> somehow, I had to comment it.
> >> I also had to download pthread and use NODEFAULTLIB on msvcprt.lib,
> >> LIBCMT.lib and libcmpt.lib to avoid conflicts with vigraimpex and each
> >> other.
> >> But now I get a load of unresolved external symbol errors. I think the
> >> last two things have something to do with the vigraimpex.lib. I tried
> >> the downloaded release and the one from my hugin builds but neither
> >> would work.
>
> > I created a patch that searches for vigra. It means that you no longer need
> > to use CFLAGS/CXXFLAGS.
>
> > I patched the CMakeLists.txt and added a FindVIGRA.cmake module in
> > CMakeModules.
> > It works for OSX and should work on all linuxes (but untested). As I know
> > absolutely nothing of windows it is only an "educated guess" for that
> > platform.
> > I hope Pablo improves the win32 stuff of the FindVIGRA.cmake module.
>
> > Inside panomatic-lib do "patch -p0 < findvigra.diff"
>
> > Harry
>
>
>
> findvigra_v2.diff
> 4KViewDownload
Harry van der Wolf
As mentioned: I don't know how Windows handles this. My advise here is only on "best guess".
To be able to compile Pablo's source you need an external vigra. The vigra inside hugin does not work.
You need both the includes and the dll or static vigra library
Now for the Win32 part inside my FindVigra cmake macro (see also below): I checked some other macros for windows stuff and copied from them.
IF(WIN32)
FIND_PATH(VIGRA_INCLUDE_DIR vigra/gaborfilter.hxx
PATHS ${VIGRA_ROOT_PATH}/include ${SOURCE_BASE_DIR}/vigra/include
)
# for dynamic build, it's vigraimpex.lib and the dll must be copied into hugin's bin folder
#SET(VIGRA_LIBRARIES ${SOURCE_BASE_DIR}/vigra/lib/libvigraindex.dll)
FIND_LIBRARY( VIGRALIBRARIES
NAMES vigraimpex libvigraimpex
PATHS
${VIGRA_ROOT_PATH}
${VIGRA_ROOT_PATH}/Release
${VIGRA_ROOT_PATH}/lib
)
ELSE(WIN32)
There is a FIND part and a SET part. The Find part really tries to find the path to the includes and to the libraries. You can expand this with the paths where your really have the includes and library (check inside hugin/CMkeModules for examples).
The NAMES specifies how the library could be named (without extension, platform independable). If it is called differently on windows please change accordingly.
The SET command (disabled here) is not searching but forcing where the library resides. It is up to you if it really is there.
You can do the same for the include_dir.
Last but not least, you can override it and specify it on the command line:
"cmake -DVIGRA_INCLUDE_DIR=<drive\plus\path\to\include\dir> -DVIGRA_LIBRARIES=<drive\plus\path\to\library> .."
Thereby overriding where cmake has to search.
I included that in patch version 3 (see attached in the top).
IF (VIGRA_INCLUDE_DIR AND VIGRA_LIBRARIES)
# in cache already
SET(VIGRA_FOUND TRUE)
ELSE (VIGRA_INCLUDE_DIR AND VIGRA_LIBRARIES)
I hope this helps, but for windows I'm also guessing.
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
T. Modes
> build of hugin? The cmake patch does not find the vigra package. I've
> tried downloading vigra 1.6 and building the library (changing it to a
> static lib, no clue if that works the way I did it), but CMake won't
> tell me it has found vigra. I tried overriding the package finder and
> putting the paths in manually but that doesn't work either, at least I
> get tons of error messages, which seem to be related to vigra if I use
> the (renamed) huginvigraimpex.lib from my hugin build or unrelated to
> vigra if I use the renamed vigraimpex_dll.lib that I built from the
I have sucessfull build panomatic-lib with hugins vigraimpex on
windows. But there was more manual tweaking of the project files
necessary. With an external vigra 1.6 I had not yet sucess. It
compiled, but then it did not run correctly (it was not able to read
the files.)
So there is some more work with the cmake system to do until it works
out of the box.
Thomas
Harry van der Wolf
I have sucessfull build panomatic-lib with hugins vigraimpex on
windows.
Thomas
-
@Thomas:
Thank you for mentioning this.
Pablo said that we needed an external vigra library but I just tested and it does compile against hugins internal library and it also works correctly.
@Allard:
After having built hugin from cmake or MSVC or whatever, you should somewhere have a library called huginvigraimpex.dll (or so).
If you do a "cmake -DVIGRA_INCLUDE_DIR=<path\to\hugin\src\foreign\vigra> -D-DVIGRA_LIBRARIES=<path\to\where\built\libaries\are\huginvigraimpex.dll> .."
and if that doesn't work, does the following work:
"cmake -DVIGRA_INCLUDE_DIR=<path\to\hugin\src\foreign\vigra\vigra_impex> -D-DVIGRA_LIBRARIES=<path\to\where\built\libaries\are\huginvigraimpex.dll> .."
Does that work?
Harry
allard
manually entering the external libs/source and the hugin libs/source.
First I have to hack your Cmake file because it still gives a 'package
not found' error even if I manually enter the lib path (I use cmake
gui 2.8rc5). But neither lib leads to a successful build. Although
after having built the external lib myself the error messages I got
did not seem to have 'vigra' in them. Perhaps it's something else.
@ Thomas: would you mind sharing the tweaks you did?
Thanks, Allard
On Jan 21, 10:16 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Hi all,
>
> 2010/1/21 T. Modes <Thomas.Mo...@gmx.de>
allard
unresolved external symbol "__declspec(dllimport) class
std::auto_ptr<struct vigra::Decoder> __cdecl vigra::decoder(class
vigra::ImageImportInfo const &)" (__imp_?decoder@vigra@@YA?AV?
$auto_ptr@UDecoder@vigra@@@std@@ABVImageImportInfo@1@@Z) referenced in
function "void __cdecl vigra::importScalarImage<class
vigra::BasicImageIterator<double,double * *>,class
vigra::StandardValueAccessor<double> >(class vigra::ImageImportInfo
const &,class vigra::BasicImageIterator<double,double * *>,class
vigra::StandardValueAccessor<double>)" (??$importScalarImage@V?
$BasicImageIterator@NPAPAN@vigra@@V?
$StandardValueAccessor@N@2@@vigra@@YAXABVImageImportInfo@0@V?
$BasicImageIterator@NPAPAN@0@V?$StandardValueAccessor@N@0@@Z)
in keypoints.obj
Whatever I try (I've built two versions of the vigra lib, used the
downloaded lib, the downloaded dll and the one I built for hugin), I
keep getting about 8 errors similar to this. Thomas' tips, that I got
offline (thanks!) didn't solve it. Any clues?
Allard
