Add minimum_consecutive_frames argument to ByteTrack

[rolson24]

Description

This PR fixes #1044. I decided to implement this by keeping the base ByteTrack algorithm the same, but changing when a track gets assigned a new track_id, and only returning tracks that have valid track_ids (>= 0). This change also resets the track_id counter when a new ByteTrack object is initialized.

fix bug from PR #1035

change update_with_tensors to not return tracks with track_id < 0

reset the track_id counter when initializing a new ByteTrack object

List any dependencies that are required for this change.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How has this change been tested, please provide a testcase or example of how you tested the change?

I tested this by running ByteTrack with multiple different values of minimum_consecutive_frames and looking at the output video to see if the short, low-quality tracks were removed. In this colab notebook, you can run the video at both minimum_consecutive_frames = 1 and 5 and compare the two output videos. You can also observe the maximum track_id in every frame to see that the tracker with a minimum_consecutive_frames value of 5 has much lower values indicating that there are fewer valid tracks. The number of valid tracks is also more stable.

Any specific deployment considerations

This might require updating the documentation for ByteTrack, which I am willing to do if this is approved.

Docs

• Docs updated?

[SkalskiP]

Hi @rolson24 👋🏻 Looks like there are some unresolved conflicts. Could you take care of this?

[rolson24]

Yes. I need to do some more testing before it gets merged though.

[rolson24]

This most recent commit fixes this issue: (#1049 (comment))

If all of the detections in a frame have low confidence, then the tracker will still return these detections, but with an empty tracker_id array. This causes issues when you try to get the track_id of one of these detections (for example, using the trace_annotator). I have fixed this by simply returning empty detections with a tracker_id array of length 0. This is the behavior of the original update_with_detections() function.

I have tested this change by creating unit tests that cover all of the possible cases for detection inputs. See this colab notebook.

[SkalskiP]

Hi @rolson24 👋🏻 is this ready for testing and review?

[rolson24]

Yes.

…

On Fri, Mar 29, 2024 at 8:34 AM Piotr Skalski ***@***.***> wrote: Hi @rolson24 <https://github.com/rolson24> 👋🏻 is this ready for testing and review? — Reply to this email directly, view it on GitHub <#1050 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AX2EJPA6XNH52GKDREVOF2TY2VGVDAVCNFSM6AAAAABFIDOROSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXGE4DINBYHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rolson24]

After further testing, the whole idea of using track_ids to signify whether a track is valid or not will not work. This is because joint_stracks and sub_stracks rely on track_ids to prevent duplicate tracks from being in the lists. Right now this issue is causing only one track to be initialized in each frame. We would either have to modify those functions, or instead (probably better) only mark tracks that have existed for at least minimum_consecutive_frames as being "activated". This will allow them to keep unique track_id's and also allow us to easily filter out tracks that are valid. I can implement this and test it, before submitting a new PR