Ask Your Question

BFMatcher performances VS OpenCV version

asked 2019-02-01 07:59:27 -0500


First of all, I want to thank you for all the great jobs you 're doing with openCV. I notice a change in computation time of the BFMatcher::match function between 2 opencv versions. The difference is a factor of 2 between 3.4.3 and 3.4.4 (and above). I use a simple test program wich run this function 1000 times and compute average, min and max of the time taken by this function to run. All the versions (except 3.2) are built using the cmake flags shown in this post.

I made a diff of modules/features2d between 3.4.3 and 3.4.4 and did not see any major changes. Do you have some hints of what can cause this? Do I made something wrong with the cmake flags for v3.4.4 and above ?

Thanks for your help,

Best regards

image description

Test code :

int nTest = 1000;
vector<KeyPoint> kpts1;
Mat desc1;
vector<DMatch> matches;
vector<double> bfTime;
Mat img1 = imread("./anImage.jpg", IMREAD_GRAYSCALE);

Ptr<ORB> orb_detector = ORB::create(1500);
Ptr<BFMatcher> matcher = BFMatcher::create(NORM_HAMMING, true);
orb_detector->detect(img1, kpts1);
orb_detector->compute(img1, kpts1, desc1);

for(int i = 0; i < nTest; i++){
    auto start = chrono::high_resolution_clock::now();
    matcher->match (desc1, desc1, matches);
    auto stop = chrono::high_resolution_clock::now(); 
    auto duration = chrono::duration_cast<chrono::microseconds>(stop - start);
double totalTime = accumulate(bfTime.begin(), bfTime.end(), 0.0);
cout << "mean time: "<< totalTime / double(nTest) << " [s] min time: "<< *min_element(bfTime.begin(), bfTime.end()) << " [s] max time: "<< *max_element(bfTime.begin(), bfTime.end()) <<endl;

cmake flags:

 cmake .. -DCMAKE_BUILD_TYPE=Release \
   -DCMAKE_INSTALL_PREFIX=/home/baptiste/App/install/opencv \
   -DBUILD_opencv_python2=OFF \
edit retag flag offensive close merge delete


Maybe you could try to save / load keypoints and descriptors. This way, we are sure that the issue directly comes from the brute force matching method.

Eduardo gravatar imageEduardo ( 2019-02-01 11:35:40 -0500 )edit

2 answers

Sort by ยป oldest newest most voted

answered 2019-02-21 03:09:32 -0500

Eduardo gravatar image

updated 2019-02-21 03:11:04 -0500

You are using brute-force matching with cross check enabled.

Since OpenCV 3.4.4, cross check has been fixed. See this issue: BFmatcher with crossCheck=True doesn't cross check #11855 and the corresponding pull request.

edit flag offensive delete link more

answered 2019-02-20 10:23:46 -0500

I also ran the openCV performances tests on features2d (following this) for version 3.4.3 and 3.4.4 and get the following result for this test name : batchDistance_Dest_32S::Norm_CrossCheck::(NORM_HAMMING, true)

image description

This function is called in the brute force matcher when the Hamming norm is used and cross check is set to true. I observe the same difference in terms of computation time in this two particular versions as my tests shown (in my previous post)

Do these performances tests has been performed by someone else for these versions: 3.4.3 and 3.4.4 ? Are my CMake flags not good ?

Thanks a lot. I can send you the results of these performances tests (.xml) if you need to. (I'm on Ubuntu 18.04.2 LTS)

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower


Asked: 2019-02-01 07:59:27 -0500

Seen: 88 times

Last updated: Feb 21