Почему 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"