roboforum.ru

Сабж: результаты работы с видеоизображением.

Сюда постепенно буду выкладывать алгоритмы и методы, которые показали свою эффективность и могут оказаться полезными не только в общеобразовательном плане, но и прикладном.

Выкладка во многом получиться "задом-наперёд", и многие причины почему так, а не иначе, по умолчанию буду упускать (пояснять только по надобности).

Предполагаеться, что полученое изображение - RGB-матрица, размером W x H точек. Кроме того, камера, с помощь которой выполняеться сьёмка прокалибрована, тоесть извесно соответствие между координатоми точки на матрице и углом, под каким падает световой пучёк, воздействующий на соответствующий светочувствительный элемент матрицы.

Ннуууу же..... ? мы все ждем

=DeaD= писал(а):Ннуууу же..... ? мы все ждем

Застопроилось дело. Теория выдохлась, нужно экспериментировать на реальной, боевой технике
Сделано:
Разработана методика калибровки положение на матрице - угол (довольно точная, несложна в воспроизведении в домашних условиях)
Разработана методика калибровки чувствительности элементов матрицы, выделение значение от освещённости (малополезна в прикладном плане, т.к. требует специального оборудования поэкпериментирую с несколькими образцами, возможно, накопив статистики придумаю что-то более реальное в воспроизведении)
Разработана методика калибровки динамической погрешности элементов матрицы. (довольно точная, несложна в воспроизведении в домашних условиях)
После выполнения калибровок:
Правильно находит контуры, иногда и зоны видимости в общем (особенно хорошо видит контуры/зоны медленнодвижущихся объектов)
Нивелирует градиенты (даже неравномерные)
Ниверирует блики/засветку (только на цветных матрицах, на чёрно-белых - глухой вариант)
Не очень боиться отражений - либо принимает за блик, либо правильно пределяет длинну хода луча (но "понять", что это зеркало, тем более где оно, пока не способно)
Нивелирует motion blur (динамическую погрешность матрицы)точнее, умеет использовать для определения перемещения - но не всегда срабатывает правильно.
Определять расстояния поточечно (соответственно, группировать в объекты с одинаковой скоростью, определять их скорость относительно камеры и т.д.) срабатывает не всегда, много ошибок (особенно в зонах контуров).  :(  :(
Не получилось совсем:
Следить за быстродвижущимися объектами (шумы матрицы и низкая её дискретность портят всю картину до невозможности )
Научить автокалиброваться - знаний/времени не хватает
Распознавать ошибки распознавания - верит всему, что насчитало, потому и обламываеться регулярно. (не получаеться найти критерий достоверности - продолжаю копаться).

Пробы велись на цифровых фотографиях и фрагментах AVI-шек.

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

Интересует отработка объектов с большим спектром расстояний - типа "ковер на полу" - работает?

=DeaD= писал(а):Интересует отработка объектов с большим спектром расстояний - типа "ковер на полу" - работает?

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

Последний заработавший вариант:
Есть FIFO-буфер, в который складируються кадры (более-менее работать начинает с буфером в 50-60 кадров, но чем больше тем лучше работает) в виде BMP RGB 8бит/цвет. FPS фиксированный.
Прим: ИЦ - интенсивность цвета, число которое получаем с АЦП камеры для каждой из составляющих цвета.
Обязательно нужно знать:
1) мин. ИЦ и макс. ИЦ для каждой точки (оказываеться, (8-битных) камерах мин. значение немного больше нуля, макс. значение немного меньше 255, и у каждого пиксела разное).
2) функциональную зависимость ИЦ от освещённости (так же для каждого пиксела, тоже оказываеться разное).
3) динамическая погрешность (функциональная зависимость ИЦ за кадр от разницы между текущим значением ИЦ и действительным - как правило, зависимость линейная, но опять же, для каждого пиксела разная)
Прим: всё это отноститься к каждой составляющей (тоесть для красного зелёного и синего каждого пиксела все эти параметры свои, индивидуальные так сказать).
4) зависимость угол обзора от координат для каждого пиксела.
5) изменение положения камеры для каждого кадра

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

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

ПС: алгоритм пока не подходит для обработки в реал-тайм, реальная продуктивность 0.3 FPS для BMP RGB24 320x240 на P4 2.4GHz. код написан на ТМТ Паскаль (корявый, стыдно выкладывать )

Пункт 2 - что такое зоны с одинаковыми тенденциями?

С точки зрения камеры, на картинке присутствуют два типа объектов: движущиеся относительно камеры и неподвижные отностиельно камеры.

Для движущихся характерной чертой есть размытость контуров. Даный алгоритм очень хорошо "отлавливает" зоны, где один объект закрыл/открыл собой другой между двумя соседними кадрами, при условии, что они достаточно отличаються ИЦ какой либо составляющей, и зона перекрытия не слишком большая. Прямым ходом используеться motion blur, уже с пользой для дела. Кстати, если поверхность объекта имеет фактуру, и разрешающей способности камеры хватает её "разглядеть", то это очень хорошо - расстояние до этой поверхности вычисляеться довольно точно. Это-же относиться и к градиентным заливкам - они тоже воспринимаються как фактуры (а группировка то идёт по расстояниям ). Если же поверхность одноцветна (с точки зрения камеры), то алгоритм там видит сквозную "дырку" (то есть зону, в пределах которой расстояние до поверхностей очень велико). В прочем, таких казусов на практике втречалось довольно немного (да и человек если не в курсе, что там что-то есть, реагирует так же ).

Неподвижные объекты
Это всё равно что пытаться построить 3Д картинку по одному кадру, ничего не получиться (наверно неспроста природа наделила нас двумя глазами). По этому вся работа с изображением с одной камеры возможна лишь при условии, что каринка движеться.

Засветка пиксела (блик)
Боремся довольно просто. Прямо в алгоритме отслеживаем тенденцию изменения ИЦ, и если получаеться, что по тенденции ИЦ в таком-то кадре должно составить/превысить ИЦмакс этого пиксела в следующем/предыдущем, и значение ИЦ в следующем/предыдущем кадре равно ИЦмакс, то полагаем, что произошла засветка пиксела, и работаем с вычисленным ИЦ. Естественно, что постоянно засвеченная неподвижная зона считаеться "дыркой", но контуры засветки вполне помагают - их ведь алгоритм воспринимает как контуры обьекта.

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

Это я все понял, тенденцией то что считается? какой параметр?

=DeaD= писал(а):Пункт 2 - что такое зоны с одинаковыми тенденциями?

Возьмём один из ИЦ (обозву его Y) какого либо пиксела, просмотрим его изменение на протяжении всего буфера (номер кадра обозву X, нумерация кадров в хронологической последовательности). Допустим, Y изменяеться (точнее, он должен изменяться, иначе ничего не получиться) в течении X. Имеем протабулированную функцию Y=F(X). Что делаем дальше: полагаем, что некотором отрезке Х1...Х2 так что (X1<X2) функция описываеться выражением:
Y(X1...X2)=Y0+DY*exp((X-X1)*k)
где к - коефициент, который характеризирует динамическую погрешность даного ИЦ. Так вот, разбиваем Х на отрезки, на которых експериментальные точки ложаться на эту кривую наилучшим образом (как критерий я использовал коефициент корреляции, хотя ИМХО это не наилучший вариант). Так, для одного ИЦ мы получим несколько (как правило не более двух) комплектов параметров: X1, X2, Y0, DY. Так вот, зонами с одинаковой тенденцией я называю пикселы, чьи параметры X1, X2 отличаються не более чем на единицу, а  DY не более чем на амплитудное значение шума матрици. Зона с одинаковой теннденцией, это область изображения, которая изменяеться в определённый промежуток времени в соответствии с дин. погрешностью матрицы.

Вот! Сразу бы так просто и понятно.

А почему вдруг интенсивность должна меняться по закону f(x)=a*e^(bx)+с ? Это чем-то обосновано теоретически, или так просто получилось?

Да, забыл сказать - перед поиском этих зон нужно исправить нелинейность матрицы (см.п.2 необходимой информации), если её не исправить, то экпоненциальный закон изменения конечно не "натянеться" на имеюшиеся ИЦ. Кроме того, когда ищем Х1, Х2 не забываем, что если нам встречаеться ИЦмакс, а на основе предыдущих/последующих даных получаеться что в этой точке аппроксимированное значение может быть ИЦмакс и выше, то и его тоже его тоже добавляем в эту зону. Тогда Х2 предыдущей зоны, и Х1 последующей берём из пересечения аппроксимационных функций (если, конечно такое получаеться).

=DeaD= писал(а):А почему вдруг интенсивность должна меняться по закону f(x)=a*e^(bx)+с ? Это чем-то обосновано теоретически, или так просто получилось?

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

Хм, а вы когда исправляли нелинейность матрицы случайно сами не создали этот закон?

=DeaD= писал(а):Хм, а вы когда исправляли нелинейность матрицы случайно сами не создали этот закон?

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

ПС: не исключено, что эти манипуляции некоторые камеры выполняют самостоятельно, но на всякий, стоит проверить.