к.т.н. Руцков М.В.

 

 

Видеодетекторы пять лет спустя

(часть четвёртая)

 

 

Вы уж меня извините товарищи дорогие, что в предыдущих публикациях скатился на два ВидеоХлама. А что делать? Надо ж как-то бороться с глупостями всяческими. Всё делу время, потехе час! Продолжим. В третьей части была обещана структурная схема, которая, в некотором роде, олицетворяет идеологический подход к построению истинно охранного видеонаблюдения, а не тупого архивирования! Получите!!! Лишь за одно прошу простить   этакую фривольность  в плане рукотворных фантазий. Ну, нет у меня времени на освоение разнообразных рисовалок. А что, может быть и стильно получилось в духе времени, так сказать! Каждый лепит как может!    

 Думаю, всё понятно. Изображения от камер проходят через базовые детекторы - три MD (точный, средний, грубый) и один SDD.  Далее с помощью масок и индивидуальных настроек формируются Виртуальные Детекторы - VD (до 32-х для каждого канала). Следует отметить, что ресурсы системы не работает в холостую - соответствующий детектор активируется только в том случае, если он задан хотя бы в одном VD. Всё это хозяйство "замешивается" с помощью булевой алгебры в тревоги (до 128-ми). Сигналы от внешних устройств (датчиков) тоже участвуют.

Таким образом, имеем некое подобие первичной зрительной системы человека, в которой действует набор полосовых фильтров на разные случаи жизни. Точный фильтр отслеживает мелкие детали, подавляя низкочастотные и среднечастотные флуктуации изменения, связанные, например, с перекрытием и открытием солнца облаками. Средний фильтр хорошо отсекает мелкие объекты, скажем машины, которые попадают в кадр, но находятся на заднем плане вдалеке. Ну, а грубый фильтр просто убивает всю мелочь, детектируя только крупные объекты. Причём справляется даже с вибрацией самой камеры.

   Реализация тревог как функций булевой алгебры тоже имеет свои прелести. Приведу лишь пару примеров. Например, можно запрограммировать объёмное детектирование, когда несколько камер смотрят на один объект с разных точек, а тревога вырабатывается лишь при единовременном срабатывании всех соответствующих виртуальных видеодетекторов логическая функция И. По тревоге можно задать любое действие: запись в архив изображений от любых камер, звуковое оповещение, всплывающее окно, активация внешнего устройства и т.д.

А вот более экзотический способ, когда все виртуальные детекторы расположены в кадре от одной камеры. Рассказываю в ролях:

Прибегает ко мне мой партнёр импортный и взахлёб начинает вещать о том, что, мол, со страшной силой нужна технология распознавания мотороллерных номеров! Если кто другой (нехороший) на моём месте был, то сразу бы спросил Сколько?. Но мы ведь гуманоиды, отнюдь! Поэтому мой вопрос прозвучал несколько иначе Зачем?.  Тогда он рассказал мне грустную историю, о том, что хулиганы-подростки на мотороллерах въезжают в парковые зоны не путать с парковкой! А там вроде могут только мамы с детьми прогуливаться. Да уж проблема! Ну, тогда говорю: Молодец, здорово придумал, а если они перед въездом тряпочку на номер накинут?. Он так изумился:  Думаешь сообразят?.  А то! Хотя не знаю, как ваши дети, а наши влёт!. Очень он расстроился и спрашивает: Что делать?. Не волнуйся говорю, Это наш истинно русский вопрос! Всё очень просто решение уже заложено. Установи камеру сверху. Если мамы с детьми в парк заходят, то они как бы в ширину располагаются (за руки держатся), а мотороллер в длину вытягивается. Возьми, хотя бы три зоны нарисуй (в нашей системе можно задавать произвольные зоны детекции) встык по направлению въезда и меж ними функцию И организуй, тогда только длинномерные объекты детектироваться будут. Нет, конечно, ежели кто заход будет в танце делать Летку-Енку исполняя, то извини. Однако, это маловероятно. Короче, всё он сделал, как предписывалось очень эффективно оказалось, хотя честно признаюсь, алгоритм на ходу сочинил.

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

Теперь займёмся настройками детекторов. В начале несколько штрихов с идеологическим уклоном. Сейчас снова глянем на основное окно настройки канала. Так вот, идеология такова кручу настройки - тут же вижу! Если камера физически подключена, то в центральном окошке появляется живое видео. Но не в первозданном виде, а уже после компрессии - фрэймы жмутся влёт, тут же распаковываются и выводятся на экран. Фактически мы видим то, что будет записано в архив. Под изображением - ползунок, который задаёт степень компрессии. Двигая, его можно визуально оценить качество картинки. Тут же (справа) высвечивается объём видеоданных в килобайтах. Ну, скажем, задвинем мы ползунок резко влево (снижение качества и объёма данных) - мгновенно получим характерные JPEG--лапти! Далее, есть возможность в режиме on-line подстроить - яркость, контрастность и цветовые компоненты (вертикальные ползунки справа от окна). Можно вывести гистограмму яркости. По ней сразу видно - куда мы загнали видеосигнал. Ручка яркости позволяет его отцентрировать, а контрастности - раздвигать-задвигать. Для очень ленивых можно просто включить режим "Коррекция гистограммы" (в нижнем правом углу окна настройки) - она сама будет подстраиваться, что очень полезно для видеонаблюдения в режиме outdoor, на улице значит! Вот такие чудеса! Тот же принцип - on-line настройка применён и для видеодетекторов. Задаём различные настройки и сразу видим - что детектируется и не посыпались ли ложные срабатывания.

 

 

 

Итак, переходим к настройкам базовых видеодетекторов. Начнем с MotionDetection - MD  или Детектор Движения. Это хозяйство находится в верхнем левом углу окна настройки и выглядит следующим образом. 

Есть индивидуальные настройки для каждого полосового детектора: грубый, средний, точный и общие - целиком для канала. Начнём с общей настройки, которая имеет интригующее название - "Адаптация". Само по себе движение - это смещение контуров объектов за определённый период времени. Минимальный интервал величиной в 20 мс получим при темпе обработки (для ТВ-систем)  50 поле/с (real-time). Много это или мало - сразу и не понятно. Ведь объекты в реальной жизни могут двигаться в широчайшем диапазоне скоростей. Например, пролетающая птица имеет очень высокую скорость - она сначала "отпечатывается" в одном месте кадра, а потом в совершенно другом, т.е. за 20 мс преодолевает расстояние в несколько раз превышающее её собственные размеры. Фактически у нас получается не смещение контуров, а их появление и пропадание. Вот если бы у нас была камера на 1000 fps и более, то естественно контуры были бы где-то рядом. Именно эта особенность и используется в "Фильтре Низких Скоростей". Но об этом чуть позже.

Итак, из простой логики мышления ясно, что для работы алгоритмов детектирования движения требуется некое эталонное изображение и текущее! И они каким-то образом сравниваются. В дубовых системах просто берут да вычисляют межкадровую разность. Что из этого получается - уже писал. Алгоритм перестаёт ловить медленные объекты. Ну, например, диверсант в маскхалате тихонечко проползёт зону контроля - и тишина!!! Можно конечно обрабатывать каждый пятый, десятый кадр..., тем самым, увеличив интервал времени для сравнения фрэймов. В результате начнём зевать быстрые движения. Тогда начинается придумывание разнообразных линий задержки, параллельных процедур с индивидуальными интервалами времени. Всё растёт как снежный ком - получается дурдом! Однако мы пошли совсем другим путём. Есть такое понятие - фон сцены, нечто неподвижное. Но он не может стоять как вкопанный с момента включения - всё плавно меняется. Вот тут-то и появляется термин Адаптация. Фактически это время, за которое изменения на изображении перерастают в фон! Если диверсант двигается быстрее, чем его изображение адаптируется к фону - то мы его поймаем!!! Например, в окошке установлено значение 10 секунд. Значит товарищ в маскхалате, с целью обмана системы, должен за это время сместиться на расстояние, не вызывающее отличий между эталонным и текущим кадром, достаточных для срабатывания детектора. Вот и спрашивается - а дурно ему не станет?

Теперь приступим к изучению параметра "Порог". Как видно из кусочка окна настроек порог устанавливается для каждого MD-детектора индивидуально. Это и понятно - шумы и помехи на изображении обычно смещены в верхнюю часть спектра пространственных частот. Значит для точного детектора их (шумов и помех) пролезет сквозь соответствующий полосовой фильтр больше, чем через средний и тем более - грубый. Однако у последних своя песня - и связана она с флуктуациями общего освещения. Глобальными: облака с солнцем играют и грубо-локальными - фонарь качается. В общем, требуется индивидуальный подход. Теперь пара слов о самой процедуре детектирования, поскольку до сих пор мы говорили лишь о полосовой фильтрации. А она фактически выделяет контуры объектов. Так вот, мы имеем некий эталонно-фоновый кадр и текущий. Между ними выполняется - и не вычитание, и не сравнение, а некое сопоставление. Оно представляет собой сугубо нелинейную операцию, подсмотренную у нейронов живой природы, и является нашим ноу-хау! Могу лишь сказать, что отслеживаются позиции контуров. На месте - отдыхаем, сместились - тревога! Поэтому алгоритм выдерживает даже 100-герцовую пульсацию люминесцентных ламп при значениях шаттера камеры выше 1/50 cекунды (полное накопления). После процедуры сопоставления рождается полутоновое изображение, которое режется на уровне заданного "Порога". Чем меньше это значение - тем выше чувствительность и хуже помехоустойчивость. В окне живого видео те области, в которых "Порог" был превышен (наблюдалось движение или активность) - отмечаются красными точками. Причём в режиме on-line - двигаете ползунок и тут же всё видите. Ну и пара слов о конкретных значениях параметра "Порог" - исходя из практического опыта. Для точного детектора в режиме outdoor (камера снаружи) рабочий диапазон - 10-15. В режиме indoor можно сместиться на 3-5 единиц вниз. Для среднего и грубого детекторов значения могут быть ещё меньше. А вообще всё зависит от конкретной сцены.

Далее рассмотрим параметр "Шумоподавление". Сразу скажу - вещь нетривиальная! Забегая вперёд, отмечу, что для каждого из 32-х возможных виртуальных детекторов можно выставить индивидуальный порог срабатывания. Что сие означает? Попробую пока на пальцах. Итак, следствием детекции являются "красные точки" на экране. Мы их подсчитываем и смотрим - превышен ли порог? Если да, то конкретный виртуальный детектор срабатывает. Допустим, идёт человек, "облепленный красными точками", число которых колеблется в районе 10-ти (так оптика выбрана). А вот если авто поедет, то их будет уже в районе 30-ти. Собачка пробежит - 5-ть от силы. И всё бы хорошо - если объект один! Поставил порог -  15 и лови себе только машины. А теперь представим - стая ворон пролетела, каждая из которых родила по 1-2 "красные точки"! Вот вам псевдоавто и проехало! С шумами и помехами - аналогичная история! Ну, тогда - "давить" будем! Если ползунок "Шумоподавление" установить на "1", то будут убиты все изолированные "красные точки", если на "2" - погибнут ещё и 2-связанные точки (в квадратном растре, каждый пиксел имеет 8 соседей - 8-связность) и т.д. Фактически идёт проверка на локальность возмущающего воздействия (движения), что и соответствует реальным объектам! А вообще, сама идея шумоподавления пришла во время работы над SDD - Детектор Оставленных/Унесённых Предметов. Долго бился с тенями от зданий, которые медленно смещались, вызывая ложные срабатывания. Причём все они выстраивались в цепочку по контуру тени. Так вот, "Шумоподавление" со значением "3" убило их - наповал! 

Перейдём к функции "Фильтр Низких Скоростей" - SlowSpeedFilter (SSF). Ну, прежде всего, чтобы путаницы не было - объясняю. Фильтр пропускает именно низкие скорости, а высокие - давит. Теперь о скорости, - в каких единицах её измерять? Если в классических - "метры в секунду", то толку будет мало! Мы не можем её оценить с помощью лишь одной камеры. Например, машина на скорости более 100 км/час в глубине сцены будет перемещаться по экрану монитора медленнее вашего пальца, который вы будете двигать в полуметре от объектива! Тогда уместно использовать термин "угловая скорость", т.е. на какой градус объект смещается в единицу времени. Естественно возникает незатейливый вопрос - а зачем нам всё это надо? Отвечаю - для борьбы с высокоскоростными (в угловом исчислении) помехами! Того не легче! Объясняю на реальных примерах мошкара, которая вьётся прямо перед объективом или снежные хлопья, пролетающие на таком же расстоянии. Причём снежинка на экране монитора может быть крупнее самосвала - разные масштабы! А есть и реально быстрые объекты - птицы, например. Всё это вызывает ложные срабатывания видеодетектора. Как бороться? Вот тогда и пришла в голову идея "Фильтра Низких Скоростей". Как это работает, подробно рассказывать не буду опять же ноу-хау! Так вот, смысл заключается в том, что в настройках задается не значение скорости (угловой), а её обратный аналог - время (в миллисекундах). Если объект шустрый - он усевает за заданное время сместиться на "приличное расстояние" (в пикселах) и, тем самым, игнорируется. Однако, лучше один раз увидеть. Вот вам демо-клип - снято с собственного балкона на 12-ом этаже. Заданное время составляет 400 мс. Трудно заранее рассчитать этот параметр. Но у нас есть режим настройки в on-line - меняете время и всё сразу как на ладони! Кстати, данная технология прекрасно справляется со светом фар от приезжающих машин. Свет от них бьёт в окна, вызывая светопреставление внутри охраняемого помещения. Думаю, вам в голову придут и другие вариации использования сего алгоритма.

Итак, с  MotionDetection MD, вроде закончили. В следующий раз займёмся SlowDownDetection SDD или Детектором Оставленных/Унесённых Предметов.

  

Об авторе: Руцков Михаил Вадимович, кандидат технических наук, гендиректор  MegaPixel Ltd.,

e-mail:  megapixel@tochka.ru тел. (495)4129422

 

Rambler's Top100