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

Switch to unified view

a/RevisionLog.txt b/RevisionLog.txt
...
...
154
To comment-out use "#-old-CP "
154
To comment-out use "#-old-CP "
155
155
156
Give the output file name the same extension as the input
156
Give the output file name the same extension as the input
157
project, no matter what user enters?
157
project, no matter what user enters?
158
   
158
   
159
22 July Design for layout-guided CP selection
160
161
The key thing is to match keypoints for one pair of images 
162
at a time.  A list of pairs to be processed will be created, 
163
based on overlaps predicted by the layout.  
164
165
The overlaps should be evaluated using only (Y,P) and some
166
kind of average image diameter.  Then candidate CPs can be
167
validated (for each pair) as follows.
168
169
1) map KP coordinates to the sphere (using lens fn, including
170
correction if known).
171
2) repeat {
172
  find rotation of one image around optic axis that minimizes 
173
  the variance of KP differences (considered as 3-vectors);
174
  discard outlier CPs;
175
} until( set is pretty compact );
176
3) If there are more than maxmatches CPs left, sort them on 
177
position across the line between image centers, divide into 
178
maxmatches groups, and keep the strongest CP in each group.
179
180
If there is no layout, it is more efficient to match KPs for
181
all images at once, as now; however for really big jobs it
182
might be necessary to divide the kp's into several groups &
183
do global matching on those.  Anyhow, we should then select
184
the image pairs having decent numbers of matches and do the
185
rotational refinement on those.
186
187
It would be possible to construct a complete alignment from
188
the results of the pairwise alignments.  But perhaps just a
189
consistency check is enough.
190
191
It might be feasible to use a Monte Carlo approach to
192
build the overlapping pairs list:  Match a random selection
193
of keypoints (equal numbers from each image), count matches 
194
by pair, use the pairs with above average numbers of matches.  
195
This could be a good check for layout errors, too.
196
197
So I need a KP matching subroutine that will support all
198
these modes.  For full generality it should take a list of
199
KP lists to be loaded into the k-d tree, and a second list
200
of KP lists to be used as probes, and output a list of CPs
201
(caller can separate that into lists by image pair).
202
203
And a rotational optimizer that takes a list of CPs for a
204
single pair of images; the projection specifications; and
205
maybe a tuning parameter or two, and returns the subset of
206
good CPs and the relative alignment of the pair.  I don't
207
think this needs to be given an initial alignment.
208
209
Infrastructure---
210
I'd like to abandon Nowozin's MultiMatch structure as it
211
puts all KP data and CP data "in one basket", making it
212
hard to partition a big job pairwise.  That will mean
213
abandoning his polishing fns too, as they all assume a
214
MultiMatch.  So with this change the "autopano" part of
215
APSCpp will become a completely different program from
216
autopano.
217
218
For a performance boost on multicore systems, it would be
219
good to repackage the KP finder as a task (or a separate
220
command pgm).
221
222
But first, test whether there are any systematic coordinate
223
errors in CPs:
224
-- make project with an image and same rotated 90 degrees;
225
   check optimization errors.
226
1) Hugin assigns different focal lengths to the 2 images, so
227
must set them equal by hand. It then stitches them with near
228
perfect cancellation, either with the 90 deg rotation set at 
229
load, or using CPS from legacy APSCpp.
230
PFS_093-PFS_093-rot.pto, "8mm crop 1.60149 circular fisheye".
231
2)Run this thru APSCpp 2.5.2 giving
232
 93-93r-stg.pto  -- maxdim 1600, stg on
233
    Hugin and PTAsm display CP at same spots in both images;
234
    Hugin gets good auto alignment after deleting 2 bad CPS.
235
    PTAsm auto alignment fails.
236
 93-93r-nostg.pto  -- maxdim 1600, stg off
237
    Hug & Pta show CPs not coinciding, 
238
    Hug auto alignment very bad.
239
Clearly I am botching CP rescaling when the stg is off.
240
-- try re-using the pre-find remapper & (when stg off) inverting 
241
the pre-find scale. Now both stg on & stg off CPs are misplaced!
242
The relative positions are same in both images, but all are in
243
the wrong places.
244
So must review how to prescale & scale back.... tomorrow.
245
246
23 July   kp coord scaling tests w/rotated image pairs
247
-- put stg rescaling back the way it was.  Compute true factor
248
   from long image axis instead of width.
249
Now stg on gives good match w/90 deg rot (1 wild CP), stg off
250
still gives shifted CP sets.
251
-- try 180 deg rotation:  PFS_093-PFS_093-180.pto
252
stg on: perfect alignment (1 bad point).
253
stg off: perfect alignment (2 bad points). 
254
255
So it looks like N. code gets coords wrong on 90 deg rot, and
256
SAremap somehow corrects that??  No, as usual the fault is all
257
mine:  I forgot to make undoing the stereographic mapping
258
conditional on having done it in the first place.  With that 
259
fixed the no-stg 90 deg case aligns perfectly (0 bad pnts) -- 
260
indeed significantly better than with stg enabled, which means
261
the remapping makes SIFT localization a bit less certain.
262
263
Now that it's working, improve the API some more....
264
-- lens-type option to override PT format codes.
265
-- focal-length + crop factor option to override hfovs.
266
-- lens-correction option to use a,b,c,d,e from project.
267
268
26 July BUT FIRST -- some more testing
269
270
Test set: L:EOSPix\StFx\IMG_7346-7350.pts.  Six 15mm fisheye 
271
pix that stitch well with PTGui.  Run APSCpp with ransac on, 
272
maxdim 1600 (2.19x reduction), autoalign with Hugin...
273
  result      CPs Avg Worst
274
  PTGui   autoalign   200 1.0 7.8
275
  no stg      245 2.9 35.4
276
  no stg + refine 249 3.5 307
277
  stg         222 2.1 17.5
278
  stg + refine        241 2.7 26.8
279
and at full source resolution...
280
  no stg, full rez    334 2.9 20.6
281
  stg, full rez       296 2.1 19.2
282
283
Stereographic remapping seems quite worthwhile, and gives 
284
a big payoff per CPU second because it runs very fast.
285
286
Reducing resolution did not degrade CP quality measurably.
287
288
The refine option takes a very long time and makes the result
289
worse.  It is actually an attempt to find SIFT CPs over again 
290
at original resolution, in small patches around the found CPs.  
291
I think I'll drop it, possibly in favor of something like local 
292
correlation, perhaps on patches that have be reprojected to
293
on-axis rectilinear...
294
295
Anyhow the bottom line is that APSCpp's CPs are still far
296
worse than PTGui's.  And it takes about 5 times longer to
297
find them.
298
  
299
BTW ransac does prune some bad points, but not enough, it
300
needs attention too.
301
302
BTW 

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks