Pedestrian detection - strategies for eliminating false positives

edit

Finally, I did indeed implement Track Before Detection. This has improved things, but only somewhat.

The problem is that:

• With the OpenCV DefaultPeopleDetector, sometimes there are things that randomly get detected as a person (ex the vertical portion of a frame).
• When this happens, even the weight assigned to the detection (returned from detectMultiScale) could be very high
• Sometimes, the same erroneous detection will take place over several frames, tricking the Track Before Detection code into thinking it's real.

It's puzzling because for 90% of the frames, that same erroneous detection won't occur, but then sometimes it occurs in bursts of frames with high weight. I guess this shouldn't be too surprising due to changing lighting conditions, etc, but still seems weird.

Another refinement you can add is that new tracks only appear at the edges of your image. I don't know if that's true, but for many cases, it is. Alternatively, new tracks are always moving, so if the motion is small (because it's a false alarm) then it gets ignored.

I still feel like the, ultimately, the body detection will need to be improved over the DefaultPeopleDetector, but your suggestions are nevertheless worth implementing. Thanks again Tetragramm.

Does it? Because it doesn't even mention the integrated non-maxima supression algorithm, and thus several parameters are omitted. Moreover, it has incorrect info as "The size of the sliding window is fixed at 32 x 128 pixels, as suggested by the seminal Dalal and Triggs paper", and also, among others, it avoids explaining the cons of resizing the input image.

@LorenaGdL what's your opinion of the integrated NMS algo? I've seen several suggestions that it is not the way to go. You disagree?

@logidelic - I tend to use it and I've had no issues, as long as you know what you're doing of course. Surely there are more advanced algorithms, probably better than the integrated one, but since it is already there, why not try it first? Explaining the detectMultiScale function and skipping that part seems quite absurd to me, specially when the default input arguments do force an internal NMS (i.e. if the user do not change them, he's doing a NMS probably without notice).

Lorena, you should read the article in depth - of course the non-maxima supression is expressed in detail, also with code provided. Nevertheless I think the article can give some hints how to improve the results.

@JohannesZ the integrated NMS algorithm is not explained, but an alternative one. I'm not questioning the quality of such alternative, just saying that not all the parameters of the HOGDescriptor not mentioned (if I'm wrong, please correct me and point me to where the finalThreshold and useMeanShifGrouping params are explained), exactly those who might help in avoiding FPs. I agree, it gives some hints, but it also omits important information (e.g., as I said, it seems that resizing input image to a lower size is all pros, but it also has its unmentioned cons), and contains misinformation (more examples: "The detectMultiScale method constructs [...] a sliding window step size of (4, 4)" -> false; if winStride is omitted, winStride = blockStride (whose default is 8,8) )