我有一条角度为 205 度、长度为 77 像素的线。（用 sqrt(x^2+y^2) 找到）有点像这样。这张图片上的测量值不正确，它只是为了向您展示我的意思。
我正在执行 houghlines2 像这样：
image.HoughLines2(storage, HoughLinesMethod.Probalistic, 2, Cv.PI / 90, 1, lineLength, 0);
我添加了一个 for 循环来确保我检测到了这条线。当 lineLength 为 44 时，我终于找到了使用 houghlines2 方法的线 - 见下图。
为什么我必须一直降到44？我需要能够以“几乎”正确的长度找到它，+- 10 可以，但 -33 太多了。
我需要关于如何执行 houghtransform 的答案，而不是很多指向不同读数的链接。我一直在阅读很多页面，但我无法理解它。
让我试一试……今年夏天我一直在 C++ 中使用 OpenCV 的 Hough 变换，但实际上我从未在HOUGH_PROBABILISTIC.
我有一个大致的想法，为什么标准的霍夫变换有时不会检测到一条线，它可能会给你一个解释为什么这也不起作用：当你应用该HoughLines2方法时，你必须指定rho和theta参数。现在，如果这个参数设置不正确（例如，bin 间隔太宽，theta 太大），可能会“错过”部分行。
你说你做了一些阅读，所以你知道大致的想法。现在，如果您尝试想象一条从(0, 0)到的线(500, 1)。如果您知道如何以数字方式绘制直线，那么您就会知道这通常显示为类似于直线：一条 from (0, 0)to (250, 0)，另一条 from (250, 1)to (500, 1)。如果您的霍夫角现在很大（例如，大于线所在的角度），它实际上永远不会“捕捉”同一箱中的所有这些点，并且基本上会检测到两条长度为250的线。不仅“小一点”，而且实际上很多。由于HOUGH_PROBABILISTIC不仅需要像素落入同一个“bin”，而且还要求它们在原始图片中或多或少是连续的，这可能为这个故事增加了另一层复杂性。
如果您考虑仅检测线段，则可能适用的其他解释是，最小长度不是由像素的实际数量决定的，而是由最终在同一个 bin 中的像素数量决定的。现在，由于上面提到的同样的事情，所有 77 个像素可能实际上并不在 bin 中，因此很短。
当然，所有这些只是我认为可能导致问题的基本原则。希望它有所帮助。我的建议是：尝试使用“rho”和“theta”参数或其他方式，只检测正常线。这些方法在 OpenCV 中的实现要好于这个版本的 IMO。