Почему cv2.NORM_HAMMING дает другое значение, чем фактическое расстояние Хэмминга?

Question

Я использую расстояние Хэмминга, чтобы вычислить разницу между двумя дескрипторами ключевых точек, полученными дескриптором BRISK из opencv. Я следую предложению документации 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, которое не похоже на 87.0, полученное из opencv. Сделал некоторые поиски, чтобы узнать причину этой разницы. Но не нашел объяснения и уточнения.

Кто-нибудь может дать объяснение этой разнице? Заранее спасибо.

============= Добавление здесь примера (чтобы сделать вопрос более обобщенным):

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" после XOR-го двух значений. псевдокод:

HammingDistance = count_1(xor(val1, val2))

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