Cpfind for Dummies
bloody tomatoes
Jeffrey Martin
Is anyone able to explain what they all mean?
so far I only (sort of) understand sieve1 and sieve2 width, height, size. all the other stuff is not clear to me at all....
Jeffrey
kfj
On 19 Jan., 14:18, Jeffrey Martin <360cit...@gmail.com> wrote:
> I am also quite confused by all the options in Cpfind.
>
> Is anyone able to explain what they all mean?
They aren't even specific to cpfind, but are common throughout the
genre. To understand their meaning, one has to familiarize oneself
with the underlying technology. Initially, there is the algorithm to
find candidates for the control points - the so-called feature points.
This part of the process is also the part where there are patent
issues. Keywords here are SIFT (as in autopano-sift) and SURF (used in
Panomatic), and apperently cpfind is now using another feature
detector which is unencumbered by patent issues. Once feature points
have been detected in all images, they have to be compared between
images to find matching pairs. The 'features' in a feature point are
very complex; often they consist of some 100 individual values.
Matching them is not easy. The kdtree is one algorithm used in the
process. In this process, quite a few fals positives are found. They
have to be eliminated, and one well-understood mathematical way of
doing so is the ransac algorithm.
All these mathematical methods are used to our advantage by the CPG
algorithms. They can be finetuned, but usually the default values
provide near-best performance. Only in extreme situations (fisheye
photos are extreme, mathematically) can it become necessary to modify
them; usually the CPGs will query the lens type and adapt
automatically, but especially in a CPG which is still in active
development, like cpfind, manual intervention for testers and
experimentors must be possible - that's where the cryptic, unintuitive
parameters come in.
My advice concerning these is: if you don't understand what they do,
best don't mess with them. It is highly unlikely that trial-and-error
is going to get you anywhere. If the CPG doesn't perform with your
data, there is more likely another problem:
- the treatment of the particular lens is not correct
- the mathematical method isn't suited to the type of image processed
- the image is flawed (parallax, distortion)
so, of the various options that go beyond the obvious, I think you can
make rougly two groups. The first may be useful to play around with
and some can even make a big difference, particularly:
--fullscale Uses full scale image to detect
keypoints (default:false)
This is often helpful if you have hi-res images, it can dramatically
increase the number of CPs found, but it will take (sometimes much)
more time. The reason for this is that the CPG routinely scales down
the images to reduce processing time. Using --fullscale stops it fro
downscaling. Other CPGs give you the option to specify how much
downscaling you want, here you can only switch it on or off.
--multirow Enable heuristic multi row matching
(default: off)
--linearmatch Enable linear images matching (default :
all pairs)
--linearmatchlen <int> Number of images to match in linear
matching (default:1)
these are used for avoiding to have to compare every image to every
other. Usually your hugin settings will decide whether to use them or
not. They have little effect on the match quality, but a great effect
in speeding up matching for mutlirow or linear panos.
--minmatches <int> Minimum matches (default : 4)
I'm not sure if this one is actually looked at, but if you get too few
CPS, you may try and raise it.
The remainder deal with the mathematics I've outlined above. The
defaults are sensible and experimentation with them is unlikely to be
productive unless you know what you're doing:
--sieve1width <int> Sieve 1 : Number of buckets on width
(default : 10)
--sieve1height <int> Sieve 1 : Number of buckets on height
(default : 10)
--sieve1size <int> Sieve 1 : Max points per bucket
(default : 50)
--kdtreesteps <int> KDTree : search steps (default : 200)
--kdtreeseconddist <double> KDTree : distance of 2nd match
(default : 0.25)
--ransaciter <int> Ransac : iterations (default : 1000)
--ransacdist <int> Ransac : homography estimation distance
threshold (pixels)
(default : 25)
--sieve2width <int> Sieve 2 : Number of buckets on width
(default : 5)
--sieve2height <int> Sieve 2 : Number of buckets on height
(default : 5)
--sieve2size <int> Sieve 2 : Max points per bucket
(default : 2)
I hope this has shed some light on the issue.
Kay
bloody tomatoes
that said, i don't know why changing sieve1size instead of sieve1width/height is a better or worse idea. or, if i should lower the "minmatches" value instead.
if there were say 5 parameters to test with 4 different values (1024 combinations) on 10 different kinds of panos, would that be helpful? I'll do it :) I have a computer, and my house is cold ;-)) Would this be helpful?
kfj
On 19 Jan., 15:50, bloody tomatoes <bloodytomat...@gmail.com> wrote:
> if there were say 5 parameters to test with 4 different values (1024
> combinations) on 10 different kinds of panos, would that be helpful? I'll do
> it :) I have a computer, and my house is cold ;-)) Would this be helpful?
vary ;-)
Kay
bloody tomatoes
Jeffrey Martin
it says "If you want to use this multi-row matching inside hugin set the control point detector type to All images at once."
Why wouldn't you set it to "multi row" ??
Bruno Postle
> on this page http://wiki.panotools.org/Cpfind#Feature_matching it
> says "If you want to use this multi-row matching inside
> hugin<http://wiki.panotools.org/Hugin>set the control point
> detector type to All images at once
> <http://wiki.panotools.org/Hugin_Parameters_for_Control_Point_Detectors_dialog#All_images_at_once>
> ."
>
> Why wouldn't you set it to "multi row" ??
The 'multi-row' option in the Hugin preferences predates cpfind. It
was created to use generatekeys/autopano from autopano-sift-C to do
the multi-row matching as a series of processes that are controlled
by Hugin and linked by temporary keyfiles.
The `cpfind --multirow` parameter now does all this internally
without creating temporary files, which is presumably a lot faster,
and it means that it can be used as a 'normal' control point
generator by Hugin.
cpfind can also do caching of keyfiles on disk when asked, so you
could still use the 'multi-row' option but with cpfind, this would
potentially consume less memory but I haven't done any tests.
--
Bruno
Pablo d'Angelo
Am 17.01.2011 17:52, schrieb bloody tomatoes:
> Hello,
>
> I'm reading this http://wiki.panotools.org/Cpfind and i have a few
> questions:
>
> 1) The default settings of cpfind - this is the best setting for normal
> (non-fisheye) images? or it's "probably good enough" but as cpfind is
> very new, it could use more testing?
I did test the default setting (cpfind as in
hugin-mac-2010.5.0-4854_d29b1d6da0e0 by Harry) mainly on different
fisheye images Jeffrey send me, and they worked fine.
In general, I think the settings are fine for most panos. If you have
examples where the default settings fail, please let me know.
> 2) What does --ransaciter and --ransacdist do (in plain english) ?
Part of the ransac based outlier removal, see
http://en.wikipedia.org/wiki/RANSAC
Basically it tries to optimize an image pair and keeps only matches
which have an error smaller than ransacdist. Setting this too strict
will remove more matches than nessecary. Values between 10 and 50 are
probably good. The current implementation in cpfind is a bit crude and
works best for "normal" images. Wide angle and fisheye images are
currently not handled well, and the ransacdist is currently increased if
that happens. I'm working on a proper solution though.
> 3) "To achieve good control points images with a high horizontal field
> of view (e.g. ultra wide rectilinear or fisheye) are therefor remapped
> into a conformal space (cpfind is using the stereographic projection
> <http://wiki.panotools.org/Projection#Stereographic_projection>) and the
> feature matching occurs in this space."
> how does cpfind decide what to remap to conformal space, or not? or is
> it depending on the lens type? (rectilinear no, fisheye yes) ?
All images with a hfov > 65 are remapped into stereographic (unless they
are already stereographic, as the Samyang 8mm fisheye is, so choose
stereographic as input projection if you have a Samyang 8mm fisheye.)
> 4) When doing "linear" and "multirow" matching, does it try to join the
> images in a 360? or only the first/last image? or not at all?
I'm not sure on the linear matching, but the multirow matching will try
to connect all overlapping images. However, it might not work if the
roll angles of the images change a lot, as overlap is only computed on a
pano where yaw and pitch have been optimized. That is probably fine for
large multirow projects shot from a panohead, but maybe not so great for
hand held sphericals with wide angle lenses...
> 5) Changing --kdtreesteps and --kdtreeseconddist affect the final number
> of keypoints found. is there anything more specific that should be
> known? or should these numbers stay as they are (i'm guessing they
> should be played with, since the parameters are there to be played with!)
Larger kdtreesteps tell cpfind to look harder for matches. I think 200
is probably good enough, but it could be improved. Not so important.
kdtreeseconddist determines how "similar" corresponding matches need to
be. Smaller values force cpfind to accept only unique matches, larger
values accept more, but potentially bad matches. If no points can be
found, increasing this to 0.4 or so might be worth a try, but there will
be more errors.
> 6) Is there any good reason to have --sieve1size at 30 and not 3000
> (more is better) ?
More is also slower... Sievesize 3000 basically means take all features
found.
ciao
Pablo
Jeffrey Martin
By the way, with these photos, I am still getting CP's outside the cropping circle. does anyone have any idea why that would be the case?
www.vrlog.net/temp/cpfind-pablo/bad-cp-shaved-nikkor.zip
questions:
1) is cpfind using the lens FOV to calculate CP's? (as autopano sift C does)
(only FOV? or also a/b/c ?)
2) is cpfind supposed to use the crop in hugin (so that there should not be CP's outside the crop)?
I will keep testing.
Harry van der Wolf
Thanks Pablo for the detailed explanations.
By the way, with these photos, I am still getting CP's outside the cropping circle. does anyone have any idea why that would be the case?
www.vrlog.net/temp/cpfind-pablo/bad-cp-shaved-nikkor.zip
Are you using the previous 4854_d29b1d6da0e0, still containing the error for fisheye FOVs > 170, or do you use the latest 4857_9cf4ed265424 where this error SHOULD be solved (not user off course as I don't have an image set with these kind of fisheye images.
It's only a small change in mail header and number, but it could be the main differentiator here.
Which brings me to the next question: Some time ago we decided on standard test sets, didn't we?
If so, where are they?
Harry
Pablo d'Angelo
Am 19.01.2011 22:23, schrieb Jeffrey Martin:
> Thanks Pablo for the detailed explanations.
>
> By the way, with these photos, I am still getting CP's outside the
> cropping circle. does anyone have any idea why that would be the case?
> www.vrlog.net/temp/cpfind-pablo/bad-cp-shaved-nikkor.zip
>
> questions:
> 1) is cpfind using the lens FOV to calculate CP's? (as autopano sift C does)
> (only FOV? or also a/b/c ?)
It uses the full information (including a/b/c), crop circle and masks.
> 2) is cpfind supposed to use the crop in hugin (so that there should not
> be CP's outside the crop)?
Yes, it should. I have seen that the circle in your example was a bit
offset. This might be related to the "center on d/e" in the crop panel.
This means that the circle is always centered on the d/e parameters,
which worked nicely with my peleng. If bad d/e parameters are used, the
circle will be shifted. You could try without the "center on d/e".
I haven't added any safety margin for the crop in cpfind, so the the
crop circle should never be outside the image.
So far I used the following procedure for fisheye panos:
0. (Do only once:) Enter Preferences/control point creator. Create a new
cpfind detector entry change the default cpfind entry to use only the
"-o %o %s" arguments and make it the default. (multirow might or might
not be suitable for this purpose..)
1. Load images into hugin
2. Select fisheye and enter focal length and crop factor
3. Set crop on all images.
4. Press "align" button
5. (straighten + look for bad control points), optimize with a,b,c, d,e
if required.
6. save lens settings for later usage.
Once you have saved your lens, you can load the parameters and crop with
the "Load lens" button, and skip step 2 and 3.
ciao
Pablo
Jeffrey Martin
yes, I used the latest one.
Jeffrey Martin
Thanks for the explanation. A couple questions and clarifications:
On Wednesday, January 19, 2011 10:46:59 PM UTC+1, Pablo d'Angelo wrote:
> 2) is cpfind supposed to use the crop in hugin (so that there should not
> be CP's outside the crop)?Yes, it should. I have seen that the circle in your example was a bit
offset. This might be related to the "center on d/e" in the crop panel.
This means that the circle is always centered on the d/e parameters,
which worked nicely with my peleng. If bad d/e parameters are used, the
circle will be shifted. You could try without the "center on d/e".
https://bugs.launchpad.net/hugin/+bug/704884 i am using the command line to do this stuff, is this maybe where my problem is?
Pablo d'Angelo
> Hi Pablo,
>
> Thanks for the explanation. A couple questions and clarifications:
>
> On Wednesday, January 19, 2011 10:46:59 PM UTC+1, Pablo d'Angelo wrote:
>
> Yes, it should. I have seen that the circle in your example was a bit
> offset. This might be related to the "center on d/e" in the crop panel.
> This means that the circle is always centered on the d/e parameters,
> which worked nicely with my peleng. If bad d/e parameters are used, the
> circle will be shifted. You could try without the "center on d/e".
>
> with my example, the vertical offset is about 100 pixels - due to the
> lens being on an adapter, maybe. anyway,
You can savely untick the "center on d/e", then you move the crop circle
freely.
> I filed a bug report about this
> yesterday.
> https://bugs.launchpad.net/hugin/+bug/704884
I can confirm that.
I tried searching for the right spot in the code, but I'm not very
familiar with the refactoring that James had done on SrcPanoImage class.
Where can I insert a "hook" for intercepting changes to the d/e
parameters? Maybe some other Developers (Thomas, James?) can give me a
small hint.
> i am using the command line
> to do this stuff, is this maybe where my problem is?
Can you give a summary what you have done (in hugin and on the command
line?)
ciao
Pablo
Can-C. Dörtbudak
same problem for me. I've tried the fullscale option and sieve1size
etc. as well. I can't find control points in the pictures of my
walimex fish eye. If somebody wants to verify this here is the link to
the pictures: http://www.doertbudak.de/test_can.zip
Cheers, Can
Pablo d'Angelo
On 21 Jan., 09:07, Can-C. Dörtbudak <doertbu...@googlemail.com> wrote:
> same problem for me. I've tried the fullscale option and sieve1size
> etc. as well. I can't find control points in the pictures of my
> walimex fish eye. If somebody wants to verify this here is the link to
> the pictures:http://www.doertbudak.de/test_can.zip
development version, and the default cpfind settings.
Hugin 2010.4 will NOT work, you need the most recent development
version (harrys latest OSX build might work too, although it doesn't
yet contain a proper RANSAC for fisheye images).
I did the following steps:
1. Load images
2. Set full frame fisheye, HFOV
3. Press Align button
And this properly connected all images, even though the overlap is
quite small.
ciao
Pablo
Can-C. Dörtbudak
many thanks for this very quick response. I have to have the latest
dev Version. Where do i get this one? Do i need to compile it myself?
Thanks, Can
Dale Beams
Dale
> Date: Fri, 21 Jan 2011 02:53:54 -0800
> Subject: [hugin-ptx] Re: Cpfind for Dummies
> From: doert...@googlemail.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
Can-C. Dörtbudak
i would like to run in on win7 64bit.
Can
On 21 Jan., 14:37, Dale Beams <drbe...@hotmail.com> wrote:
> What OS and distro are you using?
>
> Dale
>
> > Date: Fri, 21 Jan 2011 02:53:54 -0800
> > Subject: [hugin-ptx] Re: Cpfind for Dummies