Understanding ByteTrack in yolov11

[ykn96]

Hello! I see that bytetrack is being implemented in the ultralytics library and i wish to get a better understanding of it In the ultralytics library, i see that there is a bytetrack.yaml file which contains

# Ultralytics 🚀 AGPL-3.0 License - https://ultralytics.com/license

# Default Ultralytics settings for ByteTrack tracker when using mode="track"
# For documentation and examples see https://docs.ultralytics.com/modes/track/
# For ByteTrack source code see https://github.com/ifzhang/ByteTrack

tracker_type: bytetrack # tracker type, ['botsort', 'bytetrack']
track_high_thresh: 0.25 # threshold for the first association
track_low_thresh: 0.1 # threshold for the second association
new_track_thresh: 0.25 # threshold for init new track if the detection does not match any tracks
track_buffer: 30 # buffer to calculate the time when to remove tracks
match_thresh: 0.8 # threshold for matching tracks
fuse_score: True # Whether to fuse confidence scores with the iou distances before matching
# min_box_area: 10  # threshold for min box areas(for tracker evaluation, not used for now)

May i know What do the values track_high_thresh and track_low_thresh and new_track_thresh and match_thresh mean? and how are these values computed?

[roxlu]

I've been digging into the C++ implementation, which uses similar thresholds.

From what I understand, track_low_thresh and track_high_thresh refer to detection scores, that is, how confident the system is about a detection. These thresholds are used to split detections into two groups: one with low confidence and one with high confidence. The high-confidence detections are matched first with existing tracks.

After this initial high-score matching phase, any remaining unmatched tracks are then matched against the lower-confidence detections. This gives those detections a second chance to be associated with existing tracks.

At the end of the matching process, the system checks if there are still any high-confidence detections left that didn’t match with any track. If there are, it assumes these might be new objects and creates new tracks for them.

Now, the match_thresh value is a bit different—it's not related to detection confidence. Instead, it's a cost threshold used during the linear assignment step, which is solved using the Jonker-Volgenant algorithm. This part relies on IoU (Intersection over Union) scores to determine how well a detection overlaps with a track.

Here’s the catch: normally, an IoU of 1.0 means perfect overlap, and 0.0 means no overlap. But the assignment algorithm looks for the lowest cost matches, where 0.0 means no cost and higher values mean worse matches. So to use IoU directly as a cost, they invert the values using 1.0 - iou_score.

So, for example, if match_thresh is set to 0.8, that means any pair with less than 20% overlap will not be matched. But even a small overlap, like 21%, would still be considered a valid match.