0
    Ptr<SIFT> detector = xfeatures2d::SIFT::create();

    vector<cv::KeyPoint> key_points_1, key_points_2;

    Mat dstImage1, dstImage2;
    detector->detectAndCompute(srcImage1, Mat(), key_points_1, dstImage1);

I want to extract a image sift feature; but when i run code above, there is a strange situation; key_points_1.size() != dstImage1.size(); as we all know, descriptor will create and compute by keypoints, so they should have same size. One time I have experience this situation, so I rebuild opencv and opencv_contribute, code will be ok; but after a few days, this bug show again, I am confused. detail: vector<keypoint>& keypoint; before run out of function detectAndCompute till '}', keypoint.size() = descriptor.size, it is ok; but when it go back the main function, keypoint.size() have changed.

WIN7 Visual studio 2017 opencv 3.4.1 opencv_contribute 3.4.1 detail: https://upload.cc/i1/2019/05/14/9Me5hT.jpg

keypoint1.size = 156 ,but descriptor1.size = 224
keypoint2.size = 143 ,but descriptor2.size = 205
EdChum
  • 376,765
  • 198
  • 813
  • 562
faithwang
  • 1
  • It sounds like memory corruption. Check your code for out-of-range memory use, especially assignments. – ALX23z May 14 '19 at 07:40
  • i think it happened because of memory corruption, but it is only easy initialization, i don't know how to avoid it ,can you give some suggestion about method?@ALX23z – faithwang May 14 '19 at 07:49
  • Having a _and_ in a function name is "code smell". Either `detectAndCompute` does really 2 things and should be decomposed, or it is a bad thinking of its behaviour so it should be renamed `computeOnDetection` or just `compute` since it is already a member a of "detector". – Sandburg May 14 '19 at 09:38
  • Problem with finding memory corruption is that the corruption might occur almost anywhere in the code. It is likely to be in a completely different part of the code - completely unrelated to the opencv code you write now. One method to find the corruption is to comment parts of your code and each time check if the corruption happens. Eventually narrowing down to the exact location. The only problem is how to reliably tell if the corruption happens or not... @faithwang – ALX23z May 14 '19 at 16:55
  • i debug step by step, i find that strange situation that keypoint change between in function of sift and out of function, detail like image in https://upload.cc/i1/2019/05/15/YZhKQU.png become to image in https://upload.cc/i1/2019/05/15/XMZY4w.png, and i find memory location of allocator don't change, but keypoint's size have changed, what happed?and i divide it to compute and detect two function, it is same. @Sandburg – faithwang May 15 '19 at 11:09
  • i delete other irrelevant code to find location memory corruption, but it is same, i don't know whether corruption happened.maybe not.@ALX23z – faithwang May 15 '19 at 11:13
  • I am sorry to make the mistakes, i found what i do to make it wrong, because i changed Keypoint struct to avoid other bug before, so when out of function, keypoint will read malposed memory, which make keypoint defferent. hope it can help others. – faithwang May 15 '19 at 12:09

0 Answers0