New feature: real-time multiple object tracking based DLC mode - #534
New feature: real-time multiple object tracking based DLC mode#534ehsainit wants to merge 9 commits into
Conversation
|
@ehsainit thanks for your PR. We will not accept code additions that do not conform to the headers/open-source nature of the code, ie.. files that say: need to be edited, thanks! We also ask you provide a description, and why this is a useful feature for the DLC codebase. i.e.: https://github.com/AlexEMG/DeepLabCut/blob/master/docs/contribute.md |
| # [DEMO the code](/examples) | ||
|
|
||
| We provide several Jupyter Notebooks: one that walks you through a demo dataset to test your installation, and another Notebook to run DeepLabCut from the beginning on your own data. We also show you how to use the code in Docker, and on Google Colab. | ||
| # Update: DeepLabCut with new feature: Real-Time MOT tracking |
There was a problem hiding this comment.
remove from readme.md -> would go into release note, and docs for use.
Hi @MMathisLab - thanks for the reply ! i sent to you a document with detailed description of this addition a while back. |
|
Hi @ehsainit yep! But given this is in the public domain now, I think it would be good to document this here, and specifically point to the code edits, etc. |
|
@MMathisLab , Got it ! i will do so in the upcoming days. |
|
Hi @MMathisLab @AlexEMG, |
|
Hi @ehsainit |
|
Hi @MarineChap Thanks for your interest in the feature, sure feel free to use. Note: the size of the bounding boxes might be to small, you might need to make it bigger |
|
Nice ! @ehsainit, First of all, it is unclear how to run it. ;)
|
| [scmap[maxloc][joint_idx]]))) | ||
| return np.array(pose) | ||
|
|
||
|
|
There was a problem hiding this comment.
This function is defined twice --> See two methods below
There was a problem hiding this comment.
The is intended as I suggested before I still don't know how this feature will be integrated into the DLC. For your testing purposes use https://github.com/ehsainit/DeepLabCut/blob/c34b849999a497f81675f9c27ef4d212e71c7183/deeplabcut/pose_estimation_tensorflow/nnet/predict.py#L78
@MarineChap you are right that is because it is still unclear how this feature should be integrated in the DLC. But yeah for the initial purposes i ran it using the main.py class as you guessed
|
|
Hello ! My video is a rodent with 2 leds on the head running in a maze. The model is trained to detect these two LEDs. I changed the threshold in extract_localmaxima for 0.1. Does it something you were expecting to change following the type of application ? Some remarks :
Have a good day ! |
Hey @MarineChap , Thanks for your feedback. I remember testing the model on CPU and i was really slow mainly in inference of DLC1 stage. However in GPU mode it was quick fast, did you run it using the GPU ? I still not convinced of the way I'm extracting the local maxima from the score-maps but this method achieved the best results on the tested videos, i did expect this, yet it is surprising that you change it to 0.1(too low). My guess is that you defined more than one label and the wrong label is extracted ? About the 3D errors could you should you error code ? Thanks ! |
I am having this error mainly because possible_objects = [slice(...), slice(...), slice(...)] and not what I am guessing it was for you possible_objects = [slice(...), slice(...)] Also, indeed, you are right. As I am confined at my home, I am using an old model where I have 4 labels (2 useless which are computing nothing) instead of 2. What I don't understand is why it would cause a problem? Also because I am stuck at home, I have only my laptop so no GPU. But, from my point of view, a tracking should be able to work without a huge requirement of computation. People won't use it if they need others stuffs than there usual computer. It is not like offline computation which can be send in a cluster easily. But it is only my opinion. So... @MMathisLab what do you think on this subject ? A problem or not a problem the need of GPU for real-time tracking? |
|
I think for best tracking performance utilizing GPUs is important. That being said, one can do this inexpensively, and indeed we will release information how to do this soon. I think this code is not sounding as flexible as one needs, but I’ll need to re-evaluate once our roadmap (see docs) items are out. |
@MarineChap well, this error is caused by the score-map structure. When tracking one type of object you don't need multiple labels. the score-map that is extracted from network include 4 "probability tables" one for each label, in our case you need just one. Do you still remember which color did you use to label the images ? if so just add those two lines of code I agree with @MMathisLab on the GPU part. The heavy computational was mostly because of the network computation. @MMathisLab i think the code is flexible but still not integrated in DLC, I assumed that there will be an option in the GUI later on for training for the purpose of real-time tracking (using only one label). |
|
This will be integrated with DLC 2.2 with a new PR. Closing this thread here. |
Goal & workflow
The goal is to extend DLC to support real-time multiple object tracking. For simplicity and efficiency, a traditional tracking by detection approach was introduced.
The DLC network detects a scale of high probabilities representing animals or look-alike objects, which allows modeling the score-map as a function with multiple local maxima.
Afterwards, candidates detections will be collected from the score-maps, all of the candidates will be assigned as new births , each having a unique identity, Kalman filter instance initialized with the first detection , a constant signifying the amount of skipped frames because of no available detection and a unique color. After that, the detection-track-association problem is solved using the Hungarian algorithm. Only motion-information (Mahalanobis distance) is used.
Next, the tracks will be maintained and updated using the matched detection, only if their motion metric value is reasonable (e.g. not too high), otherwise, they will be re-assigned. Detections with no existing tracks will be assigned as births.
Finally the matched tracks Kalman filter instances will be updated using their correspondent's detection. To deal with the unmatched tracks, we keep track using the a priori information that their Kalman filter instances hold. If they remain unmatched up tp certain number of frames they will be assigned as deaths.
Note: This was done in the course of my studies as a Bachelor's project in the Straw Lab at the University of Freiburg. The Straw Lab is interested in real-time flies tracking , so the cost metric & other stuff were specifically chosen with the regard to the input.
Glossary:
Steps:
At time step t, for a processed frame:
Evaluation Results
This feature was evaluated using 1, 3 and 10 flies offline due to lack of time (back then),
Videos proprieties :
Here are some of the results:
Trajectories plots of tracking process on one fly. The 4 subplots diagrams demonstrate the accuracy performs of Kalman filter prediction against the DLC1 detectors .while the top two subplots illustrate the detectors performance over 40 second video, the other two subplots shows how accurate the Kalman filtering was.
This figure demonstrate a trajectories comparison between the predictions (orange line) and the DLC1 detection (blue line) over 20 seconds video of 3 flies. Here we can see the x, y trajectories of one fly,
Illustration of the prediction performance of the Kalman filter upon missing measurements over a 10 frames sequence.
Here we can see the time complexity of the framework. the x-axis represent the time in second and the y-axis the number of tracked objects.
In Action
Notes
The Kalman filter is a constant velocity model
Evaluation was done using only the initial input videos (See picture in header)
This feature merely tested on DLC2, as it was developed under DLC1
ToDos
More Testing, Evaluation on real-time cameras with different fps rates
Evaluation on different videos @AlexEMG
Better local maxima extraction - more reliable method
The Math for the transition noise covariance matrix of the Kalman filter is wrong, must be corrected