Разработка системы детекции лиц (Face Detection)

Детекция лиц: где ломается на реальных кадрах

На тестовом ролике детекция лиц выглядит почти решённой задачей: ровный свет, фронтальные ракурсы, люди идут по одному — точность на видеопотоке держится около 95%. В эксплуатации тот же код на камере с плотным потоком даёт десятки ложных срабатываний за смену и заметную долю пропусков, и служба безопасности перестаёт доверять рамкам на экране.

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

Дальше подключаются сложные условия съёмки: ракурс в 60–70 градусов к оптике, мелкое лицо в глубине зала, шум ночной матрицы и артефакты сжатия. Один общий порог уверенности такие кадры не покрывает: снизишь его — растут ложные срабатывания на постерах, бликах и отражениях, поднимешь — теряешь людей в глубине кадра. Поэтому настройка идёт не одним числом, а по зонам: у входа одна планка, у турникета другая, на дальнем конце коридора третья.

Практический вывод: качество определяет не выбранная модель, а предобработка кадра, пороги под конкретные зоны, проверка на своём архиве записей и контроль регрессий после каждой правки. Это и есть работа, которая отделяет демонстрацию от системы. Дальше разбираем, как это закрывается на каждом этапе.

Измеримый эффект: скорость обработки, точность, отказоустойчивость

Пропускную способность измеряем в кадрах в секунду на один узел обработки, а не в «числе подключённых камер» — так видно, где заканчивается запас. Детектор отрабатывает каждый кадр ключевых потоков, модуль сопровождения связывает находки между кадрами, поэтому один узел держит десятки потоков без пропуска событий. Когда потоков становится больше, добавляется второй узел — логика при этом не переписывается.

Долю ложных срабатываний регулируем порогом уверенности и постфильтром: кандидаты ниже порога уходят в очередь спорных, а не в события. Метрики качества сверяем с открытым протоколом испытаний NIST FRVT, а порог подбираем на записях заказчика, а не на абстрактном наборе — поэтому точность держится на реальном освещении, ракурсах и плотности потока. На выходе — единицы ложных срабатываний на сотни событий вместо десятков.

Отдельный класс отказов — обрыв связи. Кадры и результаты детекции буферизуются на узле, у каждого события свой идентификатор, поэтому после восстановления канала накопленное уходит в архив без дублей и без «слепых» окон. Оператор видит непрерывную картину, даже если внешний канал пропадал.

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

Подходы к детекции лиц: сравнение режимов

Выбор режима детекции лиц определяется не самой моделью, а бюджетом задержки, стабильностью канала и требованиями к приватности. Один и тот же детектор даёт заметно разное качество в зависимости от того, где считается кадр и что уходит дальше по цепочке — сырое видео, координаты найденных лиц или только метаданные.

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

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

Этапы внедрения: от аудита камер до сдачи системы

Порядок работ выстроен так, чтобы качество детекции подтверждалось до ввода в эксплуатацию, а не после. Ошибки при монтаже и выборе ракурсов не компенсируются настройкой модели, поэтому начинаем с площадки, а не с кода.

1. Аудит камер. Разбираем ракурсы, высоту установки, перекрытия и фактическое освещение днём и ночью. Фиксируем, какие камеры пригодны как есть, какие нужно развернуть или досветить, а где детекция будет нестабильной.
2. Схема размещения. Определяем зоны контроля и точки монтажа так, чтобы лицо попадало в кадр целиком и анфас, а не в профиль на выходе. Схему согласуем до монтажа: перевесить камеру после запуска сложнее, чем спроектировать сразу.
3. Настройка порогов срабатывания. Подбираем порог уверенности, число подтверждающих кадров и минимальный размер лица. Выше порог — меньше ложных, но растёт доля пропусков; баланс подбираем под задачу контроля, а не «на глаз».
4. Проверка на реальном потоке. Прогоняем систему на записи за несколько суток с разной загрузкой и освещением, считаем пропуски и ложные срабатывания отдельно по каждой камере. Настройки правим, пока метрики не выйдут на согласованный уровень.
5. Регламенты и устойчивость. Описываем поведение при потере камеры, переполнении хранилища и сбое питания, настраиваем ротацию данных и оповещения о деградации. Система должна сообщать о проблеме сама, а не после разбора инцидента.
6. Передача системы. Отдаём конфигурацию, доступы и документацию, обучаем вашу службу эксплуатации. Приёмка — по метрикам из проверки на реальном потоке, а не по факту «всё запустилось».

После сдачи конфигурация остаётся открытой для правок: при изменении потока или перестановке камер пороги пересматриваются точечно.

Комплект на выходе: схемы, конфигурации, регламенты

Комплект документации — часть результата, а не приложение к нему. Мы пишем его так, чтобы инженер заказчика сам развернул контур на второй площадке, поменял зоны детекции и откатил модель без обращения к нам. Что передаём:

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

Кейс: контроль доступа в розничной сети

Сеть из нескольких десятков магазинов уже была оснащена камерами, но контроль доступа держался на людях: служебные входы и зона выдачи заказов открывались по картам, а спорные проходы разбирали вручную. Парк камер при этом оставался разнородным — от Hikvision ранних серий до более свежих моделей, доставшихся от прошлого подрядчика.

Разбор событий выглядел так: заявка от управляющего, выгрузка записей по времени, покадровый просмотр трёх потоков. На один эпизод уходило 40–60 минут, при потоке 8–12 заявок в неделю это съедало смену охраны целиком, а точной метки входа всё равно не было — приходилось искать момент прохода вручную.

Что изменили и что получили

Камеры мы не меняли: подключились к существующим потокам и откалибровали детекцию под их качество. Слабые ракурсы помечены как «требует проверки» вместо ложного срабатывания, списки разделены по ролям — персонал, подрядчики, повторные нарушения, а каждое событие ложится в журнал с временем, камерой, зоной и степенью совпадения.

После настройки разбор одного события сократился с 40–60 минут до 2–3 минут: оператор открывает карточку и видит нужный фрагмент, а не всю смену. Доля эпизодов, закрытых без ручного просмотра записи, выросла примерно до 70%, повторные проходы по чужим картам стали видны в тот же день, а ложные срабатывания на оживлённом входе срезали в разы за счёт порогов и отбора ракурсов.

Что делать, если уже развёрнута иная видеоаналитика?

Менять работающий контур целиком не обязательно. Чаще всего замена видеоаналитики идёт двумя путями: параллельный контур рядом с текущей системой или поэтапный переход по зонам. Какой из них дешевле по времени и ресурсам, зависит от парка камер и доступа к их настройкам.

Совместимость с текущими камерами проверяем до начала работ: отдаёт ли камера отдельный поток под аналитику, поддерживает ли открытый стандарт вроде ONVIF, не занят ли он существующей системой монопольно. Если прошивка закрытая и поток отдаёт только родной сервер, ставим шлюз — он забирает видео и передаёт его детекции лиц.

Переход строим по зонам: сначала одна группа камер, на ней сверяем метрики с прежней системой — пропуски, ложные срабатывания, задержку до записи в журнале. Только когда новая детекция не уступает, переводим следующую зону. Откат — возврат к прежнему потоку, поэтому старую конфигурацию сохраняем до конца перехода.

Ограничения каждого пути проговариваем заранее, а не после запуска. Параллельный контур даёт честное сравнение, но требует запаса по ресурсам, надстройка быстрее по срокам, но зависит от открытости камер.

Частые технические сомнения перед стартом

Модель детекции проверяется не на демо-стенде, а на реальных потоках: входная группа с контровым светом, склад с масками, ночная парковка с подсветкой. Ниже — сомнения, с которыми приходят чаще всего, и как мы закрываем их на этапе проектирования, а не в эксплуатации.

Что делать с ночной съёмкой и слабым освещением?

Ночью камера уходит в чёрно-белый режим с ИК-подсветкой, и это не мешает детекции: признаки лица здесь контрастные, а не цветовые. Модель прогоняем на кадрах с шумом, засветкой от фар и смазом от движения, при необходимости добавляем предобработку — выравнивание и подавление шума. Если сцена не даёт нужного контраста, говорим об этом до старта и предлагаем другую точку установки или оптику.

Какой будет нагрузка на существующее оборудование?

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

Как хранятся биометрические данные?

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

Обсудим задачу и вернёмся с оценкой и планом

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

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

Опишите задачу в свободной форме — вернёмся с оценкой сроков, этапами и составом работ. Пилотный контур запускаем первым: он даёт измеримый результат на реальном потоке и снимает риски перед разворотом на весь объект.