Технический форум по робототехнике.
A Optical Flow вообще работает с «corner sub-pixel», и его устойчивость зависит от наличия таких особенных точек (то есть изображение должно быть контрастным, с четкими границами), а если камера например облако движущееся заснимет, тогда он и вовсе работать не будет.
Виталий писал(а):A Optical Flow вообще работает с «corner sub-pixel», и его устойчивость зависит от наличия таких особенных точек (то есть изображение должно быть контрастным, с четкими границами), а если камера например облако движущееся заснимет, тогда он и вовсе работать не будет.
Точно также как и ваш алгоритм, ведь он тоже по сути использует особые точки, только выбираете вы их по другому =)
Блочный подход наиболее распространен благодаря простоте.
Поиск векторов полным перебором дает наилучший
результат в смысле минимизации межкадровой разницы, но
имеет высокую вычислительную сложность, и поэтому редко
применяется. Даже полный перебор не всегда
правильно определяет вектора движения, тем более это
справедливо для быстрых алгоритмов.
Поле векторов, найденное блочным алгоритмом определения
движения, имеет некоторые характерные свойства. А именно,
вектор движения, с большой вероятностью, найден неверно,
если:
1) ошибка определения вектора движения велика
(поскольку это означает, что сопоставленные блоки мало похожи);
2) вектор движения значительно отличается от соседних
векторов (следует из гладкости поля векторов движения);
3) дисперсия блока мала (как правило, в этом случае блок мало отличается от соседних блоков).
На рисунке 1 приведен пример неправильного определения
векторов движения.
EDV писал(а):В прочем, мы немного отвлеклись от темы. Напомню, необходимо с помощью карты движений найти количество объектов и их границы.
EDV писал(а):Ну вот, всё бы хорошо, но cvCalcOpticalFlowBM это ничто иное как «block matching method», а у него есть серьёзный недостаток, ну-ка посмотрим, что тут коллеги из МГУ пишут:
EDV писал(а):Такого прокола с моим методом просто по определению не может случиться, так как всё полотнище будет отсегментировано одним единым сегментом, а его движение будет проанализировано по контурным точкам, там где изображение достаточно насыщенное и сравниваемым блокам есть за что «зацепиться», ну а патом найденное смещение будет аппроксимировано на всё полотнище целиком по контурным точкам.
EDV писал(а):В прочем, мы немного отвлеклись от темы. Напомню, необходимо с помощью карты движений найти количество объектов и их границы.
GraphD писал(а):Дак вы же на 1-ом шаге описанной вами процедуры нашли количество объектов через сегментацию. Чем тут еще карта векторов поможет?
=DeaD= писал(а):Согласен, такого прокола с вашим методом не случится, потому что у него случится гораздо больший прокол - вы просто не поймаете правильный вектор движения там, где его легко можно поймать, а будете его рассчитывать усреднением от огромной площади.
=DeaD= писал(а):Если использовать ваш метод - то конечно кроме различных вариаций на тему размытых контуров, опирающихся на найденные вами реперные точки - у вас ничего не найдется - просто потому что всю остальную информацию вы уничтожили по ходу обработки.
EDV писал(а):Ну что же, вот результаты обработки видеопоследовательности различными алгоритмами «Optical Flow»:
=DeaD= писал(а):А можно минимальную информацию об использованных параметрах в каждом из методов?
CalcOpticalFlowPyrLK не пробовали?
EDV писал(а):Ну что же, вот результаты обработки видеопоследовательности различными алгоритмами «Optical Flow»:
но это если у вас время и ресурсы позволяют.=DeaD= писал(а):EDV писал(а):Ну что же, вот результаты обработки видеопоследовательности различными алгоритмами «Optical Flow»:
Обработку 5 кадров подряд пробовали? Играть параметрами?
И вообще - если выложите тестовый проектик с исходниками и данными для проверки, который можно будет быстренько перекомпилировать - будет гораздно интересней многим
