Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Hi, It all depends on your computation time constraints.

Whatever the descriptor (SIFT, SURF, etc.)... each one having its computation time...

Using the FLANN matcher is fast but is approximate so that mismatches happen more often... then, it is common to see more mismatches even if using an accurate descriptor only because the matcher is not that appropriate... then, find the compromise !

Instead of using the FlannBasedMatcher, you should try C++: BFMatcher::BFMatcher(int normType, bool crossCheck=false ) http://opencv.itseez.com/modules/features2d/doc/common_interfaces_of_descriptor_matchers.html?highlight=crosscheck.

This matcher is brute force then it requires much more processing power but... it is more precise.

In addition, you can try different setups : choose the distance (normType parameter) : NORM_L1 is efficient and low cost, NORM_L2 "can" be better but is more expensive.. but you can use NORM_L2SQR which is equivalent to the L2 distance but avoids the square root computation, avoiding some CPU usage.

If you use crossCheck=true, this will allow a more refined matching by trying to match in both directions (img1->img2 and img2->img1) and keep common matches... but this will result in fewer matches. However, take care, a bug report has been sent this summer : on current trunk, crossCheck=true leads to some wrong computations... (see http://code.opencv.org/issues/2292

If you do not use the crossCheck=true setup, then, I recommend to not use directly the BFmatchers object but prefer the static allocation method :

C++: Ptr<descriptormatcher> DescriptorMatcher::create(const string& descriptorMatcherType), then, use "BruteForce-L1", "BruteForce-L2", "BruteForce-SL2" or "FlannBased" to choose the appropriate matching method, this makes your program more flexible.

Have a nice code ;o)

click to hide/show revision 2
No.2 Revision

Hi, It all depends on your computation time constraints.

Whatever the descriptor (SIFT, SURF, etc.)... each one having its computation time...

Using the FLANN matcher is fast but is approximate so that mismatches happen more often... then, it is common to see more mismatches even if using an accurate descriptor only because the matcher is not that appropriate... then, find the compromise !

Instead of using the FlannBasedMatcher, you should try C++: BFMatcher::BFMatcher(int normType, bool crossCheck=false ) http://opencv.itseez.com/modules/features2d/doc/common_interfaces_of_descriptor_matchers.html?highlight=crosscheckhttp://docs.opencv.org/modules/features2d/doc/common_interfaces_of_descriptor_matchers.html?highlight=crosscheck.

This matcher is brute force then it requires much more processing power but... it is more precise.

In addition, you can try different setups : choose the distance (normType parameter) : NORM_L1 is efficient and low cost, NORM_L2 "can" be better but is more expensive.. but you can use NORM_L2SQR which is equivalent to the L2 distance but avoids the square root computation, avoiding some CPU usage.

If you use crossCheck=true, this will allow a more refined matching by trying to match in both directions (img1->img2 and img2->img1) and keep common matches... but this will result in fewer matches. However, take care, a bug report has been sent this summer : on current trunk, crossCheck=true leads to some wrong computations... (see http://code.opencv.org/issues/2292

If you do not use the crossCheck=true setup, then, I recommend to not use directly the BFmatchers object but prefer the static allocation method :

C++: Ptr<descriptormatcher> DescriptorMatcher::create(const string& descriptorMatcherType), then, use "BruteForce-L1", "BruteForce-L2", "BruteForce-SL2" or "FlannBased" to choose the appropriate matching method, this makes your program more flexible.

Have a nice code ;o)