# Does using FLANN-Matcher for every frame make sense?

I want to track interesting points in the video view. Due to performance reasons, I picked ORB as feature detector and feature descriptor that gives me 500 points each frame.

Now when it comes to the matching part, I only need a few correspondences (>7 for homography), so an approximate nearest neighbor search is fine.

My first question is: Should I use FLANN matcher with LSH Indexing like this (considering that I have a binary feature descriptor, this sounds reasonable):

FlannBasedMatcher matcher (new flann::LshIndexParams(20,10,2));
std::vector< DMatch > matches;
matcher.match( descriptors_object, descriptors_scene, matches );


or should I rather go for a Brute-Force matcher (if I have only 500 points), since I am not reusing the index that the FLANN matcher built a second time, but each frame a new one. Or simply rely on the AutotunedIndexParams? Is the building of the FLANN-Index computational expensive?

The second question is, how to find the optimal parameters for the LshIndexParams? The original documentation (p.8) of FLANN uses 12, 20 and 2. What is the correct key-size of ORB-features?

Third and final question: Are the improvements, described in this paper(download) already implemented, or do I have to directly use the authors code?

edit retag close merge delete

I In my case when the area of the object was small, an error occurred. And I don't know why. Do you have the same problem?

( 2015-05-18 10:34:19 -0500 )edit

Sort by » oldest newest most voted
• In your case I'd rather use the BFMatcher, since you deal w. very small data. The speed-up you gain using LSH won't be huge and may be even neglected due to the creation of the index each time!
• Flann with LSH is imho a good choice for matching many binary features.
• Afaik AutotundedIndexParams is not supported with LSH, so it would end up using a kd-tree or sth else.
• The building shouldn't be very time intensive for LSH, but you'd get an overhead here.
• Finding the correct parameters is always difficult, only try and error helps.
• No, these improvements are not included. However, they aren't included in the author's code either. So, you'd have to code them yourself. . As @Nyenna pointed out, this feature is actually included in flann, called HierarchicalClusteringIndexParams() . Note that OpenCV uses an older version, so if you really want to use it, I recommend to use the bug-fixed version of Muja (take care to get not confused with the different namespaces: cvflann::, cv::flann::, flann::).
more

2

What improvements are you talking about? The hierarchical clustering trees search is implemented both in OpenCV and in the author's code...

( 2013-07-23 02:44:46 -0500 )edit
1

Oh, you are right! Thx @Nyenna to point this out! I thought only hierachical k-means is included.

( 2013-07-23 03:36:57 -0500 )edit

Official site

GitHub

Wiki

Documentation