opencv: OpenCV3 python calls to FlannBasedMatcher::knnMatch fail with error

The following code returns an error.

    sift = x2d.SIFT_create(1000)
    features_l, des_l = sift.detectAndCompute(im_l, None)
    features_r, des_r = sift.detectAndCompute(im_r, None)

    FLANN_INDEX_KDTREE = 1
    index_params = dict(algorithm=FLANN_INDEX_KDTREE, trees=5)
    search_params = dict(checks=50)
    flann = cv2.FlannBasedMatcher(index_params,search_params)

The error returned:

opencv/modules/python/src2/cv2.cpp:161: error: (-215) The data should normally be NULL! in function allocate

I tried this with Python 2.7. FLANN_INDEX_KDTREE is set to 1 unlike here, since in modules/flann/include/opencv2/flann/defines.h I found it set to 1 on line 84.

About this issue

Original URL
State: closed
Created 9 years ago
Reactions: 13
Comments: 56 (16 by maintainers)

Commits related to this issue

fix issues with matcher related to open issue in OpenCV 3.1 with use of FLANN matcher (https://github.com/opencv/opencv/issues/5667) — committed to tobybreckon/python-examples-cv by tobybreckon 8 years ago

Most upvoted comments

still no official fix? 😦 Edit: cv2.ocl.setUseOpenCL(False) seems to work

+12

mpmX on Feb 23, 2017

Also seeing this with the ORB feature compute function @ c48d7f86b:

orb = cv2.ORB_create()
kp = orb.detect(image, None)
kp, des = orb.compute(image, kp)
...
error: (-215) The data should normally be NULL! in function allocate

moof2k on Dec 5, 2016

Yeah, earlier I was also facing the same issue but after installing opencv contrib it is working without any error pip install opencv-contrib-python

lavinachitara on Nov 29, 2017

This bug looks like it’s been around for a couple months.

I guess that does not bode well.

I’ll have to find that line of code and try commenting it out.

I guess that’s the downside of open source.

Is there a bug fix roadmap to see an estimated time to fix?

hmischel on Jan 13, 2016

I was not able to make OpenCV 3.3 work with my conda ENV. Some issues with Openblas etc.

So I tried my code on a new docker image with OpenCV 3.3. It worked fine. Thanks!

niyazpk on Sep 12, 2017

Actually, @Dikay900, 26d9a7c seems wrong to me, given the DescriptorMatcher::add logic. From what I can understand from browsing the source code, if you call getMatVector on an InputArray (which ultimately is what is passed to add via knnMatch), and then InputArray is actually of type MAT, then each column of the Matrix is added as an element to the vector. Whereas, if you call getMatVector and InputArray represents a STD_VECTOR_MAT then each element represents an entire Matrix, which seems more correct. Given the logic of the DescriptorMatcher::add, it seems that either a vector of Matrices or a single Matrix is expected, and thus you can’t just call getMatVector as is done in that commit. You need to do as I did in my gist, which replicates the logic from DescriptorMatcher::add.

patricksnape on Jan 23, 2016

@hmischel I’m just saying - don’t be surprised if you have a massive memory leak or something isn’t computing what you think it is! I think that the offending line is being hit because something weird is happening. I can’t replicate the issue for createBackgroundSubtractorMOG2, but I can replicate it for FlannBasedMatcher.

Something fishy is happening though - for example, the code passes if you do matches = flann.knnMatch(des1, 2) rather than matches = flann.knnMatch(des1, des2, 2).

My gut feeling is that something weird is happening with the bindings and the fact that knnMatch is overloaded is the problem. Perhaps passing the second argument, which in the C++ API could map to the output matches vector, is somehow getting interpreted as the output vector in Python (which is expected to be an empty array?).

patricksnape on Jan 22, 2016