10
$\begingroup$

I am currently working with and comparing the performance of several feature detectors provided by OpenCV as basis for visual feature matching.

I am using SIFT descriptors. I have accomplished satisfactory matching (after rejecting bad matches) when detecting MSER and DoG (SIFT) features.

Currently, I am testing my code with GFTT (Good Features to Track - Harris corners) to get a comparison, and also because in the final aplication, a set of GFTT features will be available from visual feature tracking process.

I am using cv::FeatureDetector::detect(...) which provides me with a std::vector<cv::KeyPoint> filled with detected features / keypoints / regions of interest. The structure cv::KeyPoint contains basic information about feature's location, as well as information about size and octave in which the keypoint has been detected.

My first results with GFTT were terrible until I compared the typical size and octave parameters in different types of features:

  • MSER sets the size (between 10 and 40px) and leaves the octave to 0
  • DoG (SIFT) sets both the size and the octave (size/octave ratio between 20 and 40)
  • GFTT the parameters are always: size = 3, octave = 0

I presume that is because the primary purpose of GFTT features was not to be used in matching but only in tracking. This explains the low quality of matching results, since the descriptors extracted from such tiny features stop being discriminatory and invariant to many things, including small, 1-pixel shifts.

If I manually set the size of GFTT to 10 - 12, I get good results, very similar to when using MSER or DoG (SIFT).

My question is: is there a better way to determine how much to increase the size (and/or octave) than just-go-with-10-see-if-it-works? I want to avoid hardcoding the size increase if possible and determine it programmatically, but hardcoding is okay as long as I have some solid arguments backing up my choices of the new size / size increase / size estimation algorithm.

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ Hey@penelope: check out this link this guy already done some good work.[computer-vision-talks.com/2011/08/… $\endgroup$
    – Sistu
    Jun 14, 2012 at 10:39
  • $\begingroup$ @Sistu hey that looks like a very good general comparisons of descriptors in a general case, and with a planar object, but I am working on specific kinds of images and I need to do my own test. Besides, the question was much more specific than "I need reference materials comparing the performance of various types of decriptors". It is a nice link though, will check it out. $\endgroup$
    – penelope
    Jun 14, 2012 at 11:44

2 Answers 2

Reset to default
4
$\begingroup$

I'm not sure there is actually a good response to your precise question : the scale-space thing of SIFT and SURF was actually developed to automatically estimate the "good" relevant neighborhood size around a corner-like keypoint (which is what good features to track are).

Now, more positive answers would be:

  • build a database of keypoints and good matches (e.g. using square calibration patterns) and create an automated performance assessment on this database to find the correct size. This task can actually really be automated (see the work by Mikolajczyk and Schmid about point matching evaluation)

  • embed your good features in an image pyramid to also have some kind of scale associated with them. You can look for references on multi-scale FAST and Harris interest points, that do something very similar to this procedure.

To heuristically find the maximum block size, you can compute estimates of your images with a box blur (which is more or less what the blockSize operator does) and see when the corner disappears. Note however that more blur takes the corner away from its true location.

If you're really looking for some quick-and-dirty fix, try sizes between 5x5 and 11x11 (typical sizes used in stereo block matching). If you're looking for an intellectually satisfying criterion, then try to maximize the likelihood of good matching of two feature points under your noise level.

Improve this answer
$\endgroup$
1
  • $\begingroup$ I was looking for a solution that was a little bit more quick-and-dirty that what you propose. Also, I can only determine weather a match is a good one or a bad one after I get my keypoints extracted and matched to something. Even if I match them totally randomly I get some good matches -- so your first suggestion not that helpful. As for the second part, more quick-and-dirty: I know there is no perfect parameter, but as I said, increasing the size to 12 helped - the quality was comparable to SIFT and MSER matching. I just have no argument whatsoever to pick 12 over a 100 or over 34... $\endgroup$
    – penelope
    May 9, 2012 at 9:47
0
$\begingroup$

To help you determine the best parameters for the detectors, OpenCV has the AjusterAdapter for that purpose. I never used it myself but it is probably the standard way to programatically determine the parameters. Also be aware that although Keypoints have several properties, not all make sense to all algorithms. Because the Keypoint structure is used for diferent algorithms, it has all those fields but sometimes they are not used, that's why you get those octave = 0; IMO.

Improve this answer
$\endgroup$
2
  • $\begingroup$ I know that some types of features are not the best type for some purpose sometimes, but recent works have been trying approaches where they use more than 1 type of v.features/interest regions and achieve better results with the combination than with any single type on it's own (I can add links to works if you're interested). Also, what I'm doing is at least part research, so trying out and evaluating results achieved with different keypoint types is what I'm supposed to do, even if some of those results are not as good as state-of-the-art. I'll look into AdjusterAdapter, thank you. $\endgroup$
    – penelope
    Jun 14, 2012 at 7:16
  • $\begingroup$ I just looked through the function the interface provides. It can only increase or decrease the number of features the detector detects. Besides, I don't have any problems with features that are detected. I would just like a way to adjust their size so they could be better used in matching (increasing the size to 10 does that, but I don't have any concrete (enough) argumentation for that choice) $\endgroup$
    – penelope
    Jun 14, 2012 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.