问题标签 [feature-descriptor]

我刚刚研究并着手SURF实现它，但我仍然不明白我们为什么要descriptor在其中使用，我了解keypoints其中的目的，但是当我们提取关键点时，我们为什么需要这样做descriptors？它们在认可中的重要性和作用是什么？

我从纸上、论坛和网络上读到了它，但我没有通过那个方程式得到它，我只想用简单的话来了解它，因为有些人可能不善于理解方程式。

I am trying to understand how to get the descriptor for a given KeyPoint in OpenCV. So far my code looks like follows:

The problem is that I am getting no data in the descriptor. What am I missing? Could you explain in more detail what are the params passed to the KeyPoint object? I am new to computer vision + OpenCV, so probably a better explanation (than OpenCV's documentation) could help.

我正在使用 OpenCV 来计算 ORB 描述符，我遇到的问题是在执行过程中的随机点出现这样的错误

LightFieldRecovery(3468,0x7fff73a9a310) malloc: * 对象 0x100911608 错误：已释放对象的校验和不正确 - 对象可能在被释放后被修改。*在 malloc_error_break 中设置断点进行调试

我没有使用任何指针（明确地）我使用 std::vectors 作为数据容器。代码太长，无法在此处发布，但您可以看到它https://github.com/BRabbit27/LigthField/blob/master/LightFieldRecovery/main.cpp

有没有人能发现这个错误在哪里？我整天都在找它。

我在 OS X Mavericks、Xcode 5 和 C++ 下工作（在 Xcode 的 Build Settings 下，C++ Language Dialect设置为-std=gnu++11否则我无法编译 OpenCV 代码）

编辑

在 Valgrind 的帮助下，我能够将问题缩小到以下代码段，但我看不出错误是什么，我不明白将数据从 a 复制cv::Mat到uchar*指针时我错过了什么。

错误 A

错误 B

显然我假装使用memset的方式不是一个好方法。

错误 C

同样，memcpy我传递了错误的参数或复制到越界区域

错误 D

如何创建 SIFT 描述符（图像）数据库？我的目的是在支持向量机上实施一个有监督的训练集。

我使用的CPU版本如下。

我的问题是如何使用 GPU 获取“描述符”？

我尝试了以下代码。（不起作用）

如何从“gpu_descriptors”获取“描述符”？

任何人都可以帮我解决这个问题吗？非常感谢！

我正在尝试根据本 教程使用 FLANN 算法评估特征检测器和描述符

我想为评估部分建立一个ROC 曲线，因此我必须得到 TP、FN、FP 和 TN。问题是，我不知道如何获得这些值！我读过很多论文，但都没有解释，例如他们是如何得到误报的。在给定的教程中，您可以设置一个特定的阈值，以便您可以计算好匹配和坏匹配，但这并不是一切都正确匹配的理由。我应该手动计算每个图像对还是他们的常用技术自动解决它。

提前感谢您的帮助！

如何通过以下方式在 OpenCV 中创建可与 OpenCV 中的 DescriptorMatchers 之一一起使用的描述符。

我已经有以下描述符类。如何转换或创建可与 DescriptorMatcher 一起使用的新矩阵。最好是BFMatcher。

我正在使用 opencv 2.4.8。像这样声明 orb：

补丁大小不是意味着关键点周围应该有 (patchsize-1)/2 空间吗？

我在垂直和水平边距为 15 像素的坐标处提供关键点，但这样的位置无法生成描述符。

例如，对于 240x320 的图像，无法描述点 (15,15)，即使有足够的像素 (0,1,....14 -> 15 像素)。

无论如何使用描述符检测图像中的统计表？我已经使用 opencv 训练了一个 haar 分类器。有没有其他方法或技术来检测给定图像中是否有表格？

编辑1： 找到我对下表所做的霍夫线转换。

检测图像中对象的概念方法是什么？

我目前正在使用 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的论文。