Hi all,
panomatic and thus cpfind use a RANSAC step for outlier removal. This
used to be based on a homography, which works ok for non-wide angle
images. It breaks for fisheye images, here a large error tolerance must
be choosen, and this results in a rather weak outlier check for wide
angle and fisheye images.
Additionally, the homography is more general than what we expect for
panoramic images (it can also "mirror" images, for example), and this
can result in some false matches slipping through, even when a
relatively strict RANSAC threshold is choosen. Unfortunately, this can
sometimes connect unrelated images together, and cpclean doesn't help as
it won't remove all matches in an image pair.
I have thus implemented a new RANSAC model that can make use of the
restrictions we have in panoramas, and also include prior information
about lens type, HFOV and distortion etc. Basically, it tries to
estimate roll,pitch and yaw for each image pair (using two control
points), and checks if the remaining points are consistent, and repeats
that a few times.
A new --ransacmode parameter can be used to switch between the ransac
modes. By default it uses the homography and switches to the
roll,pitch,yaw model if the HFOV is bigger than 65 degrees, the same
value that is used to decide whether to remap to stereographic or not.
For testing, the HFOV can also be estimated in the RANSAC routine, but
this is quite fragile due to panotools problems with estimating HFOV on
image pairs.
Some examples:
--ransacmode rpy (new)
http://www.flickr.com/photos/vonengel/5378995090/
--ransacmode auto (default mode, uses homography)
http://www.flickr.com/photos/vonengel/5378994908
Unfortunately, in some cases, the HFOV is not know very well (incomplete
EXIF data, bad crop factors entered by the user etc...), so one cannot
unconditionally recommend --ransacmode rpy.
It might be possible to work around that problem, but it will require
some significant work, and I'm not sure if it worth it.
For the user that means:
1. User has a good estimate of the HFOV (EXIF Data or prior
calibrations) -> use cpfind --ransacmode rpy
which makes cpfind virtually bullet proof to really bad mismatches.
2. Bad EXIF Data and user doesn't know about crop factors or the like ->
use cpfind --ransacmode auto (the default) or cpfind --ransacmode
homography, and accept some outliers.
I hesitate to default to --ransacmode rpy, as this will probably lead to
quite some breakage for novice users, who enter bad crop factors.
I find 2. a bit unsatisfying as it means that we will get suboptimal
results for many inexperience users (and many experienced ones too, who
don't know about all the cpfind internals...).
Whats your opinion about that?
- Should we add more default presets to the control point detector
preferences?
- Try to automatically add --ransacmode rpy, if the hugin could
successfully read HFOV from the EXIF data?
- Try to robustly add HFOV to the RANSAC model? Maybe just trying a
range of initial HFOVs would be sufficient... However, I'm not sure if I
can do that with my limited time budget.
Another way to reduce the problem would be to use a camera-crop factor
database, such as the one from Autopano PRO:
http://www.autopano.net/wiki-en/Cameras.txt
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
