[Realization: Current likelihood permits bad candidates] Work Log
Thought more on split/merge. Could make merge a special case of split, and the move becomes a split/split process. At every step, pick a track, pick a subset of observations from that track, then reassign them all to an existing curve or a new curve. It's symmetric, which is nice, but the probability of a merge being selected becomes vanishingly small very quickly.
Looking into issues with offline pair-candidate generation. So many bad candidates are coming up, and their ML values look better than the good candidates.
A big issue is that we aren't penalizing missing data (gaps/tails), and we don't enforce multiple-view consistency (only two views need to match).
Option 1: use a stronger likelihood to rule out background curves. Use per-pixel foreground/background classifier? Use color consistency metric? Sample from posterior, project, check pixels, repeat -- gets a monte-carlo of marginal likelihood.
Option 2: use foreground/background classifier to classify fragments; misusing a background fragment in a foreground pair results in some penalty.
Option 1 is nice theoretically, but has lots of moving parts (new features, training, monte-carlo issue, need to know how thick to make branches.) Unlikely to get working in two weeks. Also isn't clear what the role of the detector curves are. Are they data? data-driven proposals?
Options 2 is a bit weird, but doesn't introduce dimensionality issues. But also doesn't specifically address the issue of bizzare candidates being introduced. For example, a bad pair could still be proposed as long as they're both foreground curves.
Posted by Kyle Simek