matspetter's profile - activity

I have the same issue with a Nexus 5

When I try to use the VideoCapture native camera it doesn't initialize properly. In the logcat I see: "Cannot create OpenGL context".

This error (Cannot create OpenGL context) I also get when I for example create a Mat instance the first time:

Mat m = new Mat(500,500,anytype);

I have seen that the same (or very similar) problem has existed on Samsung Note and S4 etc so maybe this is the same thing!?

I'm running Android 4.4.2 and opencv 2.4.8 (have also tried 2.4.9).

Are there any possible work-arounds?

maybe you have some special reasons to compile yourself but there is a pre-compiled framework here: http://sourceforge.net/projects/opencvlibrary/files/opencv-ios/2.4.8/opencv2.framework.zip/download

which I think is compiled also for 64bit

I have also fiddled with this. I am now using this little script to build it:

set -x
clang++ -c -v *.cpp -Os -DWITH_TBB=ON -I /usr/local/include -I /usr/local/include/opencv -I /usr/local/include/opencv2

clang++ -v *.o -L /usr/local/lib -lopencv_highgui -lopencv_objdetect -lopencv_imgproc -lopencv_video -lopencv_features2d -lopencv_flann -lopencv_legacy -lopencv_ml -lopencv_core -o traincascadeLinux

goto the apps/traincascade folder and run the above. It will generate a "traincascadeLinux" executable.

Hello all. I have been using opencv_traincascade a lot. I know that it takes time to train, easilly several days or even a week. I (think) however that sometimes the training gets stuck and never ends.

I don't have the full picture of how the training really works in opencv_traincascade but after some analysis I have the feeling that the problem is in CvCascadeImageReader::NegReader::nextImg and/or in combination with CvCascadeClassifier::fillPassedSamples .

In CvCascadeImageReader::NegReader::nextImg it seems like there is no "protection" against that the variable "last" just loops around and around without ever finding whatever the code is looking for!!?? It will just pick the same images over and over again in this line: src = imread( imgFilenames[last++], 0 );

So the loop in CvCascadeClassifier::fillPassedSamples will call CvCascadeImageReader::NegReader::nextImg forever!!?? What will stop this loop if the predict(i) call in CvCascadeClassifier::fillPassedSamples never returns 1.0 ?

It would be nice if someone with a deep understanding of how the training works could explain the termination criteria in this case! :) Or maybe we have a bug here in the code!!??

Regards, Mats B

hmm this solution do parallelize a part of the code but unfortunately it doesnt seem to help much since the "nature" of that part is such that it doesn't help much, if anything at all :( So, back to the drawingboard...

I made an attempt to solve this by using parallel_for_ that seems to work. At the top of cascadeclassifier.cpp I added:

class Parallel_predict: public cv::ParallelLoopBody
{
private:
    const vector< Ptr<cvcascadeboost> >& v;
    int idx;
    int * result;

public:
    Parallel_predict(const vector< Ptr<cvcascadeboost> >& vectorToProcess, int i, int * r)
    : v(vectorToProcess), idx(i), result(r){ *result=1; }

    virtual void operator()( const cv::Range &r ) const {
        for (int i = r.start ; (i!=r.end)&&(*result==1) ; ++i)
        {
            if (v[i]->predict(idx)==.0f)
            {
                *result=0;
                return;
            }
        }
    }
};

Then, also in cascadeclassifier.cpp, I updated the int CvCascadeClassifier::predict( int sampleIdx ) method to look like this:

int CvCascadeClassifier::predict( int sampleIdx )
{
    CV_DbgAssert( sampleIdx < numPos + numNeg );

    int result;
    Parallel_predict p(stageClassifiers, sampleIdx, &result);
    cv::parallel_for_(cv::Range(0,(int)stageClassifiers.size()), p);
    return result;


    /* OLD CODE
    for (vector< Ptr<cvcascadeboost> >::iterator it = stageClassifiers.begin();
        it != stageClassifiers.end(); it++ )
    {
        if ( (*it)->predict( sampleIdx ) == 0.f )
            return 0;
    }
    return 1;*/
}

I have only tried this on OSX. It seems to work alright and it for sure use all of my cores :) There are however more code that could be paralellized (like in fillPassedSamples) but those are not very obvious how to attack.

/MB