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
octave in which the keypoint has been detected.
My first results with GFTT were terrible until I compared the typical
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
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 increase /
size estimation algorithm.