roboforum.ru

A Optical Flow вообще работает с «corner sub-pixel», и его устойчивость зависит от наличия таких особенных точек (то есть изображение должно быть контрастным, с четкими границами), а если камера например облако движущееся заснимет, тогда он и вовсе работать не будет.

Точно также как и ваш алгоритм, ведь он тоже по сути использует особые точки, только выбираете вы их по другому =)

Виталий писал(а):

A Optical Flow вообще работает с «corner sub-pixel», и его устойчивость зависит от наличия таких особенных точек (то есть изображение должно быть контрастным, с четкими границами), а если камера например облако движущееся заснимет, тогда он и вовсе работать не будет.

Точно также как и ваш алгоритм, ведь он тоже по сути использует особые точки, только выбираете вы их по другому =)

Подтверждаю сказанное Виталием.

Однако с утверждением "Optical Flow зависит от наличия особенных точек" не согласен. Optical Flow это вроде задача, а конкретных алгоритмов её решения целое семейство. В том же OpenCV есть реализация четырех методов - как минимум CalcOpticalFlowBM, если я всё правильно понял, работает со всеми точками подряд, а не только с особыми.

Ну вот, всё бы хорошо, но cvCalcOpticalFlowBM это ничто иное как «block matching method», а у него есть серьёзный недостаток, ну-ка посмотрим, что тут коллеги из  МГУ пишут:

  Блочный подход наиболее распространен благодаря простоте.
Поиск векторов полным перебором дает наилучший
результат в смысле минимизации межкадровой разницы, но
имеет высокую вычислительную сложность, и поэтому редко
применяется.  Даже полный перебор не всегда
правильно определяет вектора движения, тем более это
справедливо для быстрых алгоритмов.

  Поле векторов, найденное блочным алгоритмом определения
движения, имеет некоторые характерные свойства. А именно,
вектор движения, с большой вероятностью, найден неверно,
если:
1) ошибка определения вектора движения велика
   (поскольку это означает, что сопоставленные блоки мало похожи);
2) вектор движения значительно отличается от соседних
   векторов (следует из гладкости поля векторов  движения);
3) дисперсия блока мала (как правило, в этом случае блок мало отличается от соседних блоков).

На рисунке 1 приведен пример неправильного определения
векторов движения.

Полный текст публикации можно найти здесь:

http://graphics.cs.msu.su/ru/publications/text/gc2006ssv.pdf
http://graphics.cs.msu.su/ru/publications/text/conference9_ks.pdf


  Так что если, к примеру, двое мужчин будут тягать на зелёной лужайке перед камерой монотонно окрашенное полотнище, этот метод найдет на этом полотнище очень много достаточно забавных векторов движения.

  Такого прокола с моим методом просто по определению не может случиться, так как всё полотнище будет отсегментировано одним единым сегментом, а его движение будет проанализировано по контурным точкам, там где изображение достаточно насыщенное и сравниваемым блокам есть за что «зацепиться», ну а патом найденное смещение будет аппроксимировано на всё полотнище целиком по контурным точкам.


В прочем, мы немного отвлеклись от темы. Напомню, необходимо с помощью карты движений найти количество объектов и их границы.

EDV писал(а):В прочем, мы немного отвлеклись от темы. Напомню, необходимо с помощью карты движений найти количество объектов и их границы.

Дак вы же на 1-ом шаге описанной вами процедуры нашли количество объектов через сегментацию. Чем тут еще карта векторов поможет? Понять разве что какой объект движется одинаково с неким другим, и на основе этого можно временно или насовсем их "сцепить". Вобщем если вы опишете идею с этими векторами, вернее что из нее вы хотите получить нового, то возможно решение окажется очевидным всем.

EDV писал(а):Ну вот, всё бы хорошо, но cvCalcOpticalFlowBM это ничто иное как «block matching method», а у него есть серьёзный недостаток, ну-ка посмотрим, что тут коллеги из  МГУ пишут:

Честное слово - меня удивляет, что такие странные вещи пишут "коллеги из МГУ", они бы еще числа делить боялись, потому "что вдруг на ноль?"

Элементарный ход - установить отсечку, какие точки мы анализируем, и отсечку, - если нет явного пика совпадения, то считать, что совпадение установить однозначно не удалось и все такие точки позже определять путем комбинации усреднения окружающих векторов и проверки на совпадение. В моих опытах даже для задач 3Д-реконструкции по стереопаре у меня получались весьма интересные результаты, - http://www.roboforum.ru/viewtopic.htm?t ... &start=105, хотя объем вычислений пожалуй был больше, чем в вашем варианте (однако я не оптимизировал алгоритм почти никак).

EDV писал(а):Такого прокола с моим методом просто по определению не может случиться, так как всё полотнище будет отсегментировано одним единым сегментом, а его движение будет проанализировано по контурным точкам, там где изображение достаточно насыщенное и сравниваемым блокам есть за что «зацепиться», ну а патом найденное смещение будет аппроксимировано на всё полотнище целиком по контурным точкам.

Согласен, такого прокола с вашим методом не случится, потому что у него случится гораздо больший прокол - вы просто не поймаете правильный вектор движения там, где его легко можно поймать, а будете его рассчитывать усреднением от огромной площади.

Конечно всё зависит от желаемого вами результата. Однако используемые вами способы определения векторов движения на самом деле являются не совсем качественными и будут пропускать множество результатов, которые другими способами могли бы быть получены.

EDV писал(а):В прочем, мы немного отвлеклись от темы. Напомню, необходимо с помощью карты движений найти количество объектов и их границы.

Если использовать ваш метод - то конечно кроме различных вариаций на тему размытых контуров, опирающихся на найденные вами реперные точки - у вас ничего не найдется - просто потому что всю остальную информацию вы уничтожили по ходу обработки.

Предлагаю другой вариант - ввести оценочную функцию, которая будет показывать насколько фрагмент на одном кадре пригоден для сопоставления с фрагментами на другом кадре. То есть по сути это детектор особых точек, на которые мы будем опираться при поиске карты векторов. Это позволит явно определить все доступные нам точки.

Далее - мы получим некую размытую векторную карту, конкретизировать её предлагаю с помощью уменьшения размера анализируемой области и спуска к границам, а дальше - строим производную на векторной карте и её резкие пики - это и есть границы объектов.

GraphD писал(а):Дак вы же на 1-ом шаге описанной вами процедуры нашли количество объектов через сегментацию. Чем тут еще карта векторов поможет?

  В первом методе сегментация по карте движений выполнялась в основном по пороговому значению скорости, и такой подход хорош разве что для статического (или медленно двигающегося) фона, там где все что меньше порогового значения скорости является фоном, а всё что больше это соответственно объекты.

=DeaD= писал(а):Согласен, такого прокола с вашим методом не случится, потому что у него случится гораздо больший прокол - вы просто не поймаете правильный вектор движения там, где его легко можно поймать, а будете его рассчитывать усреднением от огромной площади.

  Вполне согласен, идеальных методов не существует  :wink:

=DeaD= писал(а):Если использовать ваш метод - то конечно кроме различных вариаций на тему размытых контуров, опирающихся на найденные вами реперные точки - у вас ничего не найдется - просто потому что всю остальную информацию вы уничтожили по ходу обработки.

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

А вот с помощью cvCalcOpticalFlowHS (Horn & Schunck algorithm) и cvCalcOpticalFlowLK (Lucas & Kanade algorithm) я и вправду не пробовал получать карту движений. Думаю, стоит попробовать и сравнить с моим способом (результаты потом выложу). Спасибо, что акцентировали внимание на других способах «optical flow» в библиотеке Intel OpenCV, сам бы мог просто не обратить внимание.

Ну что же, вот результаты обработки видеопоследовательности различными алгоритмами «Optical Flow»:

Обработка двух смежных кадров изображения:

cvCalcOpticalFlowHS (Horn & Schunck algorithm)


cvCalcOpticalFlowLK (Lucas & Kanade algorithm)


«Block matching method»  (полный перебор радиусом 4 пикселя, размер блоков 17x17, время обработки двух смежных кадров – более одной минуты)


Предлагаемый метод


Обработка трёх смежных кадров с последующим сложением полученных двух смежных карт векторов и размывом  по Гауссу:

cvCalcOpticalFlowHS (Horn & Schunck algorithm)


cvCalcOpticalFlowLK (Lucas & Kanade algorithm)


«Block matching method»


Предлагаемый метод

EDV писал(а):Ну что же, вот результаты обработки видеопоследовательности различными алгоритмами «Optical Flow»:

А можно минимальную информацию об использованных параметрах в каждом из методов?

CalcOpticalFlowPyrLK не пробовали?

=DeaD= писал(а):А можно минимальную информацию об использованных параметрах в каждом из методов?

CalcOpticalFlowPyrLK не пробовали?

cvCalcOpticalFlowHS( Img1, Img2, 0, DxVMap, DyVMap, 0.002, cvTermCriteria(CV_TERMCRIT_ITER|CV_TERMCRIT_EPS,20,0.03) );

cvCalcOpticalFlowLK( Img1, Img2, cvSize(11,11), DxVMap, DyVMap);

«Block matching method»  (полный перебор радиусом 4 пикселя, размер блоков 17x17, время обработки двух смежных кадров – более одной минуты)

CvCalcOpticalFlowPyrLK мне не подходит, там прослеживаются «features point» (CvPoint2D32f* prev_features, CvPoint2D32f* curr_features), а мне нужна карта векторов (CvArr* Velx, Vely - Horizontal and vertical component of the optical flow of the same size as input images, 32-bit floating-point, single-channel).

EDV писал(а):Ну что же, вот результаты обработки видеопоследовательности различными алгоритмами «Optical Flow»:

Обработку 5 кадров подряд пробовали? Играть параметрами?
И вообще - если выложите тестовый проектик с исходниками и данными для проверки, который можно будет быстренько перекомпилировать - будет гораздно интересней многим но это если у вас время и ресурсы позволяют.

=DeaD= писал(а):

EDV писал(а):Ну что же, вот результаты обработки видеопоследовательности различными алгоритмами «Optical Flow»:

Обработку 5 кадров подряд пробовали? Играть параметрами?
И вообще - если выложите тестовый проектик с исходниками и данными для проверки, который можно будет быстренько перекомпилировать - будет гораздно интересней многим но это если у вас время и ресурсы позволяют.

Ну конечно можно, вот выкладываю все необходимые материалы:

Тестовая последовательность:
http://edv-detail.narod.ru/training5_1.avi

Исходные тексты программы (метод выделения объектов – второй, с помощью гистограмм):
http://edv-detail.narod.ru/FragmentBitMapCompiler_07_06_07_12-35.rar

Только исходники для Visual C++ 6.0  - vc6.prj, второй проект  vc8.prj я давно не модифицировал, так что навряд ли он работать будет.

Информацию обо мне можно найти всё там же: http://edv-detail.narod.ru/

Мне кажется надо посмотреть Вам такую статейку http://research.microsoft.com/~larryz/ZitnickICCV05.pdf

Дмитрий, у меня чайниковый вопрос, можно?
Делаю по инструкции на http://edv-detail.narod.ru/Navigator_Tool_Kit.html
Однако VS при компиляции ругается:
1>Russification.cpp
1>C:\wxWidgets-2.8.1\include\wx/setup.h(142) : fataфl error C1083: Cannot open include file: '../../../lib/vc_lib/msw/wx/setup.h': No such file or directory
1>RecognitionApp.cpp
1>C:\wxWidgets-2.8.1\include\wx/setup.h(142) : fatal error C1083: Cannot open include file: '../../../lib/vc_lib/msw/wx/setup.h': No such file or directory

Я скачал несколько версий wxWidgets, но ни в одной вообще не нашёл папки vc_lib
Что не так с моим ДНК?

Добавлено спустя 2 часа 16 минут 4 секунды:
Пардон. Разобрался.
Надо было виджет ставить, согласно инструкции: http://www.rhyous.com/2009/12/16/how-to ... udio-2008/

Теперь другое горе. Ругается на строчку:
#include "cvcam.h"

И правда нет такого файла ни в виджете ни в opencv1
Или я опять глючу?

Добавлено спустя 1 час 8 минут 12 секунд:
Глючу...
Он есть в c:\Program Files\OpenCV\otherlibs\cvcam\include\

Однако..
2>..\src\RecognitionApp\RecognitionApp.cpp(1690) : error C2664: 'bool wxSizer::Remove(wxSizer *)' : cannot convert parameter 1 from 'CRecognitionPipeline *' to 'wxSizer *'
2> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
2>..\src\RecognitionApp\RecognitionApp.cpp(1723) : error C2065: 'wxSAVE' : undeclared identifier
2>..\src\RecognitionApp\RecognitionApp.cpp(1723) : error C2065: 'wxOVERWRITE_PROMPT' : undeclared identifier

Ругается на строку
// Уничтожить конвейер распознавания
mpRcgPlSizer->Remove(gpRcgPipeline);

???