[Work Log] Work Log
Fixed change-of-variable transformation for Hessian. OPtimization now finishes with fewer iterations and with higher likelihood solution.
Still getting weird overshoot curves:
It seems that our optimization occasionally causes large DC offset compared to the unoptimized indices. See below, blue is original, green is optimized.
On the other hand, some indices are much improved. Here's our always problematic curve #10, see how the large gap after the first two indices is removed.
The DC offset issue raises two questions: (1) why isn't offset of zero preferred, and (2) why does DC offset result in overshooting?
I think I know the answer to (2): we always start reconstructions at index zero. So if the evidence starts at index 10, the reconstrution will always draw the segment between index 0 and 10, even if there's no evidence.
Cached prior K is used in gradient computation; cache isn't updated when indices change.
...
On second look, I was wrong, cached K is updated in a call to att_set_start_index_2
I'll probably need to update children branch indices when parent indices change. Or only do index optimization in isolation.
Why is DC offset preferred? It's not an inference problem; confirmed that zero-offset indeed has a lower ML (not by much though).
It's clear that the curve is beneficting from extra freedom gained by starting at a higher index. The question is which parameter is encouraging this (smoothing, offset, rate)?
Lowering position variance below the optimal point reverses the trend, surprisingly. Increasing perturb position variance helps, but doesn't reverse.
Increasing rate variance past the optimal point reverses the trend, but the effect is not dramatic.
Increasing smoothing variance far past optimal shows a dramatic trend reversal.
Increasing rate variance makes position variance behave naturally -- zero offset is better for all values of position variance, with peak difference near the optimal. Correction: at very low position variance ( <= 5) the positive-offset model looks better, as we'd expect, since offset makes the model more forgiving.
Correction: increasing position variance is required for some curves.
Let's re-run with larger rate variance.
...
After increasing rate variance, indicies grow without bound! Eventually they get into the range of 4e6. Its our old friend, curve #10. This is very surprising, because the marginal likelihood should strongly discourage such large indices, since the number of poor configufations grows with index magnitude.
Could add a regulating factor, but it really seems like this shouldn't be necessary.
Fixed by simply returning -inf on failure. It seems this phenomenon is simply the result of an aggressive step in the wrong direction.
I'm starting to realize the allowing the indices to move freely can result in all kinds of subtle issues. For example, nothing prevents the spacing between indices from shrinking simultaneously, because the rate kernel is still happy (in fact, happier), the curve just appears to be moving more quickly. If the smoothing variance was set too high, this "quickening" makes the marginal likelihood happier, because points have less freedom to move in space -- the prior's slack is pulled out.
Something similar might be happening to cause indices to drift upward simultaneously.
Conclusion: Whatever the dynamics, index optimization might be a good idea to get a decent first-pass MAP reconstruction, but indices should be re-mapped using chord-length parameterization when computing ML's and final reconstructions.
For now, just subtract the excess, so first index is zero.
Reconstructions look better, but curve 7 still overshoots at the beginning:
Possibly relaxing ordering constraints between views will fix this.
Relaxing smoothness variance a small amount makes it worse. Arg...
OMG, plotting the 2D curve over the images shows significant offset!
hi resolution:
Notice curve #7 (dark green) is waaaay off on it's first point. What's going on here? I've re-traced that curve twice, is there some offset being added in opengl? Why haven't we seen the evidence of this before?
- check other views for offset error
- check other datasets for offset error
- quantify offset error (1 pixel?)
Looks like curves are shifted left by 0.5 pixels and down by 1.5 pixels. Part of the culprit is the flip_y function, which erroneously added 1 after flipping (presumably to account for the pixel grid). This brings it to within 0.5 in both directions. This is due to an ill-advised line I had added in the ground-truth tool, which translated everything by 0.5 pixels before rendering. I presumably wanted (0,0) to render in the middle of the bottom-left pixel, but in retrospect, this is stupid.
Added option 'halfPixelCorrection' for process_gt_2. Left half-pixel offset in ground-truth tool for now; with intent to fix all existing ground truth files and then remove the offending line of code.
Starting to get some real stairstep patterns in the index spacing. Almost certainly this means points from different views want to change order. Do this next
Posted by Kyle Simek