opencv houghlines2 длина линии - это путь к короткому

Question

У меня есть линия с углом 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 - это слишком много.

Мне нужен ответ о том, как выполнить преобразование хоут, а не много ссылок на разные чтения. Я читал на многих страницах, но я не могу понять это op.

Answer 1

Позвольте мне попробовать это ... Я этим летом использовал Hough Transform из OpenCV в C ++, и я никогда не получал хороших результатов с HOUGH_PROBABILISTIC.

У меня есть общее представление о том, почему стандартное преобразование Хафа иногда не обнаруживает линию, и это может дать вам объяснение, почему это также не работает: При применении метода HoughLines2 необходимо указать аргумент rho и theta . Теперь, если эти аргументы установлены неправильно (например, ячейки слишком широки друг от друга, тета слишком велики), можно «пропустить» части строк.

Вы сказали, что немного читали, так что вы знаете общую идею. Теперь, если вы попытаетесь представить линию, которая охватывает от (0, 0) до (500, 1). Если вы знаете, как нарисованы прямые цифровые линии, то вы знаете, что это обычно отображается как линии: одна от (0, 0) до (250, 0), а другая от (250, 1) до (500, 1). Если ваш угол Хафа теперь большой (например, больше, чем угол, под которым находится линия), он фактически никогда не «поймает» все эти точки в одной ячейке и в основном обнаружит две линии длины 250, Не просто "немного" поменьше, а на самом деле много. Поскольку HOUGH_PROBABILISTIC не только требуется, чтобы пиксели попадали в одну и ту же "ячейку", но также требуется, чтобы они были более или менее непрерывными в исходной картинке, это, вероятно, добавляет еще один слой сложности к этой истории.

Другое объяснение, которое может быть применимо, если вы рассмотрите возможность обнаружения только строки сегментов , заключается в том, что минимальная длина определяется не действительным числом пикселей, а количеством пикселей, которые попадают в один и тот же блок. , Теперь, из-за того же, что упомянуто выше, все 77 пикселей могут фактически не быть в корзине, и, следовательно, краткость.

Все это, конечно, просто основной принцип того, что, я думаю, может быть причиной проблемы. Надеюсь, это поможет. Мой совет: попробуйте поиграться с параметрами "rho" и "theta" или иным образом, просто определите нормальные линии. Эти методы реализованы немного лучше в OpenCV, чем в этой версии IMO.