OpenCV ORB descriptor-как именно он хранится в наборе байтов?

в настоящее время я использую OpenCV ORB features extractor, и я заметил странный (по крайней мере для меня) способ хранения ORB-дескриптора (это в основном краткое-32 с модификацией, которая не имеет отношения к моему вопросу). Как некоторые из вас знают, ORB берет ключевые точки, извлеченные с помощью модифицированного FAST-9 (радиус окружности = 9 пикселей; также сохраняет ориентацию ключевой точки), и использует те, с измененным дескриптором BRIEF-32 для хранения функции, которую ключевая точка представляет.

BRIEF (версия ORB) работает следующим образом: мы берем патч 31x31 пикселей (представляет собой функцию) и создаем кучу случайных тестовых точек 5x5 пикселей. Затем мы берем пары этих точек и оцениваем их интенсивности, что приводит к двоичному решению (0 или 1), основанному на том, больше или меньше интенсивность первой точки в паре, чем интенсивность второй. Затем мы берем все эти биты и используем базовую формулу суммы для построения двоичной строки длиной n (для краткости-32 у нас есть 32 байта * 8 = 256-битная двоичная строка):

SUM (2^(i-1)*bit_pair_test)

где bit_pair_test-это битовое значение, которое мы рассчитали из теста для пары тестовых точек. Конечный результат-что-то вроде (для набора двоичных тестов (...,0,1,0,1,1)):

(2⁰*1) + (2¹*1) + (2²*0) + (2³*1) + (2⁴*0) + ...

теперь способ, которым шар OpenCV хранит эти bitstrings, является для меня загадкой. Если мы посмотрим на матрицу, содержащую дескрипторы для всего изображения с каждой строкой, являющейся одним дескриптором для одной ключевой точки, мы увидим, что каждый дескриптор имеет 32 8-битных числа, что в целом приводит к тем 256 битам, которые BRIEF-32 использует для хранения информации. я не понимаю, почему мы разделяем эти 256 бит на 32 байта. Официальная документация (http://docs.opencv.org/trunk/doc/py_tutorials/py_feature2d/py_brief/py_brief.html) только говорит, что OpenCV хранит такие дескрипторы в байтах, однако не объясняет, почему он это делает. Я рассмотрел три возможности, не исключая возможности того, что какая-то комбинация из них может быть ответом:

• некоторые методы хранения, которые я просто не вижу
• некоторая проблема производительности с вычислением расстояния Хэмминга для двоичной строки, которая long (256 бит в нашем случае)
• оптимизация процесса сопоставления-сопоставление в основном сравнивает дескриптор ключевой точки из одного изображения с дескриптором ключевой точки во втором изображении. Поскольку у нас есть двоичные строки, расстояние Хэмминга является очевидным выбором здесь. Возможно, каждая из этих 32 подстрок каким-то образом сравнивается со своими аналогами в дескрипторе другой ключевой точки во втором изображении (подстрока в позиции 0 (ключевая точка X, изображение 1) с подстрока в положение 0 (точка г, Рис.2). Наконец, может быть, OpenCV говорит: "Хорошо, у нас есть скорость совпадения 80% дескриптора с ок. 26 всех подстрок одинаковы в обоих дескрипторах), поэтому у нас есть победитель."Однако я не смог найти никаких доказательств, подтверждающих это.

PS: вы можете прочитать статью на ORB здесь а бумага на BRIEF здесь.