Skip to content

feat(trackers): Implementation of Kalman Gating for DeepSORTTracker #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

soumik12345
Copy link
Collaborator

@soumik12345 soumik12345 commented Apr 20, 2025

Description

Implementation of Kalman motion gating described in Section 2.2 of the DeepSORT paper. This can be used to prune unlikely detection‐to‐track associations based on the predicted uncertainty of each track’s state.

@soumik12345 soumik12345 self-assigned this Apr 20, 2025
Copy link

@rolson24 rolson24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mahalanobis distance calculation looks good! I added a comment on the combined cost matrix. Also I was reading through the paper again and noticed an interesting section when they describe the matching cascade in section 2.3 and the pseudocode where they show the algorithm:
"
Therefore, we introduce a matching cascade that gives priority to more frequently seen objects to encode our notion of probability spread in the association likelihood. Listing 1 outlines our matching algorithm. As input we provide the set of track T and detection D indices as well as the maximum age $A_{max}$. In lines 1 and 2 we compute the association cost matrix and the matrix of admissible associations. We then iterate over track age n to solve a linear assignment problem for tracks of increasing age.
"

Which makes it sound like instead of just strictly sorting by lowest cost, the paper first sorts by time since last match (they call this track age) and then does matching for each set of track ages. So they would first calculate the cost matrix for tracks that were matched in the previous frame and do matching with the detections, then they would move onto the tracks that had been lost for one frame and calculate a new cost matrix with the leftover detections and do matching again and so on. I am not sure if we want to implement this, but I think that is what the paper says.
If we did implement it, I think the best way would be to change _get_associated_inds to loop over the different groups of tracks that have the same time_since_update and do the distance calculation and matching for each group. In each group of tracks, the tracks that don't get matched are marked lost, and the detections that don't get matched get sent onto the next older group of tracks to be matched.

@soumik12345 soumik12345 requested a review from SkalskiP April 22, 2025 14:03
Co-authored-by: Onuralp SEZER <thunderbirdtr@gmail.com>
@soumik12345 soumik12345 requested a review from onuralpszr April 22, 2025 14:17
@SkalskiP
Copy link
Collaborator

SkalskiP commented May 6, 2025

@soumik12345 As we agreed in Chicago, this PR is on hold until we’re able to measure the quality of the tracker output.

feat(trackers): implementation of gallery of features
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants