Track Trails

[subdavis]

Screencast.2022-01-31.10.46.05.mp4

Summary of changes

• Change interpolated region color indicator to yellow for consistency between tail region and event view
• Generate tails on-the-fly (relatively) efficiently by using the track.features sparse array with slice() to extract the region of interest.
• Adds controls for selecting the before and after length, which will affect performance.

Questions

• The tail does not indicate empty regions within a track. Occlusion is not indicated by the line style. It can be done, but only if we think it's important. I didn't want a fully transparent line because then the track looks broken -- like it could be multiple tracks.
• Need to test this approach on a diverse group of datasets.

resolves #1114

[BryonLewis]

It looks and works very well, I think your questions are the things that need to be decided upon.

• I don't think missing frames and non-missing frames should be represented the same by the track, it injects information that really isn't there by auto interpolating without giving the user indication that is what's happening. The intentional interpolation works because that's a clear indication that there is something different about that section of the track as opposed to the rest of it. I played around with thickness changes and stuff like that before for missing detections but didn't have a great solution.
• This may be too noisy for high concentrations of tracks (a lot of tracks and track tails on the screen at once). I don't know if it's within scope to have a Visibility option which only provides the track tail on the selected track. It's something I implemented in the tracker tuner to reduce visual noise on certain datasets.

[subdavis]

From @mattdawkins

Looks cool
3:01
I'm not sure about the arrow though
3:02
I'd probably recommend the after trails be turned off by default, didn't have that original
3:02
but not sure
3:06
vpview also had a few more minor optimizations: an optional time (frame count in this case) threshold where it still showed the prior track trails on the screen after track end for t time to make it easier to see what should be linked, show full volume (shows all trails, probably mostly useless in this context but could show high level trends, in WAMI it was used for visualizations like making obvious roads stand out) - but neither of those are probably not as important here, maybe the first would help determining which tracks should be merged?
3:06
In terms of those two questions, not certain about clutter, maybe it would make sense when you're editing to show only the one being edited?
3:07
The main purpose are the trails are to aid with determining which tracks need to be merged, or more commonly identifying bad jumps between targets (often the tail becomes more eradic)

---