为什么 cv2.NORM_HAMMING 给出的值与实际汉明距离不同？

Question

我正在使用 Hamming Distance to compute the difference among two keypoints descriptors obtained by the BRISK descriptor from opencv. I follow the suggestion of opencv documentation 并使用 cv2.NORM_HAMMING 计算距离如下：

dist_opencv = cv2.norm(des_1,des_2,cv2.NORM_HAMMING)

它在两个描述符中提供了一个值 87.0。但是，根据 Hamming Distance 的描述，这是不正确的。我遵循了两种替代方法（在 python 中实现）来验证这一点：

dist_alt_app_1 = len(np.where(np.abs(des_1 - des_2)>0)[0])
dist_alt_app_2 = sum(el1 != el2 for el1, el2 in zip(des_1, des_2))

dist_alt_app_1 和 dist_alt_app_2 都提供了一个值 43，这与从 opencv 获得的 87.0 不相似。做了一些搜索以了解这种差异的原因。但是没有找到解释和说明。

任何人都可以解释这种差异吗？提前致谢。

============= 在这里添加一个例子（使问题更笼统）：

des_1 = [180  25 195  96  96  88   0   0]
des_2 = [244  27 195  96  96 192   0   0]

对于上述两个描述符，dist_opencv = 5.0 和其他描述符（dist_alt_app_1 和 dist_alt_app_2）给出 3。虽然 3 是正确的汉明距离，但为什么 opencv 提供 5.0？

Answer 1

你的价值观：

180  25 195  96  96  88   0   0 
244  27 195  96  96 192   0   0

二进制

10110100 ‭00011001‬ ‭11000011‬ ‭01100000‬ ‭01100000‬ ‭01011000‬ 00000000 00000000
‭11110100‬ ‭00011011‬ ‭11000011‬ ‭01100000‬ ‭01100000‬ ‭‭11000000‬ 00000000 00000000
 ^             ^                             ^  ^^

我计算出 5 个差异 => 汉明距离是 5 => OpenCV 是正确的

提示：

您可以通过计算两个值异或后“1”的个数来计算两个值之间的汉明距离。伪代码：

HammingDistance = count_1(xor(val1, val2))

01011000
‭‭11000000‬ 
-------- xor
10011000 => it has 3 "1"

为什么 cv2.NORM_HAMMING 给出的值与实际汉明距离不同？

Why cv2.NORM_HAMMING gives different value than actual hamming distance?

python

opencv

distance

hamming-distance