Hi Bloddy,
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
--
You received this message because you are subscribed to the Google Groups "Hugin and
other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
