Announce: Feature detection using conformal images
Bruno Postle
I was going to create a web-page to describe this new tool, but it
will have to wait for the time being.
The problem is that the existing tools for automatically generating
control points within hugin are great, but have trouble with parts
of photos that are very distorted - More specifically they have
trouble matching features between photos where the distortion is
very different.
This basically describes the situation with wide-angle or fisheye
images, where features at the edges of the photos are stretched
asymmetrically. Consequently the various autopano-* tools available
within hugin only give good results with narrow field of view images
such as those from compact cameras.
A solution to this problem, as we discussed last year, is to compare
photos after remapping them into a 'conformal' projection:
http://en.wikipedia.org/wiki/Conformal_map_projection#Conformal
Features in a conformal projection (stereographic and mercator are
conformal) have essentially no distortion at the small-scale, but
lots of distortion at larger scales - This is what we need since
control points are small-scale features by definition.
So here is a tool that runs the usual autopano-sift-C tools on
temporary stereographic versions of photos, the results are then
processed to apply to the original 'normal' photos:
https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/Panotools-Script/bin/match-n-shift
It's a perl script and requires some extra CPAN perl modules
(Image::Size, Math::Matrix and Panotools::Script), it also requires
the ImageMagick 'convert' tool and autopano-sift-C - Despite all
this it doesn't really run any slower than the current
autopano-c-complete script used in hugin.
Another consequence of using conformal images is that the
autopano-sift --refine option works very well, eliminating a lot of
bad control points.
hugin doesn't yet have support for passing the necessary lens
parameters, so a typical command-line usage with fisheye images
would be something like this:
match-n-shift --projection 2 --fov 111 \
--clean --refine --points 50 --output output.oto *.jpg
..you can then open the output.oto file as a hugin project.
(change --projection 2 to 0 if you have 'normal' rectilinear photos,
and set --fov to an approximation to the horizontal field of view of
you camera/lens combination)
As a hugin Autopano-SIFT preference setting this ought to work too:
match-n-shift
-p 2 -v 111 -c -r -p %p -o %o %i
I've good results with this tool, in combination with autooptimiser
I've been able to completely stitch hand-held fisheye-lens 360°
panoramas on the command-line without much problem.
--
Bruno
Bob Bright
In my early tests (I've only used it on one pano so far), it's *MUCH* better at finding useful control points than running autopano-sift directly on the fisheye images. Thank you, thank you, thank you!!
On Sun, 2008-02-10 at 01:04 +0000, Bruno Postle wrote:
hugin doesn't yet have support for passing the necessary lens
parameters, so a typical command-line usage with fisheye images
would be something like this:
match-n-shift --projection 2 --fov 111 \
--clean --refine --points 50 --output output.oto *.jpg
As a hugin Autopano-SIFT preference setting this ought to work too:
match-n-shift
-p 2 -v 111 -c -r -p %p -o %o %i
Thanks again!
BBB
Seb Perez-D
> The problem is that the existing tools for automatically generating
> control points within hugin are great, but have trouble with parts
> of photos that are very distorted - More specifically they have
> trouble matching features between photos where the distortion is
> very different.
Bruno, you have done it again - this is awesome.
Many thanks !
Seb
ArAgost
> [...]
> temporary stereographic versions of photos, the results are then
> processed to apply to the original 'normal' photos:
>
You rule as always, Bruno! :)
Just a question: could this somehow be included in the current apsc
project of integrating all the control points finding/filtering/
refining in one step? Perl scripts are not so handy for Windows
users...
And is that FOV vertical, horizontal, or diagonal?
Bruno Postle
>It works like a charm, Bruno, both from the command line and from within
>hugin. (Ubuntu 7.10 i686, hugin 2801)
Great, I haven't tried it with hugin myself yet.
>Do you see much benefit with "--refine"? I tried it with and without,
>and the resulting control points didn't seem significantly better with
>the refine step, but it takes a *lot* longer to process (esp. with 50
>points per overlap!).
The --refine step doesn't make the points any better as I'm feeding
it the same downsized images that I'm feeding to the keypoint
generator (normally --refine works on the full sized input).
What it does do is to discard wrong control points, which makes it
very useful for a completely automatic workflow - It is slow,
especially with lots of points, so I wouldn't recommend it in every
case.
>> As a hugin Autopano-SIFT preference setting this ought to work too:
>>
>> match-n-shift
>> -p 2 -v 111 -c -r -p %p -o %o %i
>
>I think that first "-p" should be "-f".
Yes, my mistake.
>(P.S. According to the match-n-shift usage, -f is 0 for rectilinear
>input, 2 for circular fisheye, and 3 for full frame fisheye.
>What's 1 for? Just curious.)
These numbers are the same as for panotools script files: 1 is for
cylindrical and 4 is for equirectangular. match-n-shift currently
doesn't do anything interesting with these other input formats,
though it shouldn't be completely broken (untested).
You could do the same conformal-image trick for these formats by
converting to Mercator instead of stereographic, but somebody needs
to actually identify a practical use for this first.
--
Bruno
Bruno Postle
>
>Just a question: could this somehow be included in the current apsc
>project of integrating all the control points finding/filtering/
>refining in one step? Perl scripts are not so handy for Windows
>users...
Yes it could, though I wouldn't be able to do this. The advantage
of keeping it separate is that it can be easily modified to work
with alternative feature matching tools - This is inevitable as SIFT
is patent encumbered in the US.
It should actually work fine on Windows, I'll compile it to an .exe
when I get a chance - It will require an ImageMagick installation or
it will be horribly slow.
>And is that FOV vertical, horizontal, or diagonal?
Field of view is horizontal, the same as for hugin/panotools.
--
Bruno
Yuval Levy
> I'll compile it to an .exe when I get a chance -
> It will require an ImageMagick installation or it will be horribly slow.
I'm on the learning curve for compiling perl, still. When I got it
sorted out, I will add this (and the necessary ImageMagick binary) to
the package. Will ImageMagick 8bit be enough (this is just for the temp
files, right)?
Yuv
Bruno Postle
>
>I'm on the learning curve for compiling perl, still. When I got it
>sorted out, I will add this (and the necessary ImageMagick binary) to
>the package. Will ImageMagick 8bit be enough (this is just for the temp
>files, right)?
Yes, 'generatekeys' downscales images internally, so I figured it
was pointless and slow to have nona supply it with full-size
stereographic images. So I have imagemagick 'convert' do the
downscaling first - Though it's not strictly necessary and could be
hacked out for a Windows version.
--
Bruno
ArAgost
> On Sun 10-Feb-2008 at 05:27 -0800, ArAgost wrote:
>
>
>
> >Just a question: could this somehow be included in the current apsc
> >project of integrating all the control points finding/filtering/
> >refining in one step? Perl scripts are not so handy for Windows
> >users...
>
> Yes it could, though I wouldn't be able to do this. The advantage
> of keeping it separate is that it can be easily modified to work
> with alternative feature matching tools - This is inevitable as SIFT
> is patent encumbered in the US.
I need a little help though (I'm using OS X): I installed all the perl
modules and imagemagick withouth hassle, but your new tool requires a
nona executable. How do i get it? Is the nona_mask I somehow got right?
Bruno Postle
>
>I need a little help though (I'm using OS X): I installed all the perl
>modules and imagemagick withouth hassle, but your new tool requires a
>nona executable. How do i get it? Is the nona_mask I somehow got right?
Nope, nona-mask is another script that you got with the
Panotools::Script perl module.
nona is the hugin command-line stitcher tool, you probably have to
extract it from the hugin OS X dmg and put it in your $PATH.
--
Bruno
Philipp B. Koch
> So here is a tool that runs the usual autopano-sift-C tools on
> temporary stereographic versions of photos, the results are then
> processed to apply to the original 'normal' photos:
>
> https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/Panotools-Script/bin/match-n-shift
>
good points between fisheye images...
> It's a perl script and requires some extra CPAN perl modules
> (Image::Size, Math::Matrix and Panotools::Script), it also requires
> the ImageMagick 'convert' tool and autopano-sift-C - Despite all
> this it doesn't really run any slower than the current
> autopano-c-complete script used in hugin.
>
> (...)
I am on Windows XP Prof and do know almost nothing about Pearl
installations (not to mention my lack of knowledge regarding the coding
itself, haha).
I've installed the Pearl distribution available at activepearl.com and
at least I got it to run on the command line (telling me about all these
missing modules).
Then I tried to find the right ones you have mentioned on CPAN.org, and
that's exactly where I got definitly stuck... I just don't know how to
"install" (?) /
build / whatever these modules to make them work. SOOO, to cut a long
story short -- it has been mentioned on the list that maybe there's
going to be
a compiled EXE of the script. Are there still plans to do so? I'd like
to test it very much :-)
Besides: What about Matchpoint (or how ever it will be called then) --
how come it's so much out of discussion? I thought it was more or less
finished
and did a much better job than Autopano, Autopano-SIFT and
Autopano-SIFT-c -- sorry if I'm asking a little stupid, but doesn't it
"only" have to be
integrated into Hugin (or maybe compiled or in any other way be made
executable for each OS)?
Regards, Philipp Koch
Yuval Levy
> it has been mentioned on the list that maybe there's going to be
> a compiled EXE of the script. Are there still plans to do so?
yes, but not tonight. i'm giving up. i got perl working, but the whole
compile to an executable still escapes me. i'm in the final stages for
the next Windows installer. it corrects a few bugs, but it does not add
any new feature, sorry.
> Besides: What about Matchpoint (or how ever it will be called then) --
> how come it's so much out of discussion?
Zoran is in the middle of exams. Prior the the exams he committed new
code to SVN, but nobody had time to look at it and it won't be part of
the upcoming release. It's not ready for production yet.
Yuv
Bruno Postle
>
>I've good results with this tool, in combination with autooptimiser
>I've been able to completely stitch hand-held fisheye-lens 360°
>panoramas on the command-line without much problem.
Here's a test, these are thirty-two spherical hand-held panoramas I
shot in a couple of hours last summer:
http://bugbear.blackfish.org.uk/~bruno/misc/2007-06-23-goodwood-panorama/
This is the result of a completely automatic script that I ran
overnight, it basically uses the various hugin command-line tools
and match-n-shift to mimic the usual hugin workflow.
The script isn't a masterpiece, but I included it at the end anyway.
Time taken: about 100 minutes including creating the QTVR and
'planet' views. Some of them didn't work, but most are ok.
--
Bruno
Philipp B. Koch
Philipp B. Koch wrote:it has been mentioned on the list that maybe there's going to be a compiled EXE of the script. Are there still plans to do so?yes, but not tonight. i'm giving up. i got perl working, but the whole compile to an executable still escapes me. i'm in the final stages for the next Windows installer. it corrects a few bugs, but it does not add any new feature, sorry.
it's better to give such things up :-)
Besides: What about Matchpoint (or how ever it will be called then) -- how come it's so much out of discussion?Zoran is in the middle of exams. Prior the the exams he committed new code to SVN, but nobody had time to look at it and it won't be part of the upcoming release. It's not ready for production yet.
all panoramic things.
I would like to help with this, but since I am not a coder, I guess all I can do is testing snapshots..
Regards, Ph.
ArAgost
>
> Nope, nona-mask is another script that you got with the
> Panotools::Script perl module.
> nona is the hugin command-line stitcher tool, you probably have to
> extract it from the hugin OS X dmg and put it in your $PATH.
the binary distribution are the wxwidgets resources.
Shall I compile the panotools? How do I check out the right version?
Yuval Levy
> "But not tonight" -- I also tend to go to bed late, but 7 o'clock in the
> morning really is a time where
> it's better to give such things up :-)
mhhh... it's 8:26 AM now here, I already had breakfast. probably the
time displayed was UTC? just to reassure you, it was shortly before 2 AM
when I hit the pillow last night.
> I would like to help with this, but since I am not a coder, I guess all
> I can do is testing snapshots..
that's already help. detailed reports, filled in the hugin bug tracker,
are very helpful.
Yuv
Harry van der Wolf
Op 12-feb-2008, om 13:39 heeft ArAgost het volgende geschreven:
>
> On 12 Feb, 01:16, Bruno Postle <br...@postle.net> wrote:
>>
>> Nope, nona-mask is another script that you got with the
>> Panotools::Script perl module.
>
> D'oh
>
>> nona is the hugin command-line stitcher tool, you probably have to
>> extract it from the hugin OS X dmg and put it in your $PATH.
>
> D'oh again, since inside the only reference to nona i could found in
> the binary distribution are the wxwidgets resources.
If you "dive" into the hugin.app, you'll find in Hugin.app/Contents/
Resources/HuginStitchProject.app/Contents/MacOS a dynamically
compiled nona (and the other tools).
Harry
Philipp B. Koch
Philipp B. Koch wrote:"But not tonight" -- I also tend to go to bed late, but 7 o'clock in the morning really is a time where it's better to give such things up :-)mhhh... it's 8:26 AM now here, I already had breakfast. probably the time displayed was UTC? just to reassure you, it was shortly before 2 AM when I hit the pillow last night.
I would like to help with this, but since I am not a coder, I guess all I can do is testing snapshots..that's already help. detailed reports, filled in the hugin bug tracker, are very helpful.
So that will also mean I can test and report in a useful way then...
Regards, Ph.
Yuval Levy
> Ah, OK :-) Hhm, aren't you in Switzerland (don't know how I come to
> believe this)? I am in Germany, so there shouldn't be any time difference..
currently living in Canada. most likely moving to the UK in November.
the world is my oyster and I am an hydroponic tomato. no roots. I
sometimes envy those who have roots, but then they sometimes envy me for
hovering free.
Liebe Gruesse
Yuv
P.S.: what are you studying?
Philipp B. Koch
Philipp B. Koch wrote:Ah, OK :-) Hhm, aren't you in Switzerland (don't know how I come to believe this)? I am in Germany, so there shouldn't be any time difference..currently living in Canada. most likely moving to the UK in November.
the world is my oyster and I am an hydroponic tomato. no roots. I sometimes envy those who have roots, but then they sometimes envy me for hovering free.
but since seven years I live in Berlin. I guess, sometimes roots can also be something one might stumble upon (like
the roots of a tree, cracking through the asphalt) if not being paid enough attention to...
Liebe Gruesse Yuv P.S.: what are you studying?
Ebenfalls liebe Grüße nach Kanada,
Philipp
Bruno Postle
>
>I've installed the Pearl distribution available at activepearl.com and
>at least I got it to run on the command line (telling me about all these
>missing modules).
>Then I tried to find the right ones you have mentioned on CPAN.org, and
>that's exactly where I got definitly stuck... I just don't know how to
>"install" (?) /
>build / whatever these modules to make them work. SOOO, to cut a long
>story short -- it has been mentioned on the list that maybe there's
>going to be
>a compiled EXE of the script. Are there still plans to do so? I'd like
>to test it very much :-)
I've trying to do this and have been failing for various reasons I
don't quite understand.
Alternatively, you should be able to get it working with a full
activestate installation using these instructions:
http://wiki.panotools.org/Install_Panotools-Script_on_Windows
--
Bruno
Philipp B. Koch
Thanks, I'll try this as soon as I have a chance to have a closer look
at it and report my finding (if any) :-)
Regards, Ph.
ArAgost
wrote:
> If you "dive" into the hugin.app, you'll find in Hugin.app/Contents/
> Resources/HuginStitchProject.app/Contents/MacOS a dynamically
> compiled nona (and the other tools).
>
minus the right place. Thank you so much, I'm going to test it soon
(well, just after I finish testing Aperture 2 :P)
Peter Gawthrop
first of all, thanks for your excellent collection of scripts.
I have a strange nona-related bug with your script match-n-shift. In particular:
match-n-shift --refine -f=3 -fov=90 --noransac -o test.pto ?.jpg
(where I have 8 full-frame fisheye images 0.jpg - 7.jpg.)
fails because nona generates corrupt sgraph_?.tif files.
A workaround (which I don't really understand) is to replace line 80
by:
system ('nona', '-p', 'UINT8', '-m', 'TIFF_multilayer', '-o',
$path_output_small, $path_pto_temp);
to change the output format to multilayer tiff -- this produces correct tiffs and the
script produces nice results on my first test.
nona was compiled from hugin 2539
Best wishes,
Peter.
From: Bruno Postle <br...@postle.net>
Subject: [hugin-ptx] Announce: Feature detection using conformal images
Date: Sun, 10 Feb 2008 01:04:47 +0000
Philipp B. Koch
something. But whatever
I give it as parameters on the command line, the only thing that happens
is that the help message is printed out,
without any error message. I guess I'm just doing wrong with parameters
(although I took those you pointed out in your initial message).
What did you mean by mentioning it could also work with Hugin and
Autopano-SIFT as preference?
So is it possible to run it from inside Hugin once all the Pearl stuff
is installed?
Regards, Ph.
Tom Sharpless
Let me add my voice to the general chorus of praise. You have done a
great service here, first by realizing that a conformal projection is
needed for local shape matching, and second by showing us all how
well it works in practice.
It seems to me that to reach perfection, now all we need to do is to
apply these tools a bit more efficiently. Because the shape-finders
have such huge appetites for memory, we have typically applied them to
scaled-down images; but surely we could get better alignments by
working at full resolution. So we should really subdivide our images
rather than downscale them. As it is a complete waste of time to
find shapes in places where the images don't overlap, we should only
feed subimages likely to contain overlap regions to the shape finders.
What I have in mind is an iterative alignment procedure, that starts
from a rough alignment specified (or at least checked) by the
photographer and refines it in several steps. Each step maps the
overlaps more accurately, at higher resolution, and feeds the "good
parts" of them pairwise to a shape finder/control point matcher. The
usual optimizations of lens parameters as well as alignment angles
would be done at each stage.
The notion of "good parts" mainly means avoiding areas where things
seem to be moving (sky, crowds, rivers...) Identifying such regions
might be a good job for an improved control point matcher (which
should also incorporate a "crowding penalty" to overcome the tendency
to put too many points close together in areas where there are strong
features). A shape finder that handles masked images would also be
valuable.
As with any iterative optimization, the big dangers are false optima
(= globally wrong alignments) and excessive complexity (= never-really-
debugged sotware).
But I think it worth trying to develop something along these lines.
Best Regards, Tom
On Feb 12, 4:43 am, Bruno Postle <br...@postle.net> wrote:
> On Sun 10-Feb-2008 at 01:04 +0000, Bruno Postle wrote:
>
>
>
> >I've good results with this tool, in combination with autooptimiser
> >I've been able to completely stitch hand-held fisheye-lens 360°
> >panoramas on the command-line without much problem.
>
> Here's a test, these are thirty-two spherical hand-held panoramas I
> shot in a couple of hours last summer:
>
Bruno Postle
>
> I have a strange nona-related bug with your script match-n-shift. In particular:
>
>match-n-shift --refine -f=3 -fov=90 --noransac -o test.pto ?.jpg
> fails because nona generates corrupt sgraph_?.tif files.
> nona was compiled from hugin 2539
This sounds familiar, for a while nona was creating broken
TIFF, JPEG and PNG images. Yes it was fixed in svn2540:
http://sourceforge.net/tracker/index.php?func=detail&aid=1833833&group_id=77506&atid=550441
You should upgrade, there have been a lot of bugfixes in hugin since
November.
--
Bruno
Bruno Postle
>
>> http://wiki.panotools.org/Install_Panotools-Script_on_Windows
>I've gotten in to work without complaining about any missing modules or
>something. But whatever
>I give it as parameters on the command line, the only thing that happens
>is that the help message is printed out,
There was an error in one of the two command-lines in my original
email. As a test, try a minimal command-line:
perl match-n-shift -o output.oto image1.jpg image2.jpg
>What did you mean by mentioning it could also work with Hugin and
>Autopano-SIFT as preference?
It is intended to work as a complete replacement. To work properly
it needed some method for hugin to communicate field of view and
projection type, so if you have a hugin snapshot from yesterday then
you should be able to set the autopano-SIFT preference to something
like this and it will do the right thing:
match-n-shift
-f %f -v %v -c -p %p -o %o %i
(The %f and %v macros are new, so this won't work with an older
hugin. Pablo has pointed out that all these parameters would be
better communicated via a temporary project file, but this is
something for another day)
>So is it possible to run it from inside Hugin once all the Pearl stuff
>is installed?
On Windows? maybe if you follow the Panotools::Script instructions
on the wiki, as this installs all these scripts with accompanying
.BAT files in the system $PATH - Though you will need to use the SVN
version of Panotools::Script.
Sorry, the intention is to make this simpler, but it turns out that
creating an .exe version of this isn't as simple as it seemed.
--
Bruno
Bruno Postle
>
>What I have in mind is an iterative alignment procedure, that starts
>from a rough alignment specified (or at least checked) by the
>photographer and refines it in several steps. Each step maps the
>overlaps more accurately, at higher resolution, and feeds the "good
>parts" of them pairwise to a shape finder/control point matcher. The
>usual optimizations of lens parameters as well as alignment angles
>would be done at each stage.
Yes, I'd even start the process earlier than this: The lowest
resolution step shouldn't just prealign photos to identify areas
worth matching accurately, it should identify individual panoramas
given a directory full of photos.
Though I wouldn't like to see this work being done to
autopano-sift-c in a way that wasn't easily portable to matchpoint
or some other future patent-free tool.
--
Bruno
Tom Sharpless
On Feb 13, 6:05 pm, Bruno Postle <br...@postle.net> wrote:
> On Wed 13-Feb-2008 at 10:08 -0800, Tom Sharpless wrote:
>
>
>
> >What I have in mind is an iterative alignment procedure, that starts
> >from a rough alignment specified (or at least checked) by the
> >photographer and refines it in several steps. Each step maps the
> >overlaps more accurately, at higher resolution, and feeds the "good
> >parts" of them pairwise to a shape finder/control point matcher. The
> >usual optimizations of lens parameters as well as alignment angles
> >would be done at each stage.
>
> Yes, I'd even start the process earlier than this: The lowest
> resolution step shouldn't just prealign photos to identify areas
> worth matching accurately, it should identify individual panoramas
> given a directory full of photos.
tools -- I would appreciate being given a chance to tell the software
how I actually took each pano. Most of the time I have tried for a
definite arrangement of shots, and often have realized it pretty
accurately. It seems a shame to ignore this information. And since
I re-use specific arrangements often, it would be nice to be able to
invoke templates for them.
Mind you, I'm not talking about hand-correcting control points. I
dislike setting control points (even in programs that don't crash
while doing it ;->) and if a pano seems to need that I'm inclined to
abandon it. But rather often the failure is a gross misplacement of
one or two images, that can be corrected by dragging them in the
preview window (I'm talking about PTGui here, of course) and re-
optimizing. Using alignment templates would eliminate those annoying
cases.
>
> Though I wouldn't like to see this work being done to
> autopano-sift-c in a way that wasn't easily portable to matchpoint
> or some other future patent-free tool.
>
is unlikely to object to non-commercial applications of SIFT. They
might even be willing to grant an open source license, restricted to
private noncommercial use, that would make distributing it with hugin
100% legal. Have you tried to contact them about this?
-- Tom
Bruno Postle
> But rather often the failure is a gross misplacement of one or two
> images, that can be corrected by dragging them in the preview
> window (I'm talking about PTGui here, of course) and
> re-optimizing.
Being able to drag images around in the preview and generate
connections to let them snap into place would be a nice feature,
though this would be unnecessary if the software has aligned them
correctly in the first place.
>> Though I wouldn't like to see this work being done to
>> autopano-sift-c in a way that wasn't easily portable to matchpoint
>> or some other future patent-free tool.
>I don't think you should be so worried about this patent. The U of BC
>is unlikely to object to non-commercial applications of SIFT. They
>might even be willing to grant an open source license, restricted to
>private noncommercial use, that would make distributing it with hugin
>100% legal.
Yes the development of hugin has been 'non-commercial' so far - In
that nobody has made any money out of developing it, but this is not
a restriction that we can impose on users.
If you think about it, a tool that is only usable for fully
non-commercial purposes is essentially useless - Linux distributions
are quite clear about this and generally won't ship such software.
>Have you tried to contact them about this?
Apparently they are not interested in giving a full GPL exemption
which is what would be required.
--
Bruno
Bruno Postle
>
>>So is it possible to run it from inside Hugin once all the Pearl stuff
>>is installed?
>Sorry, the intention is to make this simpler, but it turns out that
>creating an .exe version of this isn't as simple as it seemed.
Ok, finally managed to get match-n-shift to build into a Windows
.exe file. I've done no testing other than to confirm that it
worked for me from within hugin:
http://bugbear.blackfish.org.uk/~bruno/misc/Panotools-Script/match-n-shift-win32.2008-02-15.zip
If it does work, then it will run faster with ImageMagick installed:
http://www.imagemagick.org/script/binary-releases.php#windows
..though I've added a --nomagick option so you don't actually need
it.
I also got the other various tools in Panotools::Script to build
into Windows .exe files (not much testing done with these):
http://bugbear.blackfish.org.uk/~bruno/misc/Panotools-Script/
Most of these tools require an ImageMagick installation in addition
to nona/enblend. They are documented here:
http://search.cpan.org/dist/Panotools-Script/
--
Bruno
Philipp B. Koch
> Ok, finally managed to get match-n-shift to build into a Windows
> .exe file. I've done no testing other than to confirm that it
> worked for me from within hugin:
>
> http://bugbear.blackfish.org.uk/~bruno/misc/Panotools-Script/match-n-shift-win32.2008-02-15.zip
>
> If it does work, then it will run faster with ImageMagick installed:
>
> http://www.imagemagick.org/script/binary-releases.php#windows
>
> ..though I've added a --nomagick option so you don't actually need
> it.
that's great news -- thanks again for the time and effort you spend for
all this!
I've tested Match-n-shift.exe within Hugin and it's amazing! For the
first time ever (!) all of my images were connected -- normally at least
the nadir and often also the zenith didn't get connected to the rest of
the pano using Autopano-SIFT. (So did Autopano-SIFT-c on the same
project, while Match-n-shift did it wonderful :-)
I get an error inside the text window after pressing the Align button:
"using E:\wintemp\uUUDa9skiO
Value "92,962292" invalid for option v (real number expected)"
Nothing happens until I press the "Cancel" button. The matching process
then starts immediately while an error window appears:
"Failed to kill process 3712 with sigterm, error 4: unspecified error"
I used out-of-cam JPGs with a 8mm Fisheye lens on my Olympus E-330. The
focal length is being read out of the exif data automatically, and as I
enter "2" as crop factor, the above value (causing the error message) is
calculated. After optimizing, the HFOV in the camera&lens tab is shown
as "96.5".
Regards, Ph.
Philipp B. Koch
> (...) I've tested Match-n-shift.exe within Hugin and it's amazing! (...)
Sorry, forgot to mention: I use the latest Hugin 0.7.0.2863 on Win XP
Pro SP2.
Bruno Postle
>
>I've tested Match-n-shift.exe within Hugin and it's amazing! For the
>first time ever (!) all of my images were connected
Great, good to hear that the windows binary works on a different
system.
>I get an error inside the text window after pressing the Align button:
>
>"using E:\wintemp\uUUDa9skiO
>Value "92,962292" invalid for option v (real number expected)"
It looks like hugin is using locale specific decimal point
separators (the script is complaining about the comma).
Though after doing some tests it seems that the perl response
happens to be the right behaviour in this case.
>Nothing happens until I press the "Cancel" button. The matching process
>then starts immediately while an error window appears:
I'm not sure what this is, sounds like another problem altogether.
Can you try entering exactly '92' into the field-of-view box and see
if there still an error?
--
Bruno
Philipp B. Koch
images into Hugin (so the focal length gets changed accordingly). No
error message then. But when trying with "90", again: error message:
"Value "90,000000" invalid for option v (real number expected)" --
obviously the comma ",000000" gets added automatically here and causes
the error, and for some reason it doesn't when being given 92.... Then,
a third test with the same panorama, left the calculated HFOV of "92.96"
and -- no error message!! So I am really unsure how to reproduce this
error...?!
About the "cancel" button necessity: This was nonsens; there is just a
biiiiig delay before the match process is started (maybe because of
remapping?). First time I tried with 36 images, so the delay was rather
long and I thought it was crashed and pressed "cancel". But with only 9
images, the delay is much shorter. With or without error message, no
"cancel" required! The error message when pressing the cancel button
(and still not canceling the match process) is already in the bug
tracker
(http://sourceforge.net/tracker/index.php?func=detail&aid=1893917&group_id=77506&atid=550441)
-- it has nothing to do with the "wrong value" error.
Sorry if this mail sounds confused. I hope it can be helpful nevertheless.
Regards, Ph.
Bruno Postle
>I've tested the same pano again, entering "92" as HFOV when loading the
>images into Hugin (so the focal length gets changed accordingly). No
>error message then. But when trying with "90", again: error message:
>"Value "90,000000" invalid for option v (real number expected)" --
Thanks, I'll add a workaround so it doesn't trigger the error
message.
>About the "cancel" button necessity: This was nonsens; there is just a
>biiiiig delay before the match process is started (maybe because of
>remapping?). First time I tried with 36 images, so the delay was rather
>long and I thought it was crashed and pressed "cancel". But with only 9
>images, the delay is much shorter.
Yes, it needs to be changed to report progress. Basically if you
use the --nomagick option then nona creates full size stereographic
versions of the photos - This takes some time and can look like it
has stopped.
--
Bruno
Pablo d'Angelo
Just a short mail about some stuff I have been working on, but which is not
yet finished.
Tom Sharpless schrieb:
> Hi Bruno
>
> Let me add my voice to the general chorus of praise. You have done a
> great service here, first by realizing that a conformal projection is
> needed for local shape matching, and second by showing us all how
> well it works in practice.
>
> It seems to me that to reach perfection, now all we need to do is to
> apply these tools a bit more efficiently. Because the shape-finders
> have such huge appetites for memory, we have typically applied them to
> scaled-down images; but surely we could get better alignments by
> working at full resolution. So we should really subdivide our images
> rather than downscale them. As it is a complete waste of time to
> find shapes in places where the images don't overlap, we should only
> feed subimages likely to contain overlap regions to the shape finders.
Hugin already has an algorithm to determine an "overlap" graph for a given
panorama (I'm not using it currently, though). Currently it doesn't store
the overlap areas, but it would be possible to do so. Basically it creates a
downscaled version of the panorama and check for the overlaps there, and
then generates a graph (with the boost graph library) with the connections.
Stuff like the approximate overlap regions could be stored in the edges of
that graph.
Doing a graph traversal and simply matching the pairs while walking over an
edge will be a good algorithm then. Choose whatever matching procedure you
like. Either a descriptor based one, or maybe a traditional, pyramid level
correlation based one would work well, if the template is halfway right.
align_image_stack already contains a simple version of that (without
pyramids). I haven't thought about optimizing the image placement at every
resolution step, due to computational reasons, but it might be a good idea.
This are the basic ingredients are already there, they just need to be
refined, improved and connected.
Also I have just committed some unfinished code for matching keypoints
(generated by an arbitrary keypoint generator) inside hugin. It has been
floating around my hard disk for several months now, and I decided to only
work on it once 0.7.0 is out. The plan is to have a keypoint matcher that
knows about the involved geometries during RANSAC etc. This could also be
combined easily with the "overlap" only matcher described above.
ciao
Pablo
Pablo d'Angelo
Bruno Postle wrote:
> On Wed 13-Feb-2008 at 21:51 +0000, Bruno Postle wrote:
>
> http://bugbear.blackfish.org.uk/~bruno/misc/Panotools-Script/match-n-shift-win32.2008-02-15.zip
>
> If it does work, then it will run faster with ImageMagick installed:
>
> http://www.imagemagick.org/script/binary-releases.php#windows
>
> ..though I've added a --nomagick option so you don't actually need
> it.
Remapping the images with PTmender would be faster than with nona, and one
can also select a antialiasing interpolator and downscale at the same time
(which will increase the computation time again ;-) This way imagemagick
wouldn't be needed.
ciao
Pablo
Bruno Postle
> Remapping the images with PTmender would be faster than with nona,
> and one can also select a antialiasing interpolator and downscale
> at the same time (which will increase the computation time again
> ;-) This way imagemagick wouldn't be needed.
Done, match-n-shift no longer depends on ImageMagick, it now uses
PTmender for all image processing.
I'll create a windows .exe maybe tomorrow.
--
Bruno
ArAgost
> > and one can also select a antialiasing interpolator and downscale
> > at the same time (which will increase the computation time again
> > ;-) This way imagemagick wouldn't be needed.
>
> Done, match-n-shift no longer depends on ImageMagick, it now uses
> PTmender for all image processing.
>
> I'll create a windows .exe maybe tomorrow.
>
systems? :P
ArAgost
> systems? :P
Yuval Levy
On Wed, 2008-02-20 at 04:19 -0800, ArAgost wrote:
> Is there a version available for those who don't use legacy operating
> systems? :P
non-legacy operating systems have Perl pre-installed, although some say
Perl is a legacy scripting language =8^D
so: just grab the perl file and you're all set:
Bruno Postle
Yes of course, the link is the same as it was at the beginning of
this thread:
https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/Panotools-Script/bin/match-n-shift
(it now requires Panotools::Script, PTmender and autopano-sift-C)
..and for users of legacy operating systems here is a .exe version
that has had hardly any testing:
http://bugbear.blackfish.org.uk/~bruno/misc/Panotools-Script/match-n-shift-win32.2008-02-19.zip
Instructions for integrating it with very recent hugin pre-releases
are in the zip file. You need to make sure you have PTmender.exe,
autopano.exe, generatekeys.exe, match-n-shift.exe and perl58.dll in
the Hugin\bin folder.
--
Bruno