APSCpp Revision Log started 18 July 2009 TKSharpless
18 July some quick & easy changes
-- #define PACKAGE_VERSION "2.5.1" in AutoPanoSift.h
TODO: separate APSCpp version no. from gk/ap one
-- correct code for smoothing image before size reduction
1) delete orignal image and swap the pointers
2) do it in the if(Scale > 1) block
-- add user controls on stereographic projection
1) --stereographic off prevents conversion
2) --stgfov sets minimum hfov for conversion. Show this
in the setup report on stereographic option
implement as new argument stgfov to GenerateKeyspp()
(< 0 prohibits conversion)
-- remove alignment and related options from APSCpp_main.c
1) delete from usage text
2) delete corresponding commandline parsing
3) delete all code that referred to bondball
4) pass null alignment params to write_pto (as if the
option had been switched off)
TODO: remove references in other files,verify that linker
nolonger loads bondball from libsift.
-- add (dummy) option --align-aware to control proposed
layout-based keypoint selection.
-- revise the usage text and some other explanatory messages
for better clarity.
-- Display revision number in startup banner.
-- Add a couple of status reports to better delineate image
-- verify no cumulative memory loss during keypoint finding.
-- add this file to svn, commit as SVN 4054
19 July Further Q&D's
-- change "align-aware" to "use-layout" (clearer)
-- eliminate option to use legacy k-d tree, ANN only.
1) remove usage line and command parse
2) remove control var useANN & uses of it
3) eliminate mode argument to GenerateKeyspp & code
that used it.
Now for project file loading -- APSCpp.c:LoadProjectImages()
-- it already loads y,p,r, now change needed
-- make it parse PTAsm, PTGui style file names...
These are on comment lines of the form
#-imgfile 3522 2348 "_MG_6981.CR2"
rather than on 'i' or 'o' lines. Name may be full path.
debugging load pts and ptp projects..
ptp load ok, but pts has a "dummy image" o-line that makes
trouble. I think it can be handled just by skipping o-lines
that don't have a file name -- must reset FNflag at eof in
case 2 passes.
But it can't, because file o-lines have back references to
dummy image attributes. So we have to support a true dummy
image in the DIinfo list. Grrr. Let's do that by leaving the
file name null and inserting checks for that where needed.
That seems to work, however a,b,c from the dummy image line
are not making it to the output file (not unsurprising as we
don't read them, but we should).
Here's what three PT family stitchers report for the hfov
of two fisheye images, using EXIF data
stitcher FL crop rectilinear fisheye
PTAsm 5.0 15 1.6 73.74 85.94
Hugin 0.8 15 1.6 73.69 85.86
PTGui 8.1 15 1.587 74.19 91.67
PTAsm 5.0 8 1.6 109.16 161.14
Hugin 0.8 8 1.6 109.1 161
PTGui 8.1 8 1.587 86.77 180
PTGui recognizes both lenses as fisheyes, PTAsm and Hugin
have to be told. But it gets the crop factor wrong (Hugin
has 1.60149, the value I compute from the 30D EXIF data).
PTGui uses the equal-area formula for fisheyes, the others
use the equal-angle. The big discrepancy on the 8mm fisheye
is because PTGui reports crop circle diameter for "circular"
fisheyes, all other fovs are for the short image dimension.
Fixed nasty bug in WritePTOFile(): using same index in outer
& inner loops. This could cause some i-lines to disappear.
To get a,b,c into the output:
--add them to DIinfo and project parser
--write them to output pto
Now deal with some differences between stitchers
1) PTAsm and PTGui give image dimensions in #-imgfile line,
so have to read those.
2) for circular fisheye, PTGui's hfov is the diameter of the
cropping circle. Hugin & PTAsm give fov for the horizontal
axis, even if that exceed crop circle. This ccould be fixed
at project read time by rescaling PTGui's number to hdim, if
I knew the crop circle diameter in pixels. But that info is
not apparent in the project file.
3) If the EXIF specifies an orientation, PTGui reports image
as oriented that way, regardless of filed orientation. Hugin
and PTAsm use the filed dimensions. This means we have to
check the filed dimentsions against the nominal ones when we
read the images, and adjust hfov if they don't agree.
4) PTAsm lets you specify fisheye type, using format 29 for
equal-area. Hugin treats all fisheyes as equal angle, PTGui
treats all as equal-area. APSCpp should let you choose.
21 July -- deal with stitcher differences...
-- read PTAsm and PTGui image dims like the file name;
-- adjust hfov at file read if DIinfo dims are transposed
(fatal error if they don't match either way).
-- provisionally assume PTGui's crop circle diameter equals
the long image axis.
TODO: correct this when better informed (have written Joost).
To deal with both fisheye types...
-- command option --equal-angle-fisheye sets default fisheye type
-- make CamLens treat formats 2,3 as equal-angle, 8 as equal-area;
-- make readProject identify Hugin, PTasm & PTGui projects and
accept PTAsm format 29 as equal-area fisheye (convert to 8),
and if not PTAsm, convert formats 2 & 3 to the default, and
adjust hfov if necessary.
-- print name of source format when converting to stg. (code is
already shown, but who knows what that means?)
1) set up Hugin, PTAsm and PTGui projects for 3 circular fisheye
images, and same rotated 90 degrees. Build release APSCpp and
run against all 6 projects (equal area, no ransac) giving 6 pto's.
Load those in Hugin and compare alignments.
2) run same projects with default equal-area fisheye; compare
3) set up Hugin, PTAsm and PTGui projects for a rectilinear
image set, and its rotated form; run & compare alignments.
Found 2 problems:
1) writing out format 8, should have been put back to 2 or 3.
(how to tell which??)
2) FL reported by Hugin depends on originating stitcher, and
not quite right even when that was Hugin.
-- at read project, compute fl in pixels & put that in DIinfo
then compute hfov from it where needed (incl. @ output)
-- review all the monkey motion with hfov, delete code where
And maybe someday....
-- add copy-project option
This is a goal left over from original revision, that seems
more desirable now: an option to output a copy of the whole
project file, with old CPs commented out and new ones added.
To comment-out use "#-old-CP "
Give the output file name the same extension as the input
project, no matter what user enters?