Refactor code according to proposed structure

[henriksod]

I have refactored the structure according to the proposal in the wiki and according to the discussion here.

I have removed TestRequirements, see this discussion why. If we want to keep it, I can reintroduce it.

I have not done the following:

Another thought is that we could easily create an abstract TrackingMethod class that all the trackers inherit from, that has the required interfaces defined. This won't change the functionality, but allows code to be re-used if needed. (see ocsort and strongsort)

[henriksod]

Ready to merge after review @mikel-brostrom

[mikel-brostrom]

Wow. This is huge. Give me a few days to go through it. But won't have time the coming 2-3 days.

[mikel-brostrom]

It is 🔥

[henriksod]

Fixed comments, ready to merge when you are ready :-)

[mikel-brostrom]

Maybe better to activate the default KF for each tracker. People compare the different methods in their papers. See this one for example: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10173520. Switching option should be added though to README 😄

[henriksod]

The KF implementation are almost identical when it comes to the actual calculations done. The only difference is the tuning, i.e. the noise and process covariance matrices. I have removed the KF implementation of strongsort, botsort, and bytetrack, and instead using the implementation of the kalman filter used by ocsort and deepocsort. This kalman filter is almost identical to the one implemented in filterpy. I propose to run an eval for each method and see if the metrics have changed compared to master, because in theory they shouldn't. :-)

[mikel-brostrom]

The only difference is the tuning, i.e. the noise and process covariance matrices.

Yup, mostly

I have removed the KF implementation of strongsort, botsort, and bytetrack, and instead using the implementation of the kalman filter used by ocsort and deepocsort

But are the old KFs activate'able somehow? We should push the good stuff, agreed, but if somebody wants to use the paper setup for academic purposes, specially now that we have a PR for ByteTrack's YOLOX people models it should be triggable IMO.

[henriksod]

What I am trying to say is that the behavior is the same. Keeping both KF implementations kind of removes the purpose of refactorization since they both implement the standard Kalman filter.

…

________________________________ From: Mike ***@***.***> Sent: Monday, July 10, 2023 11:16:05 PM To: mikel-brostrom/yolo_tracking ***@***.***> Cc: Henrik Söderlund ***@***.***>; Author ***@***.***> Subject: Re: [mikel-brostrom/yolo_tracking] Refactor code according to proposed structure (PR #986) I have removed the KF implementation of strongsort, botsort, and bytetrack, and instead using the implementation of the kalman filter used by ocsort and deepocsort But are the old KFs activate'able somehow? — Reply to this email directly, view it on GitHub<#986 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AHZJZIDPYYV42KD3EELS6FLXPRWJLANCNFSM6AAAAAA2DVAJII>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[henriksod]

Having both in requires an adapter for each Kalman filter, for each method...

[henriksod]

These changes should not change the performance of the trackers in any way. They should still perform the same as they did before.

[mikel-brostrom]

These changes should not change the performance of the trackers in any way. They should still perform the same as they did before.

Then let's get this merged 😄