roboforum.ru

Здравствуйте!
Я пишу диплом, в котором мне надо расчитывать расстояния до движущихся объектов по картинкам с двух камер.
На данный момент имею следующие наработки, работающие с кадрами видео (пока без камер):

1. Анализируются два идущих подряд кадра - "предыдущий" и "текущий".
   
2. Каждый кадр предварительно обрабатывается - вычисляется разность его цвета с цветами всех его четырёхсвязных соседей (отдельно считается по каждой цветовой компоненте, затем складывается).
   
   *: это слегка обработаные изображения - чтобы было лучше видно, что получается.
3. Затем расчитывается "разница кадров". Кадры попиксельно сравниваются, и строится новая картинка (или матрица, если угодно):
   
   1. Если разница цветов между текущим и предыдущим кадрами (в этом пикселе) меньше порогового значения, в "разницу" идёт чёрная точка.
   2. Если цвет (разница цветов с соседями) на предыдущем кадре больше, то на "разницу кадров" ставится синяя точка.
   3. Иначе - красная.
4. Далее можно сделать пару операций бинарной морфологии - наращивание и эррозию. Они воспринимают красные и синие точки как белые (или как белые они воспринимают точки того цвета (кроме чёрного), к пикселю которого в данный момент применяется структурирующий элемент).

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

1. На этапе вычисления "разницы" кадров, запоминать синие и красные точки в специальных списках, чтобы потом не искать их полным сканированием изображения.
2. Списки синих и красных точек применить в операциях бинарной морфологии для поиска пикселей, к которым надо применить структурирующий элемент.
3. После окончания "издевательств" над "разницей" кадров при помощи бинарной морфологии, объединить точки, находящиеся близко друг к другу (отдельно синие - отдельно красные):
   
   1. Перебираем точки списка.
   2. Для каждой точки вычисляем расстояние до всех остальных точек (вложенный цикл идёт не от нуля, а от номера текущей точки+1).
   3. Если расстояние меньше некоторого критического, помечаем точку, как подготовленную к объединению. Если точка уже так помечена, то смотрим к кому она ближе - к той точке, с которой её планировалось объединить ранее, или к текущей. И "делаем выводы"
   4. Затем все помеченые точки объединяем. Координаты - среднее арифметическое.
4. Получаем уменьшенные списки красных и синих точек.
5. Перебираем окресности синих точек и сравниваем их с окресностями красных точек (на "производных" предыдущего и текущего кадров соответственно) и вычисляем коэффициенты схожести.
6. Смотрим - где коэффициент схожести больше - туда точка и перешла с предыдущего на текущий кадр.

Теперь основная проблема - это "коэфициент схожести" и размер окресностей точек для его вычисления. Второе - понятное дело будет установлено экспериментально. А вот с коэффициентом надо поработать. С одной стороны, он должен быстро вычисляться, с другой - допускать повороты и масштабирования.

И ещё, как мне кажется, он должен зависеть от расстояния между сопоставляемыми точками. Конечно, найти признаки, инвариантные к искажениям можно, но вероятно, мне надо будет ещё производить какие-то манипуляции, потому что я буду сравнивать не выделенные полностью объекты, а какие-то их части. И некоторые части, вероятно, будут сравниваться неоднократно (если расстояние между объединяемыми точками будет равно радиусу окресностей для сравнения, то эти окресности будут пересекаться у соседних объединённых точек).
*: Картинки пока удалил. Потом вставлю из другого видео.

Вот вам парочка ключевых слов для Google:

Optical-flow - это семейство алгоритмов вычисляющих расстояние до объектов по серии кадров;

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

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Благодарю! Завтра буду гуглить...

Google с завидным постоянством выкидывал меня на этот форум. И другие форумы, но с теми же участниками
В итоге я слегка модифицировал свою первичную обработку, чтобы она быстро происходила в OpenCV и сравнил результаты с некой вариацией на тему алгоритма =DeaD= (как я его понял):
Моё:

1. Делаем выкопировку из центра кадра с размером на 2 пикселя меньше по высоте и по ширине.
2. То же самое, но на один пиксель выше.
3. tmp = AbsDiff этих выкопировок.
4. Результат = Результат*1 + tmp*0.5
5. 2, 3, 4, но для смещения не вверх, в влево.

Моя интерпретация расчёта дисперсии (как одной из составных частей алгоритма =DeaD=):

1. Делаем гауссово сглаживание изображения (размер ядра определяет размер "окна").
2. Находим AbsDiff сглаженного и несглаженного изображений.

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

Бкдем двигаться дальше. Всем спасибо!

А результаты есть какие-то? Можно выложить? Интересно же

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Подскажите что есть готового фриварного для решения такой задачи - МК (лучше!), DSP или ПК дожен выдавать координаты точки от лазерной указки на изображении с видеокамеры. Или отклонение от центра - т.е. 2 каких дибо сигнала пропорциональный отклонению по вертикали и горизонтали.

Робоплатформа должна направляться туда куда подсвечивают лазерной указкой.

Я конечно спрашивал Google
laser dot recognition.

Но возможно есть что-то из испытаного лично или примеченого ранее.

Так там настолько просто, что никто отдельно это не делает от, скажем, получения изображения с камеры.

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

Если у вас известно направление луча на снимке (по какой линии должно быть пятно), тогда вообще тупо вдоль линии перебором можно его найти, это не более 1000 операции - для ПК это проще простого.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Результаты на данный момент такие:

Имеем три потока. Два - захватывают видео с камер и обрабатывают его, и ещё один главный, который всё это показывает.
На рисунке сверху вниз: исходные кадры; преобразованные кадры (то, что я называю "производной"); разница "производных" текущего и предыдущего кадров.
Захват у меня происходит со скоростью 15 кадров в секунду. И процессор в ноутбуке грузится на 40% - 60% на ядро. Т.е. остаётся ещё некий запас для моей машины, чтобы попытаться найти соответствия картинок на левом и правом кадрах даже в реальном времени (ну не оптимист ли я ).
Сейчас думаю над тем, чтобы сделать подставку под камеры, чтобы они жёстко в ней фиксировались. Тогда можно будет их расположить на одном уровне и направить в одну сторону. Хотя, т.к. идеал не достижим (а только он заметно упрощает дальнейшие расчёты), я скорее всего сосредоточусь на более общих методах программного поиска соответствий.
Т.к. мы живём в реальном мире, то движение объектов, заметное одной камере, будет заметно и второй камере (если объекты в поле её зрения), т.е. не получится двигаться вдоль её оси - отклонения всё равно будут. Из этого можно сделать вывод, что все изменения в левом кадре могут быть отражены на правый. И задача состоит только в том, что надо найти эти соответствия. Если учесть, что изменения от нескольких объектов могут сливаться в единую область на одном из кадров, задача несколько усложняется, т.к. надо ещё делить объекты.
PS: Битва с советской сантехникой отняла у меня весь вечер, потому на данном этапе я пока остановился.

А я думал что это просто черные экраны, ан - нет производные и их разница

Я что-то не понял, а какая задача то решается? Стереозрение обычно использую для определения расстояния, как и OpticalFlow, а у вас оно где?

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

А вот оно ещё и не сделано. Сегодня пытался прикрутить стандартные функции OpenCV для поиска аналогов участков одного кадра на втором - "в лоб" не получилось. Завтра постараюсь написать что-нибудь более "ручное".

Я сделал ещё один шаг к решению задачи расчёта расстояний до подвижных объектов.

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

• На кадре первой камеры анализируется не каждый пиксел изменившейся области, а с некоторым шагом.
• Для облегчения проверки соответствия между камерами производится сегментация исходных кадров (сейчас - обнуляю младшие половины байтов цветовых компонент).

Что не сделано, но сделать надо:

• Распаралеллить расчёт соответствия элементов кадров разных камер.
• Привести функцию сравнения в "человеческий вид".
• Сделать расширение областей соответствия волновым алгоритмом (тормозить будет жутко).
• Добавить расчёт расстояния по найденым соответствиям.

Так всё-таки система что делает? расстояние определяет или смещение сегментов между кадрами последовательными?

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

В итоге система должна определять расстояние. Просто по началу мне казалось, что один раз определив соответствие сегментов между разными камерами, потом легче бедут их вести при помощи Optical Flow. Но этот самый optical flow работает мягко говоря не очень хорошо. Хотя возможно я к нему и вернусь чуть позже.
Целью комбинации двух методов было сократить вычислительные расходы там, где это возможно.
PS: На последнем рисунке - не последовательные кадры, а кадры с двух камер. И соответствие показано между кадрами разных камер.

Результаты работы на странице http://debobaher.ru/wiki/index.php?titl ... ereoVision