Ask Your Question


asked 2012-07-18 05:18:35 -0500

katrin gravatar image

updated 2012-07-24 06:31:27 -0500

Andrey Pavlenko gravatar image

I am playing around with the FREAK Descriptor Extractor to see if I could get faster runtime performance for my Android app. Previously I was using SURF Detector+Extractor. Since the nonfree package (which contains SURF) is excluded from the from OpenCV4Android 2.4.2 distribution I tried FAST instead of SURF (which was used in the FREAK demo code: for the descriptor extraction. I hoped that FAST+FREAK would be faster than SURF (especially since FAST is pretty fast with the drawback that it's not scale invariant). First tests however showed that my app has higher frame rates with SURF instead of FREAK. Is this known behavior or am I doing something wrong?

For FREAK I used the standard parameters, for SURF I used surf(500, 2, 2, false, false); (so 2 instead of 4 recommended octaves, 64-element descriptor instead of 124-element, computation of rotation - for rotational invariance). For SURF I used a FLANN Based Matcher (FlannBasedMatcher matcher(new flann::KDTreeIndexParams , new flann::SearchParams(8));), but for FREAK I'm only using a BFMatcher, since it's a binary descriptor.

What could be the reason for the slower performance of FREAK? Is it possible to use FLANN or some other non-bruteforce matcher for FREAK descriptors to get better runtime performance? I have also tried to convert the descriptors to float descriptors to use FLANN as presented above, but that did't give me any significant performance improvement and I guess it would not be a very good idea at all.

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted

answered 2012-07-20 03:26:07 -0500

Maria Dimashova gravatar image

Your experiment with a performance of SURF vs FREAK would be more fair if you measured them for a one descriptor. To get more information about their performance I would split the measuring the descriptors computing and descriptors matching. From your message the possible reasons of slowdown of your experiment can be the following: 1) FAST gives you more keypoints than SURF. 2) If you used FlannBasedMatcher for the SURF you may use it for the FREAK too, but with LshIndexParams. How to do this and why it doesn't work now you can find here

I expect that FREAK has to be faster than SURF (for a one keypoint) because it's a binary descriptor.

edit flag offensive delete link more


Thanks! The number of keypoints could definitley be a reason for the slowdown. I didn't check it. Thanks a lot for the LSH bug fix info, I've tried it before but it didn't work. I will give it a try as soon as I have time for it!

katrin gravatar imagekatrin ( 2012-07-20 06:11:09 -0500 )edit

answered 2012-07-23 03:36:56 -0500

Interesting. I recently made a small MEX interface for FREAK computation to simplify my frameworks that are mostly in MATLAB. I noticed a strange thing, when I plot a histogram of Hamming distances for FREAKs of two images, I get a nice Gaussian. Is there something wrong with the descriptor? Is it normal since I fear that my binary descriptors are just rubbish. I will post soon the code on my blog blog

edit flag offensive delete link more


UPDATE: I managed to extract the FREAKs for my images and some standard test images (Lowe's scene, box, basmati, book). After some analysis - binary clustering, visualization, matching - I noticed that there is a problem with this descriptor. It seems that there is some pattern but the descriptors are non-discriminant. E.g. clustering using Hamming distance gives one huge cluster and distance histogram is almost a nice Gaussian. May be I am using the descriptor incorrectly, but even running author's freak_demo.cpp on Lowe's test images, no meaningful matches are returned. Whereas SIFT returns nice correspondences from object to scene.

coppermine gravatar imagecoppermine ( 2012-07-27 08:45:09 -0500 )edit
Login/Signup to Answer

Question Tools



Asked: 2012-07-18 05:18:35 -0500

Seen: 7,385 times

Last updated: Jul 23 '12