Pull to refresh

Comments 12

А почему не сделали захват камеры прямо из OpenCV силами HighGUI?
Потомучто в этом случае OpenCV был бы центральной фигурой, а так программа может работать и без него, выключив слежение. Да и просто через v4l2 было интереснее, этим самым я предоставил возможность захвата изображений не операясь на довольно тяжелую библиотеку. OpenCV использует ffmpeg, ffmpeg использует API video4linux2, я просто не стал использовать посредников.
У меня при вводе видео с USB-камеры средствами OpenCV через некоторое время начинают сыпаться ошибки о corrupted JPEG'е. Со встроенными каммерами таких глюков нет. Опытным путем удалось выяснить, что сообщения об ошибке появляются на этапе чтения картинки с камеры — видимо, OpenCV не всегда понимает те JPG'и, которые поступают с камеры. Перенастроить камеру средствами OpenCV мне не удалось. Так что сейчас приходится разбираться с V4L. Спасибо автору за статью и за исходники — попробую брать картинку через V4L.

P.S.: у меня довольно специфическая конфигурация железа — веб-камера Logitech Webcam C300 подключена по USB к Nokia N900, на котором я пытаюсь обрабатывать видео средствами OpenCV. Такая вот экзотика :)
UFO landed and left these words here
Пожалуйста!
У меня ещё есть модуль для подключения к сетевым RTSP камерам, которые отдают картинку в Motion-JPEG, тоже могу написать статью, если кого-нибудь заинтересует.
UFO landed and left these words here
Да, она самая. Но управлять ей очень тяжело, по bluetooth происходит приличная задержка сигнала.
Хабр торт :)

А если по сути, мы ограничены линейкой, или к примеру в качестви линейки может выступать разметка на дороге, размеры которой нам известны заранее?
Сама линейка нам не нужна, нам нужно только знать длину обозримой дороги и видить точку её середины.
Давайте тогда рассмотрим следующую ситуацию:

— при калибровке камеры в центре рабочего поля лежит некий параллелепипед с известными размерами. Соответственно, проведя триангуляцию, мы узнаем фактический масштаб и величину перспективного искажения. Возможно ли, задаваясь такими параметрами, изменить Ваш скрипт так, чтобы он смог решить обратную задачу: определить направление и скорость смещения камеры относительно объекта в поле зрения?
Возможно. Но несколько не так.
Алгоритм оперирует всего несколькими параметрами:
l = L*K / ( W/x — 1 + K ), которые описаны выше.

При изменении угла камеры будут меняться параметры L и K (и возможно W). Их динамически из картинки не посчитать. Остаётся их только закрепить. Но мы можем менять переменную x — она определяет расстояние от камеры до объекта. То есть, если решать обратную задачу, то мы оставляем объект неподвижным, а вместо этого двигаем камеру. На рисунке это движение из положения 1 в положение 2. Мой алгоритм ограничен только одной свободой перемещения, поэтому мы можем перемещать камеру только строго параллельно «линейке»:



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

Выбор объекта в кадре можно сделать автоматическим, воспользовавшись всё из того же примера lkdemo.py функцией cv.GoodFeaturesToTrack.

То о чем Вы говорите больше походит на определения всех трёх координат камеры, а это не то, на что расчитан данный алгоритм.
Такая задача называется Camera Motion Estimation, алгоритмы её решения можно найти в сети, вот например один такой документ:
A Robust Method for Camera Motion Estimation in
Movies Based on Optical Flow
.
Only those users with full accounts are able to leave comments. Log in, please.