Diff of /RevisionLog.txt [03d2ea] .. [d9c482]  Maximize  Restore

Switch to side-by-side view

--- a/RevisionLog.txt
+++ b/RevisionLog.txt
@@ -156,3 +156,147 @@
 Give the output file name the same extension as the input
 project, no matter what user enters?
+22 July Design for layout-guided CP selection
+The key thing is to match keypoints for one pair of images 
+at a time.  A list of pairs to be processed will be created, 
+based on overlaps predicted by the layout.  
+The overlaps should be evaluated using only (Y,P) and some
+kind of average image diameter.  Then candidate CPs can be
+validated (for each pair) as follows.
+1) map KP coordinates to the sphere (using lens fn, including
+correction if known).
+2) repeat {
+  find rotation of one image around optic axis that minimizes 
+  the variance of KP differences (considered as 3-vectors);
+  discard outlier CPs;
+} until( set is pretty compact );
+3) If there are more than maxmatches CPs left, sort them on 
+position across the line between image centers, divide into 
+maxmatches groups, and keep the strongest CP in each group.
+If there is no layout, it is more efficient to match KPs for
+all images at once, as now; however for really big jobs it
+might be necessary to divide the kp's into several groups &
+do global matching on those.  Anyhow, we should then select
+the image pairs having decent numbers of matches and do the
+rotational refinement on those.
+It would be possible to construct a complete alignment from
+the results of the pairwise alignments.  But perhaps just a
+consistency check is enough.
+It might be feasible to use a Monte Carlo approach to
+build the overlapping pairs list:  Match a random selection
+of keypoints (equal numbers from each image), count matches 
+by pair, use the pairs with above average numbers of matches.  
+This could be a good check for layout errors, too.
+So I need a KP matching subroutine that will support all
+these modes.  For full generality it should take a list of
+KP lists to be loaded into the k-d tree, and a second list
+of KP lists to be used as probes, and output a list of CPs
+(caller can separate that into lists by image pair).
+And a rotational optimizer that takes a list of CPs for a
+single pair of images; the projection specifications; and
+maybe a tuning parameter or two, and returns the subset of
+good CPs and the relative alignment of the pair.  I don't
+think this needs to be given an initial alignment.
+I'd like to abandon Nowozin's MultiMatch structure as it
+puts all KP data and CP data "in one basket", making it
+hard to partition a big job pairwise.  That will mean
+abandoning his polishing fns too, as they all assume a
+MultiMatch.  So with this change the "autopano" part of
+APSCpp will become a completely different program from
+For a performance boost on multicore systems, it would be
+good to repackage the KP finder as a task (or a separate
+command pgm).
+But first, test whether there are any systematic coordinate
+errors in CPs:
+-- make project with an image and same rotated 90 degrees;
+   check optimization errors.
+1) Hugin assigns different focal lengths to the 2 images, so
+must set them equal by hand. It then stitches them with near
+perfect cancellation, either with the 90 deg rotation set at 
+load, or using CPS from legacy APSCpp.
+PFS_093-PFS_093-rot.pto, "8mm crop 1.60149 circular fisheye".
+2)Run this thru APSCpp 2.5.2 giving
+ 93-93r-stg.pto  -- maxdim 1600, stg on
+    Hugin and PTAsm display CP at same spots in both images;
+    Hugin gets good auto alignment after deleting 2 bad CPS.
+    PTAsm auto alignment fails.
+ 93-93r-nostg.pto  -- maxdim 1600, stg off
+    Hug & Pta show CPs not coinciding, 
+    Hug auto alignment very bad.
+Clearly I am botching CP rescaling when the stg is off.
+-- try re-using the pre-find remapper & (when stg off) inverting 
+the pre-find scale. Now both stg on & stg off CPs are misplaced!
+The relative positions are same in both images, but all are in
+the wrong places.
+So must review how to prescale & scale back.... tomorrow.
+23 July	kp coord scaling tests w/rotated image pairs
+-- put stg rescaling back the way it was.  Compute true factor
+   from long image axis instead of width.
+Now stg on gives good match w/90 deg rot (1 wild CP), stg off
+still gives shifted CP sets.
+-- try 180 deg rotation:  PFS_093-PFS_093-180.pto
+stg on: perfect alignment (1 bad point).
+stg off: perfect alignment (2 bad points). 
+So it looks like N. code gets coords wrong on 90 deg rot, and
+SAremap somehow corrects that??  No, as usual the fault is all
+mine:  I forgot to make undoing the stereographic mapping
+conditional on having done it in the first place.  With that 
+fixed the no-stg 90 deg case aligns perfectly (0 bad pnts) -- 
+indeed significantly better than with stg enabled, which means
+the remapping makes SIFT localization a bit less certain.
+Now that it's working, improve the API some more....
+-- lens-type option to override PT format codes.
+-- focal-length + crop factor option to override hfovs.
+-- lens-correction option to use a,b,c,d,e from project.
+26 July BUT FIRST -- some more testing
+Test set: L:EOSPix\StFx\IMG_7346-7350.pts.  Six 15mm fisheye 
+pix that stitch well with PTGui.  Run APSCpp with ransac on, 
+maxdim 1600 (2.19x reduction), autoalign with Hugin...
+  result		CPs	Avg	Worst
+  PTGui	autoalign	200	1.0	7.8
+  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...
+Anyhow 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.
+BTW ransac does prune some bad points, but not enough, it
+needs attention too.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks