Ask Your Question

detectMultiscale fails when weights are requested

asked 2016-01-19 17:43:13 -0600

pixelou gravatar image

updated 2016-01-28 16:01:50 -0600


When weights and rejection levels are requested, detectMultiscale always returns a square at the center of the image, regardless of the image.

Minimal working example: (the image I used is available here)

#include <iostream>
#include <string>
#include <vector>
#include <opencv2/opencv.hpp>

using namespace std;
using namespace cv;

const string opencvDir = "/usr/share/opencv/haarcascades/";
const string WindowName = "Oscars";

int main() {
    CascadeClassifier faceCascade;
    if (!faceCascade.load(opencvDir + "/haarcascade_frontalface_alt2.xml")) {
        cerr << "failed to load cascade features" << endl;
        return -1;

    Mat im = imread("oscar.jpg");
    Mat gray(im.cols, im.rows, CV_8U);
    cvtColor(im, gray, cv::COLOR_BGR2GRAY);

    double scaleFactor = 1.2;
    int minNeighbors = 2;
    int flags = 0;
    Size minSize = Size(50, 50);
    Size maxSize = Size(150, 150);
    bool outputRejectLevels = true;
    vector<Rect> objects;
    vector<int> rejectLevels;
    std::vector<double> levelWeights;

    // Broken version
    faceCascade.detectMultiScale(gray, objects, rejectLevels, levelWeights,
        scaleFactor, minNeighbors, flags,
        minSize, maxSize, outputRejectLevels);

    Mat preview = im.clone();
    for (Rect obj : objects)
            rectangle(preview, obj, Scalar(255, 0, 0));

    namedWindow(WindowName, WINDOW_AUTOSIZE);   
    imshow(WindowName, preview);


    // Working version
    faceCascade.detectMultiScale(gray, objects, scaleFactor, minNeighbors, 
        flags, minSize, maxSize);

    preview = im.clone();
    for (Rect obj : objects)
            rectangle(preview, obj, Scalar(255, 0, 0));
    namedWindow(WindowName, WINDOW_AUTOSIZE);   
    imshow(WindowName, preview);

    return 0;    

The version of opencv I use is 3.1.0.r107.g1cd3c6f. It also failed with one of the earlier revisions. Could anyone just run the test above and confirm that there is indeed a bug?

EDIT: bug report opened here

edit retag flag offensive close merge delete


I was running the tests last week, and noticed very strange behaviour, but havent got the time for the moment to dig in. This behaviour was NOT there before, because I have used the functionality succesfully in the past. By the end of the week I might be able to do more tests and I will keep you up to date!

StevenPuttemans gravatar imageStevenPuttemans ( 2016-01-27 03:29:01 -0600 )edit

Thank you for your feedback. Just for the sake of clarity: by revision I meant earlier commit of the 3.1.0 version, not older version.

pixelou gravatar imagepixelou ( 2016-01-27 03:45:13 -0600 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2016-01-27 06:24:05 -0600

updated 2016-02-04 06:25:22 -0600

I can confirm that this is a problem. Given the following reduced code

#include <iostream>
#include "opencv2/opencv.hpp"

using namespace std;
using namespace cv;

int main()
    Mat image = imread("/home/spu/Desktop/faces.jpg");
    CascadeClassifier facemodel("/home/spu/Documents/github/opencv/data/lbpcascades/lbpcascade_frontalface.xml");

    Mat temp;
    cvtColor(image, temp, COLOR_BGR2GRAY);
    equalizeHist(temp, temp);
    vector<Rect> faces;
    vector<int> rejectLevels;
    vector<double> levelWeights;

    //facemodel.detectMultiScale( temp, faces, 1.1, 3 );

    facemodel.detectMultiScale(temp, faces, rejectLevels, levelWeights, 1.1, 3, 0, Size(), Size(), true);

    for( size_t i = 0; i < faces.size(); i++ )
        Point center( faces[i].x + faces[i].width*0.5, faces[i].y + faces[i].height*0.5 );
        ellipse( image, center, Size( faces[i].width*0.5, faces[i].height*0.5), 0, 0, 360, Scalar( 255, 0, 255 ), 4, 8, 0 );

    resize(image, image, Size(image.cols/2, image.rows/2));
    imshow("result", image); waitKey(0);

    cout << "Hello world!" << endl;
    return 0;

I notice that the standard BASIC option runs fast, and returns the following result


But the extended version keeps running for ages now ... it has been over multiple minutes ... and the end result is indeed wrong. So I am guessing something is terribly wrong with the backend, because a month ago when writing some book chapters, this functionality was working perfectly fine ...


I started to compare latest 2.4 and master branch

In 2.4 the normal code works as in master, and for the extended function the results are like below. We have more detections (must be a slight different implementation detail), but it does something usefull. Nevertheless I would expect equal parameters to generate equal output, which is not the case...

image description

I now took a clean master branch with same CMAKE configuration and will report back with the results.


Tried switching to HAAR model haarcascade_frontalface_alt.xml, because LBP is my preference, BUT same exists there. Works fine for basic version in 2.4 and master. But the extended version is again running endlessly ... not received a single result yet ...


It seems that an earlier fix to the standard interface broke down the extended function so we reverted the adaptation in a new PR:

Results are then like this

image description

edit flag offensive delete link more


Thank you very much for your feedback. I am going to file a bug report then.

pixelou gravatar imagepixelou ( 2016-01-27 13:34:59 -0600 )edit

Do link it to this topic. Also, I just checked if it was OpenCL related, but it is not, with or without OpenCL enabled it hangs endlessly on my end ...

StevenPuttemans gravatar imageStevenPuttemans ( 2016-01-28 04:00:03 -0600 )edit

Thank you for taking care of this bug.

pixelou gravatar imagepixelou ( 2016-02-05 01:53:24 -0600 )edit

You are welcome! Since this piece of software is critical to my research, I did not mind digging into it :)

StevenPuttemans gravatar imageStevenPuttemans ( 2016-02-05 03:34:35 -0600 )edit

Question Tools



Asked: 2016-01-19 17:43:13 -0600

Seen: 1,364 times

Last updated: Feb 04 '16