kwiver
kwiver copied to clipboard
Use vital track types instead of custom one in srnn_tracker
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_trackerneeds to store data specific to its use case in the track states. I believe enabling this would require makingkwiver.vital.types.TrackStatesubclassable. - At the track level, the tracker performs operations like getting the n most recent track states. Perhaps a
get_most_recentfunction could be added tokwiver::vital::track, but it would at least be helpful to define__reversed__forkwiver.vital.types.Track, since thenlist(itertools.islice(reversed(track), n))[::-1]achieves something similar. - At the track set level,
srnn_trackeruses a configuration-dependent notion of track activity that differs from the vital type's. I'm not sure this functionality is worth adding tokwiver::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 Pythonset).
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.