kwiver icon indicating copy to clipboard operation
kwiver copied to clipboard

Use vital track types instead of custom one in srnn_tracker

Open predicative opened this issue 5 years ago • 0 comments

srnn_tracker (a.k.a. the TUT tracker), introduced by #691, internally maintains track-like data using the types in kwiver.sprokit.processes.pytorch.utils.track (link). It might simplify things if this functionality could be migrated to use kwiver.vital.types.Track etc. The functionality and use is slightly different, so at least changes like the following would be needed:

  • srnn_tracker needs to store data specific to its use case in the track states. I believe enabling this would require making kwiver.vital.types.TrackState subclassable.
  • At the track level, the tracker performs operations like getting the n most recent track states. Perhaps a get_most_recent function could be added to kwiver::vital::track, but it would at least be helpful to define __reversed__ for kwiver.vital.types.Track, since then list(itertools.islice(reversed(track), n))[::-1] achieves something similar.
  • At the track set level, srnn_tracker uses a configuration-dependent notion of track activity that differs from the vital type's. I'm not sure this functionality is worth adding to kwiver::vital::track_set, so it would make sense to use the vital type and then manage activity with a separate data structure (e.g. a Python set).

There are some other things that are, as I recall, related to not yet integrated code from the branch dev/tut-tracker-prr-20200716, which touches a lot of this code.

predicative avatar Sep 11 '20 16:09 predicative