# Revision history [back]

### 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?