problem with haarcascade_frontalface_alt.xml in new version of javacv

373 views
Skip to first unread message

v.f.b...@gmail.com

unread,
Sep 20, 2015, 6:43:50 AM9/20/15
to javacv
Hi,

I've been working through updating my code to work with the latest javacv, but hit a strange problem. Performance really dropped off, with laggy/slow video feed. After going through my code to figure out where, its happening when I call face detection if there has been movement detected in the frame:

faces = cvHaarDetectObjects(originalImage, cascade, faceStorage, 1.1, 3, CV_HAAR_DO_CANNY_PRUNING);

I looked through the examples, and I can see FaceApplet and FacePreview use this, but aimed for Android. So I don't know if I need to downsize the image first like in these examples, but I'd rather avoid that as I'm already dealing with a small resolution.

So then I thought, aha maybe the haarcascade_frontalface_alt.xml has been updated between openCV 2.X to 3, and it looks like it has. But if I copy in a new one, I get:

     [java] OpenCV Error: Unspecified error (The node does not represent a user object (unknown type?)) in cvRead, file /home/vin/javacpp-presets/opencv/cppbuild/linux-x86_64/opencv-3.0.0/modules/core/src/persistence.cpp, line 4976
     [java] Exception in thread "main" java.lang.RuntimeException: /home/vin/javacpp-presets/opencv/cppbuild/linux-x86_64/opencv-3.0.0/modules/core/src/persistence.cpp:4976: error: (-2) The node does not represent a user object (unknown type?) in function cvRead

Now, I know the general setup must be OK, as I just overwrite the previous file. Looking at start of the xml, in the new one (copied out of opencv, opencv/cppbuild/linux-x86_64/share/OpenCV/haarcascades/haarcascade_frontalface_alt.xml)

<opencv_storage>
<cascade type_id="opencv-cascade-classifier"><stageType>BOOST</stageType>
  <featureType>HAAR</featureType>
  <height>20</height>
  <width>20</width>
  <stageParams>
    <maxWeakCount>213</maxWeakCount></stageParams>
  <featureParams>
    <maxCatCount>0</maxCatCount></featureParams>
  <stageNum>22</stageNum>
  <stages>
..... (lots more)

compared to the old one
<opencv_storage>
<haarcascade_frontalface_alt type_id="opencv-haar-classifier">
  <size>20 20</size>
  <stages>
    <_>
      <!-- stage 0 -->
      <trees>
        <_>
          <!-- tree 0 -->
.... (lots more)

I wondered if anyone else has hit either performance issues and figured out the problem, or if it is this classifier, somehow it loads the old one OK but its not as good performance as the latest one, so is there a way to get the new one loaded?

Thanks!

Samuel Audet

unread,
Sep 20, 2015, 9:50:23 AM9/20/15
to jav...@googlegroups.com
On 09/20/2015 07:43 PM, v.f.b...@gmail.com wrote:
> I wondered if anyone else has hit either performance issues and figured
> out the problem, or if it is this classifier, somehow it loads the old
> one OK but its not as good performance as the latest one, so is there a
> way to get the new one loaded?

Yeah, I've noticed that at least the C API of the cascade classifier has
gotten a lot slower with version 3.0. Maybe we need to use the C++ API
to get good performance from now on? Let me know if you can confirm
this. Thanks!

Samuel

v.f.b...@gmail.com

unread,
Sep 20, 2015, 6:11:50 PM9/20/15
to javacv
By C++ API, do you mean something like:
cascade.detectMultiScale(originalImage, faceRect);

I tried this approach, and can load the 3.0 cascade file at least, and the detection works OK, but still just as slow. Trying switching to OpenCVFrameGrabber instead of FFmpegFrameGrabber, actually seemed a little less laggy on the OpenCV one but still pretty slow. Don't think its hardware as this is running on my laptop rather than the final target of the Pi. Is a bit of a showstopper for that device, its slow enough on the previous version with the better performance.

Was that the C++ approach you had in mind? Or any other pointers? Only other idea I had was to look through the openCV samples for something similar and check out the performance there.

Samuel Audet

unread,
Sep 21, 2015, 4:38:14 AM9/21/15
to javacv

Yes, that's what I meant by the C++ API. So I guess there's a bug in OpenCV 3.0. If someone else hasn't reported this upstream yet, I would recommend to do that first! Thanks

Samuel

--

---
You received this message because you are subscribed to the Google Groups "javacv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javacv+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Martin Deinhofer

unread,
Sep 21, 2015, 9:04:59 AM9/21/15
to javacv
Hi,

I have tried out the old haarcascade_frontalface_alt.xml file and the performance was quite the same both with javacv-0.10, opencv-2.4.10 and javacv-1.0, opencv-3.0.
I used the following detection parameters:

           CvSeq faces = cvHaarDetectObjects(grayImage, classifier, storage,
                   1.2, 1, CV_HAAR_DO_ROUGH_SEARCH | CV_HAAR_FIND_BIGGEST_OBJECT,cvSize(80,80),cvSize(0, 0));

But I recognized much worse webcam support with opencv-3.0 frame grabber. My internal camera just shows black frames and my externally attached LogiLink USB-camera can't be captured either. But both work with the VideoInputFrameGrabber. With opencv 2.4.10 both cameras worked fine as well.

Martin 

v.f.b...@gmail.com

unread,
Sep 21, 2015, 3:18:43 PM9/21/15
to javacv
Thanks for the follow up, has helped me find a solution.

If I use the old classifier, infact pretty much all the old code I had, performance is OK so long as I change
CV_HAAR_DO_CANNY_PRUNING
to
CV_HAAR_FIND_BIGGEST_OBJECT | CV_HAAR_DO_ROUGH_SEARCH

Which was unexpected! I guess something has changed in those approaches in the newer openCV 3. So now I'm back to:
faces = cvHaarDetectObjects(greyImgIpl, cascade_old, faceStorage, 1.2, 3, CV_HAAR_DO_ROUGH_SEARCH | CV_HAAR_FIND_BIGGEST_OBJECT);

Unfortunately, in same block of code, the alternative is definitely still slow to the point of being unusable.
cascade.detectMultiScale(greyMat, faceRect, 1.2, 3, CV_HAAR_FIND_BIGGEST_OBJECT | CV_HAAR_DO_ROUGH_SEARCH, new Size(), new Size(greyMat.cols(), greyMat.rows()));

So, there's a workable option there at least.
Reply all
Reply to author
Forward
0 new messages