Switching from BRISK to FREAK descriptor causes only wrong matches

asked 2013-09-09 19:31:08 -0500

a.francesconi gravatar image

updated 2013-09-09 20:06:41 -0500

I'm into a CV project where I need to extract some matched keypoints between two very similar images. Not a lot, "only" 20-30 for my purposes. So far I used the combination of two (three) algorithms:

1) BRISK to detect keypoints in both images

BRISK briskObj = BRISK(50, 0);
briskObj.detect(img1, keyp1);
briskObj.detect(img2, keyp2);

2) BRISK, again, to compute descriptors

briskObj.compute(img1, keyp1, descr1);
briskObj.compute(img2, keyp2, descr2);

3) BruteForceMatcher to match (then I filter by myself using the distance field)

BFMatcher matcher(NORM_HAMMING, true);
matcher.match(descr1, descr2, matches);
// ..... 
if (thisMatch.distance < 40) {
     filtered.push_back(thisMatch);
}

Result are REALLY good. I must quote BRISK as one of the best detector/descriptors because it produces several "perfect" matches. But it has a limit: its descriptor module is too much memory consuming for my needs (I want to port it on a device with not so much RAM).

For this, I decided to change only the second method with another lighter descriptor: FREAK.

FREAK freakObj = FREAK(true, true, 60);
freakObj.compute(img1, keyp1, descr1);
freakObj.compute(img2, keyp2, descr2);

The problem, now, is that none of the matched keypoints is right. Every match is far from the right position by 10-30 pixels (and this is because I've filtered them, otherwise it would be worse). I tried changing its parameters, like testing patternScale from 30 to 80, normalization booleans or my own filtering method. All of my matches are wrong...

So, how can I reach the performances of the BRISK descriptor with FREAK? I really need it because of its lightness

edit retag flag offensive close merge delete

Comments

1

Up to now (novice here) I've made similar experiences: the brisk descriptors are fantastic (if you take computation time into account too, it beats SIFT/SURF/et.al. any day), while I get only rubbish results with the FREAK descriptors; no matter what detector I use it with (trying to understand the paper and adjusting the parameters to my needs didn't help either... My guess is that FREAK easily fails with too small patternScale; yet that's what I need for my purposes, since larger patternScales result in too few detected keypoints while operating with rather small train images...).

The only tip I can offer: try to use the ORB-detector with the BRISK-extractor, which works really nice and yeah; the BRISK-detector seems to be bugged (or it's really one hell of a memory hog).

Lucky Luke gravatar imageLucky Luke ( 2013-09-09 20:40:45 -0500 )edit

Thank you for this, I'll try ORB. Anyway, what's a "small" and a "good" vale for a patternScale? Is 50 too low? About the excessive memory problem on BRISK, it's not a bug but it's caused by the allocation of a huge array of pattern points (it reach over 3.000.000 elements each one containing 3 float variables!). I could hack the source code by myself to see if there is a way to avoid this allocation, but right now I have no time ;)

a.francesconi gravatar imagea.francesconi ( 2013-09-10 03:36:03 -0500 )edit

Given a default patternScale of 22, 50 is certainly not too small (my remark about patternScale was really just a guess; as in shooting from the hips).

Maybe someone that actually had success with FREAK could offer some insight...

Lucky Luke gravatar imageLucky Luke ( 2013-09-10 06:33:25 -0500 )edit