与 SURF 比较的奇怪结果
我正在尝试使用 OpenCV 和 SURF 方法实现交通标志识别器。我的问题是我得到随机结果（有时非常准确，有时明显错误），但我无法理解为什么。以下是我实现比较的方法：
- 首先我检测图像上的轮廓
- 然后在每个轮廓上，我使用 SURF 找出交通标志是否在内部以及哪个交通标志
轮廓检测效果非常好：使用高斯模糊和精明边缘我设法找到与此类似的轮廓：
然后我提取与该轮廓相对应的图像，然后我将此图像与交通标志模板图像进行比较，例如：
cvExtractSURF 返回轮廓图像的 189 个描述符。然后我使用 naiveNearestNeighbor 方法来找出我的轮廓图像和每个模板图像之间的相似性。
这是我的结果：
第一个模板（这是我期望找到的模板）6/189
第二个模板（这显然非常好）92/189与轮廓图像在各个方面都不同）
我真的不明白这些结果...
这是我执行的步骤列表：
- 将轮廓图像转为灰度
- 将模板图像转为灰度
- 均衡轮廓图像的直方图 (cvEqualizeHist)
- 调整大小模板图像，使其与轮廓图像匹配
- 模糊模板图像（cvSmooth）
- 模糊轮廓图像（cvSmooth）
- 在模板图像上执行 cvExtractSURF 在
- 轮廓图像上执行 cvExtractSURF
- 对于轮廓图像的每个描述符，我都会执行一个 naiveNearestNeighbor
- 我存储“好”点的数量
为了评估 2 个图像之间的相似性，我使用比率：
goog 点的数量 / 描述符总数
P.S：有关信息，我遵循本教程：http://www.emgu.com/wiki/index.php/Traffic_Sign_Detection_in_CSharp
并使用OpenCV的find_obj示例对其进行改编C.
I'm trying to implement a traffic sign recognizer with OpenCV and SURF method. My problem is that i get random results (sometimes really accurate, sometimes obviously wrong) and i cant undertsand why. Here is how i implemented the comparison :
- First i detect contours on my image
- Then on each contour, i use SURF to find out if a traffic sign is inside and which traffic sign
The contour detection works perfectly well : using a gaussain blur and canny edge i manage to find a contour similar to this one :
Then i extract the image corresponding to this contour and i compare this image to traffic signs template image such as these :
The cvExtractSURF returns 189 descriptors for the contour image. Then i use the naiveNearestNeighbor method to find out similarities between my contour image and each template image.
Here are my results :
6/189 for the first template (which is the one i'm expecting to find)
92/189 for the second template (which is obviously very different in every way to the contour image)
I really dont understand these results…
Here is the list of the steps i perform :
- Turn the contour image in grayscale
- Turn the template image in grayscale
- Equalize the histogram of the contour image (cvEqualizeHist)
- Resize the template image to make it match the contour image
- Blur the template image (cvSmooth)
- Blur the contour image (cvSmooth)
- Do a cvExtractSURF on the template image
- Do a cvExtractSURF on the contour image
- For each descriptor o the contour image i do a naiveNearestNeighbor
- I store the number of "good" points
To evaluate the similarity between the 2 images i use the ratio :
number of goog points / total number of descriptors
P.S: For information i followed this tutorial : http://www.emgu.com/wiki/index.php/Traffic_Sign_Detection_in_CSharp
And used the find_obj sample of OpenCV to adapt it in C.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SURF 描述符非常适合比较纹理丰富的图像...我认为交通标志中没有足够的纹理供它们使用。
提取描述符时，首先定位“显着点”，在您的情况下，例如位于两个标志（矩形和字母 P）上的矩形标记的角点，然后为它们收集局部属性。比如，从近距离看，矩形的角是怎样的，模糊且灰度。
然后，这些描述符与字母 P 中的矩形角进行匹配。它们并没有那么不同......（因为我们没有考虑任何形状信息）。也许字母 P 的角更接近“禁止进入”标志的角。随机地。
当然，这一切都只是猜测……唯一能弄清楚的方法就是彻底调试。尝试在找到描述符的地方显示带有小圆圈的图像（圆圈大小可能取决于找到点的比例）。或者将两个图像放入一个 IplImage 中，并在匹配的描述符之间画线。像这样的东西：
http://www.flickr.com/photos/22191989@N00/268039276 至于如何解决这个问题
...对内部使用与检测交通标志外部轮廓相同的形状匹配方法怎么样？ （例如，一旦找到标志，您就可以寻找 P 形物体。）
SURF descriptors are fine for comparing richly textured images... I think there isn't enough texture in traffic signs for them.
When extracting descriptors, first "salient points" are located, in your case for example at the corners of the rectangularly shaped marks on both signs (the rectangle and the letter P), then local properties are collected for them. Like, how does a corner-of-a-rectangle look like, from close up, blurred and grayscale.
Then, these descriptors are matched to the corner-of-a-rectangle-s from the letter P. They aren't all that different... (as we're not taking any shape information into account). Maybe the corners of the letter P are a little bit more close to those of the "no entry" sign. Randomly.
Of course, all of this is just a speculation... the only way to figure out is to debug it thoroughly. Try displaying the images with little circles where the descriptors were found (circle size could depend on the scale the point was found at). Or put both of the images into one IplImage and draw lines between the matching descriptors. Something like this:
http://www.flickr.com/photos/22191989@N00/268039276
As for how to fix this... what about using the same shape matching method for the inside that you use for detecting the outside contours for the traffic sign? (For example, you could look for P shaped objects once a sign is found.)
我认为这是一个不好的度量，您需要使用基于描述符向量的度量，并且必须使用点之间的空间信息。
这是因为类似 SIFT 的特征只匹配“相同的点”而不是相似的点，也许你可以通过改变匹配标准来调整它。因为在 opencv 中匹配标准是获取最近的点（通过描述符）并检查附近是否有另一个描述符0.6 相似度。
描述符匹配分为两个步骤。第一步遵循 David Lowe 的简单但强大的匹配算法。更准确地说，为了查看左图像中的描述符 A 是否与右图像中的某个描述符匹配，我们首先计算左图像中的描述符 A 与所有描述符 A 之间的欧几里得距离 d(A, A') ' 在右图中。如果最近距离（例如 d(A, A1')）小于第二最近距离（例如 d(A, A2')）的 k 倍，则 A 和 A1' 被视为匹配。我们设置 k=0.6
也许你可以改变 k，但我认为它会产生更多的误报。
I think it's a bad metric you need to use metric based on descriptor vectors and you must use spartial information between the points.
This is because SIFT-like features matches just the "same points" but not similar points, maybe you can tweak it by changing matching criteria.Because in opencv matching criteria is get nearest point(by descriptor) and check if there is another descriptor near 0.6 similarity.
the descriptor matching consists in two steps. The first step follows the simple but powerful matching algorithm of David Lowe. More precisely, to see if a descriptor A in the left image matches with some descriptor in the right image or not, we compute first the Euclidean distance d(A, A') between the descriptor A in the left image with all the descriptors A' in right image. If the nearest distance, say d(A, A1'), is smaller than k times the second nearest distance, say d(A, A2'), then A and A1' are considered as matched. We set k=0.6
maybe you can change k, but I think it gives more false positives.