OpenCV ORB描述符 - 它是如何存储在一组字节中的？

Question

我目前正在使用OpenCV的ORB特征提取器,我确实注意到存储ORB描述符的奇怪(至少对我而言)(它基本上是一个Brief-32,其修改与我的问题无关).由于一些你知道ORB需要使用改良的FAST-9提取的关键点(圆半径= 9个像素;还存储所述关键点的方向),并使用那些具有修饰的附图-32的描述符存储的特征,即关键点表示.

BRIEF(ORB版)的工作原理如下:我们采用31x31像素的补丁(代表一个特征)并创建一堆随机的5x5像素测试点.然后我们采用这些点的对并评估它们的强度,从而基于该对中的第一点的强度是大于还是小于第二点的强度来产生二元决策(0或1).然后我们取所有这些位并使用基本求和公式来构建长度为n的二进制字符串(对于BRIEF-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的ORB存储这些位串的方式对我来说是个谜.如果我们查看包含整个图像的描述符的矩阵,其中每一行是单个关键点的单个描述符,我们可以看到每个描述符有32个8位数,这总共产生了Brief-32使用的那些256位存储信息.我不明白为什么我们在32字节中分割这256位.官方文档(http://docs.opencv.org/trunk/doc/py_tutorials/py_feature2d/py_brief/py_brief.html)只说以字节为单位的OpenCV商店这样的描述,但它并不能解释为什么它做到这一点.我已经考虑了三种可能性,但没有排除这些可能是答案的可能性的可能性:

• 我看不到的一些存储技术
• 二进制字符串计算汉明距离的一些性能问题很长(在我们的例子中是256位)
• 匹配过程的优化 - 匹配基本上将来自一个图像的关键点的描述符与第二图像中的关键点的描述符进行比较.因为我们有二进制字符串汉明距离是这里显而易见的选择.这可能是某种方式每那些32个子串进行比较,它们在第二图像(子串的其它关键点的描述符在位置0对应在位置0(关键点X,图像1)与子串( .关键点Y,图像2)最后它可能是OpenCV的说:"好吧,我们有描述符的匹配率80%,因为约的所有子串26是相同的两个描述符),所以我们有一个赢家." 但是我无法找到任何证据证实这一点.

PS:你可以阅读ORB纸在这里和简单的文件在这里.

Answer 1

8位和32位模式的选择是由于存储和效率问题.

• 匹配过程

BRIEF,ORB和BRISK中的位顺序无关紧要(与FREAK不同).因此,这些描述符的所有位都具有相同的意义,您不能只比较比特流的第一部分等.

另一方面,FREAK的设计考虑了这样一个匹配过程(在FREAK的论文中称为级联).

• 存储问题

好吧,计算机不存储个别位.因此,您不会看到任何人在位数组中存储BRIEF等.

可以从存储器中读取的最小组件是一个字节(通常对应于8位,尽管有些DSP不能读取小于16位的块,但这是另一个故事).因此,您可以看到人们将其描述符存储在字节数组中(键入unsigned charC/C++,这是底层的OpenCV实现语言).

此外,当变量在CPU字边界上对齐时,内存访问通常更好(更快).现在大多数CPU都有32或64位字,32位字是更好的选择,因为64位架构的设计考虑了传统的32位处理器.

• 效率问题

汉明距离通过XOR运算来计算.碰巧许多处理器都有专用指令集,可以用32位字有效地计算XOR(在64位CPU变得更常见之前,整数的通用大小).更进一步,它们还可以支持并行计算多个32位字上的几个XOR值,这是一种称为SIMD(单输入多数据)的并行技术.例如,可以利用SSE扩展来进一步加速其大小为32位的倍数的BRIEF/ORB/...描述符的汉明距离计算.