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

Question

我正在使用汉明距离来计算由来自 opencv的BRISK 描述符获得的两个关键点描述符之间的差异。我遵循opencv 文档的建议并在计算距离时使用cv2.NORM_HAMMING如下：

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

它在两个描述符中提供值 87.0。但是，根据汉明距离描述，这是不正确的。我遵循了两种替代方法（在 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"