To continue tracking of objects even without detection information

[rose-jinyang]

Hello How are you? Thanks for contributing to this project. It seems that your method did NOT consider to continue tracking of objects even without detection information. In fact, a object detector always can not detect objects. In other words, there are cases that the object detector did not detect a certain object at a certain time.

But your code implementation assigns the tracking object ids to ONLY detected objects. I think that this logic is different from the logic of other previous tracking methods such as ByteTrack or BOTSort. Why do NOT handle tracking problem by putting focus to tracks?

[corfyi]

Thank you for your interest in our project and for bringing up this important point.

Your observation about the tracking logic in our implementation is insightful. In online tracking, our approach involves iterating over all tracks to output the tracking results, with a focus on the state of each track. We only output results for tracks that are in a 'confirmed' state to avoid false positives that might arise from tracks in a 'coasted' state. A track in the 'confirmed' state is invariably associated with a detection in the current update cycle.

Therefore, iterating over detections, as done in our code, is essentially equivalent to iterating over tracks in terms of the final tracking output. This equivalence in results has been validated on various datasets including MOT17, MOT20, DanceTrack, and KITTI. Our method ensures that only tracks that are actively associated with a detection (and thus 'confirmed') are considered, which aligns with the fundamental goal of reducing false positives and maintaining reliable tracking.

Additionally, I would like to point out that you can further examine the tracking result output logic in the run_ucmc.py file in our codebase. This part of the code iterates over all the tracks, and only those in a 'confirmed' state are eligible for result output. This approach is equivalent to iterating over all detections and ensuring that only those detections that have been successfully associated are outputted.

I encourage you to conduct experiments using the MOT17 validation dataset to see this in action. This will give you a clearer understanding of how our tracking logic functions in practice and how it aligns with the principle of maintaining accurate and reliable tracking, even in cases where object detection might be intermittent or inconsistent.

Experimenting on such datasets should help illustrate the effectiveness of our method and how it compares to other tracking methods you mentioned like ByteTrack or BOTSort. We believe in transparency and empirical validation, and thus, your hands-on experimentation with the code would be very valuable.

[rose-jinyang]

Thanks for your quick reply. But regrading to your logic, a certain object track without detection for a few seconds does NOT outputted as an object track. Is it normal? I think that even object tracks without detection at a certain time should be outputted as object tracks.

[corfyi]

Regarding the handling of object tracks that lack detection for a few seconds, it's true that in the current implementation of our tracking logic, these tracks might not be outputted as active object tracks during their 'undetected' state. This is a characteristic of the approach we've adopted for online tracking.

In contrast, mainstream online MOT algorithms, including ByteTrack, OCSORT, and BoTSORT, often employ offline post-processing techniques. These methods use interpolation strategies, such as linear or Gaussian interpolation, to fill in gaps for tracks that become 'confirmed' again after a period of no detection. In our research, specifically for the MOT17 dataset, we also used linear interpolation to address this issue.

However, for real-time or online tracking applications, these interpolation methods are not feasible. My demo represents an online tracking scenario where the focus is on processing data as it comes in real-time without the benefit of hindsight. In such scenarios, the absence of detections leads to a temporary pause in track output until the object is detected again and the track is confirmed.