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

Question

我正在使用Hamming Distance来计算BRISK descriptor from opencv获得的两个关键点描述符之间的差异。我按照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"