Компьютерное зрение для детекции аномальных событий в видеопотоке: методы и вызовы
Компьютерное зрение уже давно вышло за пределы лабораторий. Ритейл, тяжёлая промышленность, добывающий сектор – везде камеры начинают работать не просто как видеорегистраторы, а как полноценные аналитические инструменты. За несколько лет мы накопили внушительный пул таких задач: детектирование средств индивидуальной защиты (СИЗ) на крупных производствах, контроль изменения цвета жидкости в сепараторе, расчёт гранулометрического состава.
Когда проектов накопилось достаточно, мы решили сделать коробочное решение – продукт, который можно быстро развернуть под типовые требования заказчика. Назвали его «Лонч». Начали приходить запросы, которые поначалу выглядели стандартными, а на деле оказались куда интереснее: задетектируйте ДТП, определите, когда лошадям вводят допинг. Оба кейса шли в параллель, переплелись между собой, и вместе дали нам понимание, что мы вообще делали не так.
Детектируем ДТП – всё выглядит здорово, пока не смотришь под капот
Первый запрос – от иностранных коллег, которые строят «умный город». Им нужна система, которая сама детектирует дорожно-транспортное происшествие и мгновенно уведомляет оператора, не требуя, круглосуточного нахождения у монитора.
Задача понятна. Подход очевиден. Берём модель YOLO, обучаем на датасете с ДТП, получаем бокс вокруг столкнувшихся машин. На демо вау-эффект есть: машинки столкнулись, что-то задетектировалось, боксы появились. Вроде работает.
Но стоит посмотреть, что происходит под капотом, и картина становится значительно менее радужной. Главная проблема – огромная вариативность самого события. Машины разные: большие, маленькие, разных цветов, в разных положениях. Углы камер тоже разные. Освещение разное. Паттернов бесконечное множество, датасет нужен колоссальный, разметка стоит денег и времени. Обучили модель на одном перекрёстке, хотим тиражировать. В ходе проверки выяснилось, что в другой локации она работает плохо, потому что там всё другое: другие углы, другое освещение, другие паттерны. Принимаем вызов, обучаем на третьем перекрёстке, потом на четвёртом. А потом пришла зима, зимние паттерны снова не те, начинаем сначала.
Этот процесс становится буквально бесконечным: постоянно добираешь датасет, постоянно размечаешь, постоянно обучаешь. Датасет разрастается, вычислительные мощности упираются в предел. Мы осознали проблему достаточно рано и начали думать, как поменять сам подход.
Параллельно: скачки, допинг и вопрос «за что зацепиться?»
Пока мы ломали голову над ДТП, пришёл второй запрос от другого заказчика. Специфика деятельности — организация скачек лошадей. Многие участники используют допинг для лошадей – это запрещено. Наша задача состояла в следующем – задетектировать факт введения допинга с камер видеонаблюдения.
Первый вопрос, который мы задали себе: за что зацепиться? Естественно, никто на камеру не вводит инъекцию лошадям, все пытаются этот факт скрыть. Детектировать шприц? Он маленький, его прячут под покрывало лошади, его почти не видно даже если специально смотреть.
Мы начали внимательно изучать видеоматериал и обнаружили кое-что интересное. В момент введения инъекции лошадь резко начинает качать головой. Объяснений два: во-первых, резко повышается пульс, во-вторых, она реагирует на болевые ощущения от укола. Вот это уже можно детектировать. Именно тут мы сформулировали для себя разницу между двумя принципиально разными подходами.
Детектирование объекта vs детектирование события
Обычная модель детектирования – это ответ на вопрос «что это?». Нейросеть смотрит на кадр и говорит: вот машина, вот лошадь, вот каска. Детектирование события — это ответ на вопрос «что произошло?». Для ответа нужно смотреть не на один кадр, а на последовательность.
Архитектура такого подхода состоит из двух этапов. Классический детектор объектов, от него никуда не деться, потому что нам нужно за чем-то следить. Второй – постобработка. Именно там живёт логика, которая анализирует поведение объекта во времени и говорит, произошло событие или нет.
Фильтр Калмана, ускорение и одно правильное решение при разметке
Начали применять подход в кейсе с лошадьми. Размечаем датасет – голова лошади и туловище. Зачем туловище —об этом чуть позже, но это решение нас потом здорово выручило. Детектор находит объекты на каждом кадре, дальше подключается трекинг.
Трекинг реализован через фильтр Калмана. Он берёт данные с предыдущего кадра — позицию и скорость объекта — и предсказывает, где объект окажется в следующем. Получает новый кадр — корректирует прогноз. Так объект не теряется и мы получаем историю его перемещения во времени.
Дальше — школьная физика. Есть перемещение и время, находим скорость. Есть скорость в двух точках, находим ускорение. Резкое движение головой — это резкий скачок ускорения. Подбираем порог: превысило — фиксируем событие. Логика железная и… первая бейзлайн-модель не работала.
Ложных срабатываний было очень много. Причина выяснилась быстро, когда лошадь идёт, ускорение её головы складывается из двух составляющих — ускорение самой головы плюс ускорение туловища. Лошадь просто идёт и кивает в такт шагам, может войти в резонанс и выйти за порог.
Вот тут и пригодилось туловище в разметке. Мы проанализировали кучу видеоматериала и убедились, что инъекцию на ходу никто не делает. Это неудобно и слишком заметно. Добавляем простое условие: если скорость туловища отличается от нуля — лошадь идёт, детектирование движения головы отключаем. Стоит — включаем.
Ложные срабатывания исчезли. Теперь событие «введение инъекции» детектируется легко: лошадь стоит, включается режим надзора, лошадь уходит – никаких срабатываний, несмотря на движение головы.
Возвращаемся к ДТП. Снова всё идёт не так
Разобравшись с лошадьми, мы решили применить тот же подход к детекции ДТП. Логика казалась безупречной, при столкновении у машины тоже резко меняется ускорение. Меняем детектор (теперь автомобили вместо лошадей), оставляем трекинг, пересчитываем пороги срабатывания под другие скорости. Запускаем. Не работает.
Проблема первая: призрак нулевой скорости.
Машина транзитом проезжает перекрёсток с постоянной скоростью, но в момент первого обнаружения объекта его скорость для модели равна нулю, ведь еще нет истории этого объекта, но через несколько кадров скорость уже есть. С точки зрения алгоритма машина «резко разгоняется» из нуля – хотя просто въехала в кадр и продолжает движение. Решение в целом простое, добавляем «охлаждающий» период — считаем скорость не сразу, а через несколько кадров после обнаружения.
Проблема вторая: обычная городская езда.
Даже с «охлаждением» ложные срабатывания остаются. Водитель засмотрелся в телефон, увидел красный, резко по тормозам, кто-то, наоборот, торопится и резко ускоряется. Порог по ускорению почти невозможно откалибровать так, чтобы отличить это от реального ДТП.
Решение: угол траектории как второй признак
Мы вернулись на шаг назад и начали искать другой паттерн – при столкновении помимо ускорения резко меняется траектория движения. Угол направления машины скачет непредсказуемо, чего не происходит при обычном торможении или разгоне.
Алгоритм следующий: берём вектор направления машины в первой точке трека, берём вектор во второй, вычисляем угол между ними. Добавляем как второе условие к ускорению, и теперь детектор начинает работать адекватно.
В итоге все объекты детектируются, и когда у машины одновременно фиксируется резкое ускорение и резкое изменение угла траектории, срабатывает триггер и оператору уходит уведомление. Это всё, что нужно было заказчику: не предотвращать ДТП, а быстро о нём узнавать.
Грабли, которые встретятся на пути
Часть проблем я описал выше, но есть еще и системные, которые стоит зафиксировать отдельно.
1. Частота кадров не менее 25 в секунду.
При работе с трекингом каждый кадр важен: трекер может потерять объект, если между кадрами слишком большой разрыв. В задачах без трекинга, например, детектирование брака на конвейере, можно брать каждый пятый-шестой кадр. Здесь нельзя. Хорошая новость, что обычные игровые видеокарты сегодня спокойно справляются с обработкой полного потока в реальном времени.
2. Перекрытие объектов.
Когда один объект перекрывает другой, происходит сразу два неприятных эффекта. Первое, что трекер может потерять или перепутать объект. Второе – ложные срабатывания, так как детектируемый бокс резко уменьшается, центральная точка объекта смещается, алгоритм интерпретирует это как резкое ускорение. Лучший способ борьбы – это правильное расположение камеры ещё на этапе проектирования.
3. Количество кадров между точками расчёта.
Параметр неочевидный, но критически важный. Слишком маленький интервал и алгоритм «дрожит» из-за шума: боксы детектора не статичны, у центральной точки есть естественная вибрация. Слишком большой — событие можно пропустить. Взяли первую точку, пик прошёл, взяли вторую точку уже после и всё, событие потеряно. Этот параметр подбирается вручную под каждую конкретную задачу.
Вместо заключения
Детектирование событий не то же самое, что детектирование объектов. Несколько вещей, которые стали для нас очевидными после этих кейсов.
Рекомендация №1: здесь не обойтись без естественного интеллекта. Прежде чем строить любую модель, нужно провести анализ и найти паттерны, которые реально характеризуют событие. Никакая нейросеть сама не догадается, что лошадь качает головой при инъекции, а машина меняет угол траектории при ударе, это формулирует человек.
Рекомендация №2: событие должно рассматриваться только в видеопотоке. По одному кадру нельзя сказать, что произошло. Лошадь, которая смотрит вверх, и лошадь, которой только что ввели укол, на стоп-кадре выглядят одинаково.
Рекомендация №3: от детектора объектов никуда не деться. Событие анализируется через поведение объекта, а значит сначала объект нужно найти и не потерять.
Рекомендация №4: поиск подходов – ключевая часть пайплайна. Нам надо найти технический подход, который подтвердит гипотезу и решит задачу.
Будем реалистами, ничего нет совершенного. Лёгкое касание бамперов может не выйти за порог. Человек, который уколет лошадь прямо во время движения (теоретически такой найдётся) создаёт слепое пятно. Но в реальных задачах «близко к идеалу» чаще всего и означает «работает на практике».
