False positives and misses

[R0flcopt3r]

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

[abewley]

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

On Fri, 26 Feb. 2021, 16:25 R0flcopt3r, [email protected] 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]

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]

Also interested in this!

[youonlytrackonce]

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]

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]

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.