Hamming slower than L2 BFMatcher

asked 2015-03-09 12:26:02 -0600

tedde gravatar image

updated 2015-03-09 18:43:16 -0600

When comparing speed of combinations of feature detectors and descriptors i realised that matching SURF features using the L2 norm is notably faster than matching BRIEF features using the hamming distance. I figured I must've done something wrong as the BRIEF paper claims the hamming distance being much faster to compute than the L2 norm - but i can not figure out what I've done wrong in that case!

(The speed is calculated using chrono and divided by features found)

Or is it correct behaviour? Or does the implementation (or compilation?) not utilise native xor instructions? Any ideas?

EDIT: So i dug around in the source code and it seams like L2 is optimised with SSE while hamming is not. Am I correct? Could that explain the results?

edit retag flag offensive close merge delete

Comments

1

Yep that is the reason, people slowly started optimizing the functions with SSE support. In order to do a fair comparison make sure that in CMAKE you disable all kinds of optimizations. Then you will see that hamming distance is indeed faster than the L2 norm :) Kind of comparing apples and pears here :)

StevenPuttemans gravatar imageStevenPuttemans ( 2015-03-10 05:31:49 -0600 )edit