问题标签 [orb]

在 OpenCV 中使用 BRISK 进行特征检测和描述时遇到性能问题。

基本上，我尝试匹配从这张图片中获得的所有描述符：

针对我从图像数据库中获得的所有描述符，使用基于 flann 的匹配器和 LSH 算法和 BRISK 进行特征检测和描述。

我的图像数据库由 242 张图像组成。在这 242 张图像中，有三张图像对应于上述“复杂”图像查询中分别拍摄的每个对象。

以下是用于 BRISK 检测的参数（默认 opencv 参数）：Treshold：30，Octaves：4，Pattern scale：1.0。

在使用最佳匹配技术进行 flann 匹配后（图像查询中的每个描述符都与其在数据库描述符集中的最近邻域相关联），我的算法输出按匹配百分比排序的数据库图像列表。以下是前四个结果：

1. 数据库中螺栓对应的图像：4 个匹配/15 个检测到的关键点 => 匹配百分比：26.7%。
2. 与数据库中的瓶子对应的图像有 4 个匹配 / 15 个检测到的关键点 => 匹配百分比：26.7%。
3. 数据库中螺栓对应的图像有 10 个匹配 / 59 个检测到的关键点 => 匹配百分比：16.9%。
4. 对应于图像查询中不存在的对象的图像：1 个匹配/16 个检测到的关键点 => 匹配百分比：16.7%。

我使用 ORB 作为特征检测和描述来比较这个结果。以下是使用的参数：特征数：2000，比例因子：1.2，金字塔级别数：8。

这是我得到的结果：

1. 数据库中螺栓对应的图像：576 个匹配/752 个检测到的关键点 => 匹配百分比：76.6%。
2. 与数据库中的瓶子对应的图像有 111 个匹配 / 189 个检测到的关键点 => 匹配百分比：58.7%。
3. 数据库中笔对应的图像有 124 个匹配 / 293 个检测到的关键点 => 匹配百分比：42.3%。
4. 对应于图像查询中不存在的对象的图像：2 个匹配/66 个检测到的关键点 => 匹配百分比：3%。

如您所见，使用 ORB 的结果要好得多。首先，在数据库中的每张图像上检测到更多的关键点，并且对于好的对象，匹配的百分比明显更好。此外，好对象的匹配百分比与错误对象的匹配百分比之间的差距更为显着。

我想知道为什么 BRISK 检测器检测到的关键点比 ORB 检测器少得多。我进行了不同的测试，以弄清楚如何使用 BRISK 检测器检测更多关键点（降低阈值，降低八度数）。我确实可以检测到更多的关键点，但与 ORB 检测器的区别仍然非常重要。你知道为什么 BRISK 检测器会有这样的行为吗？

我的 OpenCV 版本是 2.4.8，但我根据这些陈述尝试了 2.4.4 和 2.4.9 版本的 BRISK 检测部分：

http://code.opencv.org/issues/2491和BRISK 特征检测器在没有改进的情况下检测到零关键点。

我还尝试将 ORB 检测器与 BRISK 描述结合起来。匹配结果优于第一种方法（完全 BRISK），但比第二种方法（完全 ORB）差：

1. 数据库中螺栓对应的图像：529 个匹配/708 个检测到的关键点 => 匹配百分比：74.7%。
2. 与数据库中的瓶子对应的图像有 69 个匹配 / 134 个检测到的关键点 => 匹配百分比：51.5%。
3. 数据库中与笔对应的图像已匹配 93 / 247 个检测到的关键点 => 匹配百分比：37.6%。
4. 对应于图像查询中不存在的对象的图像：5 个匹配/50 个检测到的关键点 => 匹配百分比：10%。

请注意，在方法 2 和方法 3 中，在每个图像上检测到的关键点数量并不相同。实际上，当我在测试图像（这里是螺栓的图像）上运行此代码时：

BRISK 似乎没有计算描述符中所有检测到的关键点（ORB 检测器检测到的 752 个关键点 => BRISK 描述符计算的 708 个描述符）。

然而，即使 ORB 检测到的所有关键点都不是在 BRISK 描述符中计算的。从这些结果看来，BRISK 不是比 ORB 更好地描述一个关键点吗？如果我错了，请纠正我，但我很确定应该是相反的......

如果你们有任何可以帮助我理解我的结果的元素，或者如果你已经在 OpenCV 中遇到了 BRISK 的一些问题，请告诉我。任何帮助将不胜感激 ：）。

我目前正在使用 OpenCV 的 ORB 特征提取器，我确实注意到 ORB 描述符的存储方式很奇怪（至少对我而言）（它基本上是一个 BRIEF-32，其修改与我的问题无关）。正如你们中的一些人所知，ORB 使用修改后的 FAST-9（圆半径 = 9 像素；还存储关键点的方向）提取关键点，并使用带有修改后的 BRIEF-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 位来存储信息。我不明白为什么我们将这 256 位分成 32 字节。官方文档（http://docs.opencv.org/trunk/doc/py_tutorials/py_feature2d/py_brief/py_brief.html）只说OpenCV以字节为单位存储这些描述符，但它没有解释它为什么这样做。我考虑了三种可能性，但不排除这些可能性的某种组合可能是答案的可能性：

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

PS：你可以在这里阅读关于 ORB的论文和关于这里的 Brief的论文。

在过去的两天里，我一直在试图弄清楚如何向 openCV 的 ORB 添加函数。

我已经弄清楚如何添加参数和修改当前函数，但似乎无法添加新函数。

我的最终目标是拥有一个球体特征检测器并能够调用公共函数：

cv::Ptr p = new cv::OrbFeatureDetector() p->compute(~~) ;

我希望能够调用一个附加函数，例如： p->doSomething();

这是否可以在不必制作任何其他文件、名称空间等的情况下完成？

还是我必须坚持传统的 setter / getter 方法？- 如果这有什么不同，我正在使用 C++。

我只是在做一个小实验来玩不同的检测器/描述符组合。

我的代码使用 ORB_GPU 检测器来检测特征，使用 SURF_GPU 描述符来计算描述符。我使用 BruteForceMatcher_GPU 来匹配描述符，并且我正在使用 knnMatch 方法来获取匹配项。问题是我得到了很多不需要的匹配，代码实际上匹配了它可以在两个图像中找到的每个功能。我对这种行为感到很困惑。以下是我的代码（GPU版本）

如图所示，代码随机匹配任何东西。我使用普通的 CPU 功能尝试了同样的方法，它非常准确。CPU版本的代码如下

任何帮助将不胜感激。

我正在使用 ORB 特征检测器使用以下代码查找两个图像之间的匹配项：

我的问题是我找不到过滤匹配项的方法，以便它们仅在照片中具有相似位置时才匹配。我总是为一个关键点获得多个匹配，即使它们在位置上非常遥远。

有没有办法更好地过滤它们？

我在 CORBA 中遇到问题。我的服务器运行良好。但是当我尝试将客户端连接到服务器时出现此错误

有谁知道我们在哪种情况下会收到此错误？

我正在尝试对视频的帧运行 ORB OpenCV 算法，我注意到 CPU 版本的执行速度比 GPU 版本快得多。这是代码：

在 3000 帧和 720x480 分辨率的视频上运行此程序后，GPU 时间为 54 秒，CPU 时间为 24 秒。我与其他视频（不是高清）得到了类似的结果。电脑规格：

• i7-4770K CPU 3.50 GHz

• 英伟达 GeForce GTX 650

• 16 GB 内存

其他特征检测/描述算法（如 SURF）在我的机器上使用 GPU 实现时执行得更快。

有没有人在他的机器上比较过 ORB 的两种实现？

如本教程中所述，我试图使用 OpenCV ORB 匹配两个图像。

这是我的代码：

我用两个非常相似的图像运行了这个脚本。在大多数情况下，脚本可以正常工作并找到匹配的关键点。

但是，在某些情况下，我会收到此错误（它指的是最后三行代码）：

当 img2 明显是 img1 的较小子图像时，就会发生这种情况。

（如果img2是原图，img1是修改后的图，说明有人在原图上加了细节）。

如果我在文件名 img1,img2 之间切换，则脚本运行没有问题。

查询图像 (img1) 必须小于还是等于火车图像 (img2)？

我想知道我的 CORBA 服务器可以同时处理多少个客户端请求：

1. 服务器是否为每个新的客户端请求创建一个新线程？
2. 有线程池吗？
3. 默认线程池大小是多少？
4. 如果我们达到最大尺寸会发生什么？新线程是否在队列中等待？
5. 池中非活动线程（已用于客户端的线程）的空闲时间是多少？
6. 我们可以配置这些参数（池大小和空闲时间）吗？

我做了很多研究，但我没有为 Sun/Oracle 官方 CORBA 实现 (JDK) 找到这些问题的真正答案。在 Oracle 文档（链接）中，我们可以看到： -Djava.naming.factory.initial=com.sun.appserv.naming.S1ASCtxFactory -Dcom.sun.appserv.iiop.orbconnections=value

=> 我不确定这个参数到底是什么，而且这个参数可能不兼容所有的JVM，它的默认值为“one”。

我知道对于 RMI，有一个“ sun.rmi.transport.tcp.maxConnectionThreads ”参数用于更改默认线程池大小（这已经是“无限制的”）。非活动线程空闲时间为 1 分钟... RMI 受 CORBA 启发，所以 Sun/Oracle 可能为它们设置了相同的参数？

谢谢

我正在尝试在 iOS 上使用 OpenCV 进行对象检测。我正在使用文档中的此代码示例。

这是我的代码：

问题在于始终为空的extractor.compute(src_gray, keypoints_1, descriptors_1);行descriptors_1。

src并且templ不为空。

有什么想法吗？

谢谢