search

abewley / sort

Simple, online, and realtime tracking of multiple objects in a video sequence.
GNU General Public License v3.0
3.92k stars 1.09k forks source link

False positives and misses #128

Open R0flcopt3r opened 3 years ago

R0flcopt3r commented 3 years ago

Is it safe to assume that unmatched_dets are equivalent with miss and unmatched_trks are equivalent with false_positive?

abewley commented 3 years ago

This is true only if you have replaced detections with the ground truth.

On Fri, 26 Feb. 2021, 16:25 R0flcopt3r, notifications@github.com wrote:

Is it safe to assume that unmatched_dets are equivalent with miss and unmatched_trks are equivalent with false_positive?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/abewley/sort/issues/128, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5YXK6Y7DOXNEH4AJIW3TDTA64QHANCNFSM4YIUBLCQ .

R0flcopt3r commented 3 years ago

Great!

Is there a way to specify the ground truth to SORT? Currently I'm comparing the bounding boxes I get back with the bounding boxes I send in, which has a ground truth. It's somewhat slow and can result in miss-match situations that isn't the fault of SORT.

jwscot commented 3 years ago

Also interested in this!

youonlytrackonce commented 2 years ago

Is it safe to assume that unmatched_dets are equivalent with miss and unmatched_trks are equivalent with false_positive?

unmatched tracks are not handled in the code. Why? There is no track management as described in the paper. Or am I missing something?

abewley commented 2 years ago

Prediction is called on all tracks matched and unmatched and I believe the track management you are referring to is on lines 248 to 250. Where if a track goes unmatched for too long it will be removed.

On Thu, Jul 21, 2022, 15:14 youonlytrackonce @.***> wrote:

Is it safe to assume that unmatched_dets are equivalent with miss and unmatched_trks are equivalent with false_positive?

unmatched tracks are not handled in the code. Why? There is no track management as described in the paper. Or am I missing something?

— Reply to this email directly, view it on GitHub https://github.com/abewley/sort/issues/128#issuecomment-1191470579, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5YXKZXHO4GRUBVHHX2RGTVVFEKNANCNFSM4YIUBLCQ . You are receiving this because you commented.Message ID: @.***>

youonlytrackonce commented 2 years ago

Prediction is called on all tracks matched and unmatched and I believe the track management you are referring to is on lines 248 to 250. Where if a track goes unmatched for too long it will be removed. … On Thu, Jul 21, 2022, 15:14 youonlytrackonce @.> wrote: Is it safe to assume that unmatched_dets are equivalent with miss and unmatched_trks are equivalent with false_positive? unmatched tracks are not handled in the code. Why? There is no track management as described in the paper. Or am I missing something? — Reply to this email directly, view it on GitHub <#128 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5YXKZXHO4GRUBVHHX2RGTVVFEKNANCNFSM4YIUBLCQ . You are receiving this because you commented.Message ID: @.>

I cannot find prediction call for unmatched tracks on the code (if detector cannot detect the track, track should be updated according to previous prediction ). My assumption is that "unmatched detection" is a new object that just comes into the frame and unmatched track is that detector cannot detect existing track. The function "associate_detections_to_trackers" returns "unmatched_trks" but this variable is not used.