相关疑难解决方法(0)

我目前正在使用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纸在这里和简单的文件在这里.