18

I am using OpenCV 2.4.3 c++ interface to find matching points between two images. The first attempt was using SURF. The only problem is the consuming time, so I tried the new FREAK extractor. Using SURF for detection and FREAK for description, I realized that FREAK reduces the number of keypoints to almost half the detected, and the resulting matches were not enough. That is the reason, I tried FAST to obtain more keypoints. The results:

  1. SURF detector, SURF extractor, BFMatcher crosscheck true, RANSAC: 70keypoints first image, 50 keypoints second image, 200ms. 250ms. 15ms. 15ms.
  2. SURF detector, FREAK extractor, BFMatcher crosscheck true, RANSAC: 39 keypoints first image, 30 keypoints second image (after FREAK), 200ms., 50 ms. , 0ms., 0ms. It results that there too few good matchings.
  3. FAST detector, FREAK extractor, BFMatcher crosscheck true, RANSAC: 120 keypoints, 90 keypoints, (69 and 48 keypoints after FREAK), 10ms., 450 ms., 15 ms., 10 ms.

After that, I used ORBFeatureDetector, and it is obtaining the same number of keypoints than FAST, but after FREAK extractor, the resulting keypoints are 0 for each image. Am I doing something wrong? Are ORB keypoints different from those obtained from FAST? Maybe I could open another question for this, but I have last one. What could it be the best combination of detector/extractor to obtain the same results than my first experiments using SURF, but reducing the processing time? Because as I obtain more keypoints the extractor part is also more time consuming, although I use FREAK.

Alexis King
  • 43,109
  • 15
  • 131
  • 205
min.yong.yoon
  • 490
  • 4
  • 13

4 Answers4

12

FREAK removes points if it can not generate a descriptor for it, many times this occurs in the border of the image as it cannot generate a descriptor if it falls out of the boundary image. I avoid this issue by applying a ROI before extraction.

I also use FAST combined with FREAK and I get the best results, but I still have the problem of reducing extractor time, which is too high for me.

Jav_Rock
  • 22,059
  • 20
  • 123
  • 164
  • But the number of keypoints decrease for example from 800 to 84 in some cases. Is it not too much for borders? – min.yong.yoon Feb 07 '13 at 12:42
  • It depends on the size of keypoits, which is related to patternScale parameter. But yes, it is quite a lot. – Jav_Rock Feb 07 '13 at 14:00
  • Pfff. PatternScale. I am not able to understand this FREAK descriptor, nor is obtaining any good results. Thanks Jav – min.yong.yoon Feb 08 '13 at 09:14
  • Yes, patternScale is kind of tricky, I mailed the authors but still didn't answered. Anyway I get very good results, it is a matter of tuning parameters, tuning the matcher, etc, a bit complicated. There is few info and requieres some experience to success. – Jav_Rock Feb 08 '13 at 10:21
  • I will try it once more. One more question. Any clues about using kmeans to FREAK? I mean, to make a BOW vocabulary using Hamming distance? – min.yong.yoon Feb 11 '13 at 08:14
  • You said that you are avoiding the issue by applying ROI before extraction. Can you exactly tell what you are doing? I mean for example I need to extract features from all the keypoints that are found. How should I set ROI? – guneykayim Aug 15 '14 at 14:21
3

Actually, you used parameter cross check = true. this is also a reason why plenty of your points are eliminated. This parameter , when true, is expensive from a computationnal point of view. It is used to avoid pairs of descriptors that do not perfectly match during the matching process.

If you have two sets of descriptors D1 and D2, then, this parameters allows only pairs that are commonly match in the D1-> D2 and D2->D1 matching directions.

then, it all depends on your application, maybe you do not need that much matching precision...

Best regards.

Alex

Alex
  • 116
  • 4
3

Apart from the removal of border-points, as Jav_Rock suggests, the huge (inconsistent?!) decrease of points really depends on the size-parameter you stored in keyPoint. Even if you set scaleNormalized to false, with a float value for the size-parameter close to zero FREAK will just discard this keyPoint. (but I don't seem to be able to figure out why, as the size-parameter of the keyPoint is only used if scaleNormalized is true: source)

So be sure to set the size parameter to something bigger than zero (e.g. one) if you aren't using scaleNormalization.
And to interpert it as a value with the unit 'pixelsize' (when using scaleNormalization).
Btw. the minimum keypoint size is 7 by default.

Hope this helps...

Michael
  • 115
  • 1
  • 10
1

FAST is only a keypoint detector (no descriptor). If you combine FAST and use for description (multi-scale) BRIEF you will get ORB.

user2011909
  • 149
  • 1
  • 13
  • Maybe I did not explain clear. The problem is that after keypoints detection, I try to use FREAK for description, but this descriptor reduces the number of keypoints detected after description. Specially when I use ORB, the resulting keypoints after description are 0. Something I noticed debugging the resulting keypoints after FAST and ORB, is that using ORB, the response on each keypoint is a very small floating value. – min.yong.yoon Jan 28 '13 at 08:03
  • Please show us some code snippets. For me it works perfectly. – user2011909 Jan 31 '13 at 16:06
  • 1
    I am not able to reproduce the problem I had. – min.yong.yoon Feb 07 '13 at 12:34