Определение движения по видеосъемке
Спереди автомобиля расположена видеокамера. По съемке нужно определить наличие движения в горизонтальном направлении (скажем справа на лево), при необходимости есть доступ к информации о скорости и радиусу поворота. Причем алгоритм не должен быть слишком прожорлив, чтобы можно было обрабатывать 30 fps с двух-трех камер. В случае "стоящей" камеры все просто,а вот как в динамике это все сделать возникает вопрос....
Я пока остановился на следующих соображениях:
1. Выделяется несколько областей по-горизонтали
2. В каждой из них по-горизонтали идет усреднение изображения (R,G и B). Получаем некоторые усредненные значения по-вертикали
3. Далее делается преобразование Фурье (для получения спектральной плотности, которая не изменна при циклическом сдвиге функции, т.о. хотябы как-то "убирается" движение вверх-вниз).
4. Фиксируется всплеск спектра (пока точно не знаю как это сделать более корректно), при этом считается, что "сработала" область. Это будет означать,что кто-то или что-то резко появилось в области.
5. По комбинации "срабатывания" областей судится о направлении движения.
Но это все пока без использования скорости и радиуса поворота (которые скорей всего будут сниматься с GPS).
Буду признателен, если поделитесь своими соображениями по этому поводу
Спереди автомобиля расположена видеокамера. По съемке нужно определить наличие движения в горизонтальном направлении (скажем справа на лево), при необходимости есть доступ к информации о скорости и радиусу поворота. Причем алгоритм не должен быть слишком прожорлив, чтобы можно было обрабатывать 30 fps с двух-трех камер. В случае "стоящей" камеры все просто,а вот как в динамике это все сделать возникает вопрос....
Я пока остановился на следующих соображениях:
1. Выделяется несколько областей по-горизонтали
2. В каждой из них по-горизонтали идет усреднение изображения (R,G и B). Получаем некоторые усредненные значения по-вертикали
3. Далее делается преобразование Фурье (для получения спектральной плотности, которая не изменна при циклическом сдвиге функции, т.о. хотябы как-то "убирается" движение вверх-вниз).
4. Фиксируется всплеск спектра (пока точно не знаю как это сделать более корректно), при этом считается, что "сработала" область. Это будет означать,что кто-то или что-то резко появилось в области.
5. По комбинации "срабатывания" областей судится о направлении движения.
Но это все пока без использования скорости и радиуса поворота (которые скорей всего будут сниматься с GPS).
Буду признателен, если поделитесь своими соображениями по этому поводу
По поводу всплеска спектра - используй не Фурье, а вейвлет - преобразования. Тогда можно будет определить локализацию возмущения.
Спереди автомобиля расположена видеокамера. По съемке нужно определить наличие движения в горизонтальном направлении (скажем справа на лево), при необходимости есть доступ к информации о скорости и радиусу поворота. Причем алгоритм не должен быть слишком прожорлив, чтобы можно было обрабатывать 30 fps с двух-трех камер.
А что должно двигаться слева направо? Встречный автомобиль или машина должна скользить? Для чего имеются три камеры и как они расположены?
И самое интересное: как решить проблему стоящих неподвижно предметов? То есть, машина А движется навстречу машине В по дороге, обсаженной кустами. Относительно машины А движутся и машина Б, и кусты. Хуже того, если В движется строго навстречу А, то относительно А она визуально не движется (в горизонтальном направении), а увеличивается.
И самое интересное: как решить проблему стоящих неподвижно предметов? То есть, машина А движется навстречу машине В по дороге, обсаженной кустами. Относительно машины А движутся и машина Б, и кусты. Хуже того, если В движется строго навстречу А, то относительно А она визуально не движется (в горизонтальном направении), а увеличивается.
Ну двигаться слева направо или справа налево могут автомобили на перекрестке (с перпендикулярных направлений), пешеходы (основная цель алгоритма). Поэтому встречный и попутный транспорт можно убрать из рассмотрения.
На самом деле камер будет до 8-ми, на крыльях, на бампере,на зеркалах.Но пока этот вопрос не решен, располагаться будут там,где удобнее для алгортма. Определение движение как раз бутет по 2-м,3-м, остальные для других целей.
Ага. Детектор пешеходов. Ну, уже интереснее.
Осталось объяснить это программе. Я бы использовал или определение формы, или детектор скорости. На заметку: пешеход, который рискует быть сбит машиной, относительно последней имеет нулевую угловую скорость (именно на этом принципе работают локационные системы самонаведения). Это можно легко проверить при переходе дороги в неположенном месте. :)
А зачем по 2-м,3-м? Почему сразу решили, что одной недостаточно? Могу предположить, что это связано с недостаточным полем зрения одной камеры. Тогда для боковых камер придётся решать интереснейшую задачу отделения пешеходов от кустов по угловой скорости. Кстати, для центральной камеры тоже придётся решать эту задачу.
А не мог бы ты объяснить, что значит отделить пешеходов от кустов по угловой скорости? Насколько я помню, это первая производная от угла...:) Я в ннавигации не силен, занимаюсь дистанционным зондированием...
Если по условию задачи дорогой является ВПП на аэродроме - тогда да, это работает. Если по услови задачи допускается и дорога в горах (как правило, очень извилистая), то это решение работать не будет. Опять же, поле зрения становится очень малым. Вот нам и противоречие.
Вкратце, это первая производная от угла, но дело не совсем в этом. Если речь идёт о детекторе пешеходов, то задача - слделать так, чтобы машина на пешехода не наехала. Наехать она может только в одном случае - если относительно машины пешеход будет двигаться с нулевой боковой составляющей, сиречь с нулевой угловой скоростью (для полярной системы координат). Поэтому в этом конкретном случае разумнее всего отбрасывать подвижную часть картинки и оставлять неподвижную. Две камеры можно попутно использовать для измерения расстояния (по принципу дальномера).
А что, по вашему, это меняет? Например, та же листва обладает в разное время разным коэффициентом отражения, да ещё и в зависимости от длины волны. Так, в коротковолновой ИК-зоне листва выглядит почти белой.
Или речь идёт о тепловизорах? Тогда там другие тонкости, особенно если тепловизор цветной.
Или речь идёт о тепловизорах? Тогда там другие тонкости, особенно если тепловизор цветной.
Всех тонкостей я не знаю, сказали, что предоставят нормалную картинку. А идея в следующем: будет несколько ИК-диодов, и фильтр для его длины волны, грубо говоря будет что-то вроде лучей, нужно будет отследить их "прерывание" на препядствиях.
ТЗ я понял плохо, поскольку ни единого раза его не читал. Следовательно, затрудняюсь подсказать что-нибудь по сути дела. :)
Да заказчик сам его никак не доформулирует как следует :) так что пока курю бамбук...:)
Вот как доформулирует, поделись. Попробую подсказать что-нибудь, мне тоже интересно.
Жду )
mailto:aerarh@rambler.ru
Будем ждать. Задачка интересная )
преобразовать кадры в векторную форму .
если скорость камеры равномерна сместить векторную форму вектором движения , иначе нужно или знать вектора камеры на каждый кадр , или подбирать эксперементально .
обрезать кадры для корректного сравнения .
сравнить .
если отклонения больше статистической погрешности - значит в кадре что-то двигалось .
2)аналогично делается с синфазными кадрами (когда кадры выполнены в одной фазе движения камеры)
А из-за перспективы кадры разве не будут сильно различаться? Тогда надо учитывать и ее.
Но тут еще несколько проблем возникает:
1. придется всеже учитывать скорость движения
2. скорость обработки будет низковатой...камеры наверно будут с 60fps, если хотябы из них 30 обработать,будет не плохо, хотя я сомневаюсь что получиться, если придется совмещать кадры.
3. Определить наличие движения не достаточно, надо определить направление, в кадр может попасть опережающая машина