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

Posted 2023-02-16

【中文标题】为啥 cv2.NORM_HAMMING 给出的值与实际汉明距离不同？

【英文标题】：Why cv2.NORM_HAMMING gives different value than actual hamming distance?为什么 cv2.NORM_HAMMING 给出的值与实际汉明距离不同？

【发布时间】：2019-02-19 09:33:52

【问题描述】：

我正在使用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？

【参考方案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"

【讨论】：

+1，所以是因为opencv计算的位差？关于两个描述符之间可接受的差异阈值有什么建议吗？

是的，汉明距离是按位计算的。不，定义两个描述符之间距离的阈值没有多大意义。您最好按距离对所有匹配项进行排序，只保留前 N 个，或者低于中值的那些，等等......