Hi all
I'm revising autopano-sift-c to try to make it work better, and
provide some interoperability with PTAssembler and PTGui. These
changes apply only to my single-program version, also known as APSCpp;
the old two-program package (generatekeys + autopano) remain as
before.
First the not-so-bad news...
1) APSCpp can now read project files from PTAssembler and PTGui as
well as Hugin and PTStitcher, and allows for most of the differences
in how they specify angular scale (i.e. focal length). It also reads
image alignment angles and lens correction coefficients, and has
command line options to use them; however those options are not
implemented yet. The output, as before, is a Hugin project file
containing the same image specifications, plus new control points. So
now APSCpp is a way to convert (parts of) a PTGui or PTAsm project
into a Hugin project.
2) You can specify angular scale on the command line as focal length
and crop factor, as an alternative to the traditional but unreliable
hfov and image dimensions.
3) You can set the lens type explicitly to rectilinear, equal-area
fisheye, or equal-angle fisheye. The format code in the project file
is then used only to interpret the hfov given there, but not for
projecting the images. Otherwise the lens type for the fisheye format
codes (2,3) defaults to equal-area or equal-angle according to another
command line option. I decided to do it that way after seeing how
absurd it would be to rely on the lens type assumed by the stitcher
that originated the project file. They all agree on rectilinear, of
course, however for fisheyes Hugin assumes equal-angle while PTGui
assumes equal-area (Joost tells me you can specify equal-angle
somehow, but I have not found the way). PTAsm lets you choose, and
defines a format code for equal-area, but unfortunately computes the
angular scale wrong in that case.
4) You can choose whether or not to convert images to stereographic
format for keypoint finding, or set a threshold hfov below which this
conversion will not be done.
now the not-so-good...
Here are some test results, on a set of six fullframe fisheye images.
CPs Avg Worst
PTGui 8.1 autoalign 200 1.0 7.8
APSCpp 2.5.2, Hugin autoalign, reduce source 2.19x...
no stg 245 2.9 35.4
no stg + refine 249 3.5 307
stg 222 2.1 17.5
stg + refine 241 2.7 26.8
and at full source resolution...
no stg, full rez 334 2.9 20.6
stg, full rez 296 2.1 19.2
Stereographic remapping seems quite worthwhile, and gives a big payoff
per CPU second because it runs very fast. Reducing resolution did not
degrade CP quality measurably.
The refine option takes a very long time and makes the result worse.
It is actually an attempt to find SIFT CPs over again at original
resolution, in small patches around the found CPs. I think I'll drop
it, possibly in favor of something like local correlation, perhaps on
patches that have be reprojected to on-axis rectilinear...
But the bottom line is that APSCpp's CPs are still far worse than
PTGui's. And it takes about 5 times longer to find them.
The obvious needs...
1) The quality of keypoints must be improved. Much of the error in
the Hugin alignments is clearly due to visible small shifts of the
keypoint positions between the 2 images.
2) Duplicate CPs still appear oftener than I like (I would prefer
none).
3) The ransac option does prune some bad CPs, but not enough, it needs
attention too.
4) The refine option needs to be replaced with something more
effective.
And finally the hopes and fears...
1) Layout guided CP placement. Use the alignment given in the project
file to decide where the images probably do and do not overlap.
Should improve results on any image set; necessary for handling large
image sets efficiently (or indeed, at all, in the gigapixel range).
2) Lens correction. Use the lens correction coefficients given in the
project file while reprojecting images. Probably of limited interest
as it could only improve results that are already destined to be very
good; and of little use so long as the stitchers have such poor ways
of specifying what lens they have in mind. But easy to implement (my
remapper does polynomial radius correction) and could become useful
when we have good lens databases.
3) Refinement through spherical mapping. Several possible ways of
"polishing" the CP set would use keypoints projected onto the
panosphere instead of in image coordinates. Some of these would
depend on an assumed alignment, but some basic ones would not -- only
on the angular distance between a single pair of images, as estimated
from the CPs under test.
-- Tom
--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
