Pose Flow NMS

[lc4321]

Hi，according to your paper, the method of Pose Flow NMS is different from the conventional NMS method using frame-by-frame Pose-NMS. However, the code in your github means that the NMS process depends on frame-by-frame Pose-NMS. The code about the Pose flow building puzzled me also, could you help me .

[YuliangXiu]

The implementation of Pose Flow is very different from what described in the paper, this is a naive bipartial matching algorithm which can guarantee reasonable results.

[lc4321]

What's the meaning of bipartial? This words cann't be find in dictionaries.

[YuliangXiu]

sorry, bipartite matching.二分图匹配

[lc4321]

I have consulted some questions with my QQ email. Is it convenient for you to read and help me to solve the puzzles?3Q!

[lc4321]

In your tracker.py, I cann't find where '10 frames' is set to find the lost target. If there are 20 targets in the 1# frame and only 17 targets in the 2# frame, then how to deal with the remaining 3 targets without being matched in the 1# frame?

[YuliangXiu]

These 3 targets will be saved in a pool and then be used in the future matching. You can directly read my code, the matching logic is in utils.py file.

[lc4321]

Hi, whether the code of pose_flow which is consistent with paper "Pose Flow: Efficient Online Pose Tracking" will be released?

[lc4321]

There is a problem about the inter_frame pose distance according to the ORB matching method recommended in paper Pose_Flow: Efficient Online Pose Tracking. The size of bounding box surrounding keypoints is 10% person bounding box size according to the standard PCK. I always cann‘t extract feature points in the bounding box surrounding keypoints. Reason may be that the area of the box is small, resulting in the high consistency of all the pixesl in the box. However, when I increase the box area, many keypoints which are not in the same pose are exactly similar. How to deal with the ORB matching problem?

[YuliangXiu]

You can alter the matching feature from ORB to DeepMatching.

[sberryman]

I can confirm DeepMatching based tracking is working excellent! I had to shorten the link_len for my particular dataset but working great.

[lc4321]

Is the tracking based on DeepMatching a little slow？

[YuliangXiu]

Yes, a little slow, but it will guarantee better accuracy performance

[sberryman]

@Innerpeace90 The DeepMatching GPU version I was able to get around 25-30 per second with two GTX 1080 TI's and a GTX 1080.

[RomeroBarata]

Hi @sberryman, would that be possible for you to share the modifications you did to the tracker.py script to enable it to track a data set other than the PoseTrack? Thanks!

[sberryman]

@RomeroBarata I have an equally incompatible set of code now. I stepped through the tracking code line by line and pulled it apart. It turns out it isn't that complicated. You just need the deepmatching matches between the frames you are tracking, reshape the pose data a bit and finally use stack_all_pids and best_matching_hungarian from utils.py. I also used the GPU version of deepmatching as the CPU version was too slow for me.

If you have a specific question I can try and help but the code I rewrote would confuse you even more. Most of my changes are around pulling in pose data from MongoDB, deepmatching is calculated on demand and everything runs on a message bus (NATS.) I also wrote a lot of code to help visualize the tracking results and fix issues with the tracks (splitting, merging, etc.)

[RomeroBarata]

Thanks for your reply and tips @sberryman. I'll do the same and rewrite the script for my data sets. And in case I manage to make it general enough, I'll contribute it back to the repository :)