Speed up or faster alternative to Opencv CascadeClassifier

asked 2016-11-07 03:58:43 -0600

P1t gravatar image

Hi, I use a cascade classifier from Opencv to detect some objects in real time (12801024px image) but It too slow for me. I use 20 stages cascade on 2020px patch with a scale factor of 1.1. I'm about 2.5FPS on an embedded computer. I would like about 10FPS.

Here is my questions :

Is there some well known bottlenecks in this part of Opencv that I could rapidly fix?

Is there some projects (github ...) to improve this part of Opencv?

Is there some libraries (open source or not) that have a faster implementation of Viola Jones detector (cascade classifier)?

edit retag flag offensive close merge delete

Comments

  1. How is your OpenCV configurated? Does your embedded platform support TBB or any other parallel framework?
  2. There is a small OpenCV community user group, including myself, constantly aiming at improving this part of the library.
  3. How do you run your classifier, because, related to your application, tons of speedups can be achieved by choosing the correct settings.
StevenPuttemans gravatar imageStevenPuttemans ( 2016-11-07 06:08:07 -0600 )edit
  1. TBB is activated. I modified some lines in the part of code to reduce the overhead time due to lock by it don't change a lot.
  2. That's interesting. Is there specific place where this community discuss about that? I work to understand this part of code and find bottleneck. I'm interesting to know on which way you are working and me give my help. (For example, do you know if there is some works to use natural optimization of haar features (resize feature not the image)...)
  3. I use haar features, not tilted, Gentle AdaBoost, hit rate 0.999, false alarm 0.5, other parameters are default.

.

P1t gravatar imageP1t ( 2016-11-07 09:36:31 -0600 )edit
  • I do not know of a specific place where we meet, but from time to time we have a discussion on the issues page at github. And I am closely working together to gets some bugs solved. If you got any ideas you can always get in contact with me.
  • Maybe start by effictively reducing your search space. Use minSize, maxSize, ... or by using preprocessing filters to mask out regions that do not need detections...
StevenPuttemans gravatar imageStevenPuttemans ( 2016-11-08 07:36:45 -0600 )edit

You can find my own TODO list here: https://github.com/StevenPuttemans/op.... Feel free to start any discussions there!

StevenPuttemans gravatar imageStevenPuttemans ( 2016-11-08 08:58:03 -0600 )edit

I have some ideas but most of those are not compatible with LBP or HOG detector (setImage once in detectmultiscale, update pointer in setwindow, scale feature during pointer updating ...). I'm not sure (I'm not sure to well understand ystep) but it seems that the detector run for each line. Is this necessary? 1/2 or 2/3 of overlap is not enough?

P1t gravatar imageP1t ( 2016-11-10 02:19:11 -0600 )edit

Thats because the implementation follows the initial idea. It moves per pixel yes, in a sliding window manner. Updating that could work, but it would have to be in an overload function or a completely new one, because we need to maintain backwards and ABI compatibility.

StevenPuttemans gravatar imageStevenPuttemans ( 2016-11-10 02:45:51 -0600 )edit

Ok, thank you for your answers. I will try some minor changes (parametric overlap, reduce lock of mutex) and I will come back to give you my results. If it's not enough and if I have enough time, I will try to change the haar cascade.

P1t gravatar imageP1t ( 2016-11-15 02:29:56 -0600 )edit
add a comment