[Work Log] Work Log

November 23, 2013

Need to re-focus my efforts on getting WACV datasets working by December 10. My recent efforts have shown good progress on the hard problem of inferring the index set under difficult conditions, but I only have about 2 weeks to get results and write the paper, so I should be focusing on a few quick-and-dirty fixes first (improved camera calibration, naive correspondence matching). These fixes only apply to the super-clean WACV datasets, so they won't help for ECCV, but they'll get the paper out, which is what matters at the moment.

TODO today:


next

Investigating bad reconstruction of curve 2

it was reversed. fixed.

Wait, now several views of several curves are missing. Also, several corrections I remember making are now missing. What is going on? Did I somehow overwrite an old file? Can I recover it from time machine?

...

Okay, recovered from time machine. Still not sure what caused this.

Running WACV w/ linear-map correspondences

Getting NaN when estimating branch distance. Coincident points aren't handled sensibly. Fixed; also added handling of degenerate curves (single point repeated multiple times).

Running succeeded (FIX_WORLD_T is off).

The reconstructed result for dataset 8 looks good (for the first time ever), but the base point moves from view to view, even though we've removed the offset component from the kernel.

...

Found the problem: had commented out some lines during debugging; caused offset perturbations to remain in the reconstruction.

...

Enabling FIX_WORLD_T. Rerun succeeded, result looks reasonable; seems 98% identical to the version with FIX_WORLD_T disabled.

...

Getting some attachment issues. Deteched reconstruction shows a few curves were badly reconstructed. time to try new cameras

...

new cameras seem to be reconstructing everything in reverse??? is it an axis-flipping issue?

...

It turned out to be an error in my calibration routine. I had x and y swapped in my 3D coordinates.

...

Everything is now working. Result: New results aren't qualitatively different from results using old cameras. Back to the drawing board.

...

The failing curves seem to be caused by at least one view where the curve is view on-end. The resulting reconstructed points have lots of variability as to where on the 3D curve they arise from; in some cases, the chosen point is well in to the "extrapolation region" of the curve, i.e. past the end of where the other well-localized points stop.

On the plus side, these badly localized points have lots of variance in the direction of error, so there is hope to correct them. On the down side, the inferred index of these points forces them to be far from their true position.

This is an issue of poor indexing not being corrected. Is it time to bring out the big guns and try maximizing the index set w.r.t. the marginal likelihood? It seems like we've put this off long enough...

...

Imlemented, but slooooooow. Profiling shows the gradient calculation is the culprit, specifically, a dot product that is called once per dimension, per gradient evaluation. We should be able to replace that with a matrix multiplication to get a significant vectorization speedup.

...

Done, still slow. It looks like the gradient itself is pretty fast (~100ms) but the first iteration of Quasi-Newton takes several hundred evaluations (probably to build up a good estimate of the hessian). We should implement the hessian directly, which should be cheap using the cubic-time derivation, given the fact that we've already performed inversion. Need to write-up this derivation, then implement and test.

TODO (new)

Posted by Kyle Simek
blog comments powered by Disqus