Детекція облич: де ламається на реальних кадрах
На тестовому ролику детекція облич виглядає майже вирішеною задачею: рівне світло, фронтальні ракурси, люди йдуть по одному — точність на відеопотоці тримається близько 95%.
В експлуатації той самий код на камері з щільним потоком дає десятки хибних спрацювань за зміну й помітну частку пропусків, і служба безпеки перестає довіряти рамкам на екрані.
Перша точка відмови — зустрічне світло: контрове світло з вулиці або з вікна випалює половину обличчя, локальний контраст падає, і детектор втрачає контур там, де людина ще впізнавана.
Друга — рух: змаз на швидкому кроці й розсинхрон між кадрами зсувають рамку, трекер втрачає ціль і видає нову людину замість тієї самої. Третя — маски, капюшони, окуляри й руки біля обличчя, які закривають саме ті ділянки, за якими модель ухвалює рішення.
Далі підключаються складні умови зйомки: ракурс 60–70 градусів до оптики, дрібне обличчя в глибині залу, шум нічної матриці й артефакти стиснення.
Один загальний поріг впевненості такі кадри не покриває: знизиш його — зростають хибні спрацювання на постерах, відблисках і відображеннях, піднімеш — втрачаєш людей у глибині кадру.
Тому налаштування йде не одним числом, а за зонами: біля входу одна планка, біля турнікета інша, на дальньому кінці коридору третя.
Практичний висновок: якість визначає не вибрана модель, а передобробка кадру, пороги під конкретні зони, перевірка на власному архіві записів і контроль регресій після кожної правки. Це і є робота, яка відрізняє демонстрацію від системи. Далі розбираємо, як це закривається на кожному етапі.
Вимірюваний ефект: швидкість обробки, точність, відмовостійкість
Пропускну здатність вимірюємо в кадрах за секунду на один вузол обробки, а не в «кількості підключених камер» — так видно, де закінчується запас.
Детектор відпрацьовує кожен кадр ключових потоків, модуль супроводу зв’язує знахідки між кадрами, тому один вузол тримає десятки потоків без пропуску подій. Коли потоків стає більше, додається другий вузол — логіка при цьому не переписується.
Долю хибних спрацювань регулюємо порогом впевненості й постфільтром: кандидати нижче порога йдуть у чергу спірних, а не в події.
Метрики якості звіряємо з відкритим протоколом випробувань NIST FRVT, а поріг підбираємо на записах замовника, а не на абстрактному наборі — тому точність тримається на реальному освітленні, ракурсах і щільності потоку. На виході — одиниці хибних спрацювань на сотні подій замість десятків.
Окремий клас відмов — обрив зв’язку. Кадри й результати детекції буферизуються на вузлі, кожна подія має власний ідентифікатор, тому після відновлення каналу накопичене йде в архів без дублів і без «сліпих» вікон. Оператор бачить безперервну картину, навіть якщо зовнішній канал зникав.
Ручний перегляд записів як процес прибирається: людина дивиться лише спірні випадки, решта закривається автоматично. Час на перевірку падає з годин за зміну до кількох хвилин розбору винятків — і це той самий ефект, що й раніше, тільки без постійного спостерігача біля монітора.
Підходи до детекції облич: порівняння режимів
Вибір режиму детекції облич визначається не самою моделлю, а бюджетом затримки, стабільністю каналу й вимогами до приватності.
Той самий детектор дає помітно різну якість залежно від того, де рахується кадр і що йде далі ланцюжком — сире відео, координати знайдених облич або лише метадані.
На старті проєкту вибір зводиться до чотирьох схем. Різниця між ними не «краще чи гірше», а різні компроміси між затримкою, навантаженням на канал і точністю на щільних сценах.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Обробка на пристрої | Об’єкт із нестабільним каналом; кадри не повинні покидати периметр | Слабкий обчислювач: нижча частота обробки, просідає точність на щільних сценах і за слабкого світла |
| Серверна відеоаналітика | Кілька камер, потрібна реакція в реальному часі | Постійне навантаження на обчислювач і канал, чутливість до просідань мережі |
| Пакетна обробка архіву | Розбір записів за минулий період, звірка, звітність | Немає реального часу: результат з’являється лише після прогону |
| Гібридна схема | Детекція на об’єкті, повторна перевірка відібраних кадрів на сервері | Складніша синхронізація метаданих і версій детектора на пристроях |
На практиці частіше зупиняються на гібридній схемі: пристрій віддає лише події та вирізані кадри, а важка перевірка й зберігання залишаються на сервері.
Канал перестає забиватися потоковим відео, а точність на складних кадрах зростає — за умови, що версії детектора на пристроях і на сервері сумісні й оновлюються узгоджено.
Етапи впровадження: від аудиту камер до здачі системи
Порядок робіт вибудуваний так, щоб якість детекції підтверджувалася до введення в експлуатацію, а не після. Помилки під час монтажу й вибору ракурсів не компенсуються налаштуванням моделі, тому починаємо з майданчика, а не з коду.
- Аудит камер. Розбираємо ракурси, висоту встановлення, перекриття й фактичне освітлення вдень і вночі. Фіксуємо, які камери придатні як є, які потрібно розвернути або досвітлити, а де детекція буде нестабільною.
- Схема розміщення. Визначаємо зони контролю й точки монтажу так, щоб обличчя потрапляло в кадр повністю і анфас, а не в профіль на виході. Схему узгоджуємо до монтажу: перевісити камеру після запуску складніше, ніж спроєктувати одразу.
- Налаштування порогів спрацювання. Підбираємо поріг впевненості, кількість підтверджувальних кадрів і мінімальний розмір обличчя. Вищий поріг — менше хибних, але зростає частка пропусків; баланс підбираємо під задачу контролю, а не «на око».
- Перевірка на реальному потоці. Проганяємо систему на записі за кілька діб із різним навантаженням і освітленням, рахуємо пропуски й хибні спрацювання окремо по кожній камері. Налаштування правимо, доки метрики не вийдуть на узгоджений рівень.
- Регламенти й стійкість. Описуємо поведінку при втраті камери, переповненні сховища й збої живлення, налаштовуємо ротацію даних і оповіщення про деградацію. Система має повідомляти про проблему сама, а не після розбору інциденту.
- Передача системи. Віддаємо конфігурацію, доступи й документацію, навчаємо вашу службу експлуатації. Приймання — за метриками з перевірки на реальному потоці, а не за фактом «все запустилося».
Після здачі конфігурація залишається відкритою для правок: при зміні потоку або перестановці камер пороги переглядаються точково.
Комплект на виході: схеми, конфігурації, регламенти
Комплект документації — частина результату, а не додаток до нього. Ми пишемо його так, щоб інженер замовника сам розгорнув контур на другому майданчику, поміняв зони детекції й відкотив модель без звернення до нас. Що передаємо:
- Схема відеопотоків — джерела, точки підключення, резервні маршрути й поведінка при зникненні каналу: буферизація, перепідключення, оповіщення чергового.
- Конфігурація системи — параметри по кожній камері (зона інтересу, пороги чутливості, інтервал аналізу) винесені в окремі файли, а не вшиті в код.
- Політики доступу до даних — ролі й матриця прав, розділення біометрії та подієвих метаданих, терміни зберігання, порядок вивантаження за запитом.
- Регламент експлуатації — що перевіряти за змінами, які метрики вести (частка хибних спрацювань, пропуски кадрів) і за яких значень ескалювати.
- Інструкції для операторів — типові сценарії: камера недоступна, хибне спрацювання, зміна зони детекції, підключення нового джерела.
- Картка моделі — версія, дані навчання, методика оцінювання точності й спосіб донавчання на нових умовах зйомки.
- Порядок оновлень і відкату — як випускається нова версія, хто погоджує, за який крок повертаємося, якщо метрики просіли.
Кейс: контроль доступу в роздрібній мережі
Мережа з кількох десятків магазинів уже була оснащена камерами, але контроль доступу тримався на людях: службові входи й зона видачі замовлень відкривалися за картками, а спірні проходи розбирали вручну.
Парк камер при цьому залишався різнорідним — від Hikvision ранніх серій до новіших моделей, що дісталися від попереднього підрядника.
Розбір подій виглядав так: заявка від керівника, вивантаження записів за часом, покадровий перегляд трьох потоків.
На один епізод ішло 40–60 хвилин, при потоці 8–12 заявок на тиждень це з’їдало зміну охорони цілком, а точної позначки входу все одно не було — доводилося шукати момент проходу вручну.
Що змінили і що отримали
Камери ми не міняли: підключилися до наявних потоків і відкалібрували детекцію під їхню якість.
Слабкі ракурси позначені як «потребує перевірки» замість хибного спрацювання, списки розділені за ролями — персонал, підрядники, повторні порушення, а кожна подія лягає в журнал із часом, камерою, зоною і ступенем збігу.
Після налаштування розбір однієї події скоротився з 40–60 хвилин до 2–3 хвилин: оператор відкриває картку й бачить потрібний фрагмент, а не всю зміну.
Частка епізодів, закритих без ручного перегляду запису, зросла приблизно до 70%, повторні проходи чужими картками стали видні того ж дня, а хибні спрацювання на жвавому вході зрізали в рази за рахунок порогів і відбору ракурсів.
Що робити, якщо вже розгорнуто іншу відеоаналітику?
Міняти робочий контур цілком не обов’язково. Найчастіше заміна відеоаналітики йде двома шляхами: паралельний контур поруч із поточною системою або поетапний перехід за зонами. Який із них дешевший за часом і ресурсами, залежить від парку камер і доступу до їхніх налаштувань.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Паралельний контур | Потрібно порівняти якість на живому трафіку, не зупиняючи сервіс | Подвійне навантаження на мережу й сервери, в операторів два інтерфейси |
| Поетапний перехід | Заміна за зонами або групами камер | У перехідний період дані лежать у двох сховищах, потрібна звірка |
| Надбудова над поточними камерами | Парк камер міняти не планується | Закриті прошивки з пропрієтарним доступом потребуватимуть шлюзу |
Сумісність із поточними камерами перевіряємо до початку робіт: чи віддає камера окремий потік під аналітику, чи підтримує відкритий стандарт на кшталт ONVIF, чи не зайнятий він наявною системою монопольно.
Якщо прошивка закрита і потік віддає лише рідний сервер, ставимо шлюз — він забирає відео й передає його детекції облич.
Перехід будуємо за зонами: спочатку одна група камер, на ній звіряємо метрики з попередньою системою — пропуски, хибні спрацювання, затримку до запису в журналі. Тільки коли нова детекція не поступається, переводимо наступну зону. Відкат — повернення до попереднього потоку, тому стару конфігурацію зберігаємо до кінця переходу.
Обмеження кожного шляху проговорюємо заздалегідь, а не після запуску. Паралельний контур дає чесне порівняння, але потребує запасу за ресурсами, надбудова швидша за строками, але залежить від відкритості камер.
Часті технічні сумніви перед стартом
Модель детекції перевіряється не на демо-стенді, а на реальних потоках: вхідна група з контровим світлом, склад із масками, нічна парковка з підсвіткою. Нижче — сумніви, з якими приходять найчастіше, і як ми закриваємо їх на етапі проєктування, а не в експлуатації.
Як система працює з масками та закритими обличчями?
Маска перекриває частину ключових точок, тому детектор спирається на видиму зону — лінію брів, перенісся, контур голови й пропорції. Модель донавчаємо на розмічених кадрах із медичними й респіраторними масками, а поріг впевненості налаштовуємо під сценарій окремо.
Там, де потрібна лише фіксація присутності людини, вимоги до ракурсу помітно нижчі, ніж при ідентифікації.
Що робити з нічною зйомкою та слабким освітленням?
Уночі камера переходить у чорно-білий режим з ІЧ-підсвіткою, і це не заважає детекції: ознаки обличчя тут контрастні, а не колірні. Модель проганяємо на кадрах із шумом, засвітленням від фар і змазом від руху, за потреби додаємо передобробку — вирівнювання й придушення шуму.
Якщо сцена не дає потрібного контрасту, говоримо про це до старту й пропонуємо іншу точку встановлення або оптику.
Яким буде навантаження на наявне обладнання?
Навантаження рахуємо за кількістю потоків і частотою обробки: зазвичай достатньо аналізувати частину кадрів, а не весь потік цілком. Вивід моделі розміщуємо поруч із камерою або на загальному сервері — за результатами заміру на вашій сцені, а не за паспортними цифрами. Наявні камери найчастіше підходять: критична не модель, а стабільність кадру й ракурс.
Як зберігаються біометричні дані?
За замовчуванням ми зберігаємо не зображення, а математичні шаблони — вектори ознак, з яких обличчя не відновити. Терміни задає політика: події та позначки часу живуть обмежений період, шаблони — до відкликання згоди.
Доступ розмежований за ролями, дії потрапляють у журнал, а за вимоги локального контуру рішення розгортається у вашій інфраструктурі без виходу даних назовні.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб повернутися з оцінкою проєкту й планом впровадження, нам потрібно зрозуміти майданчик і сценарії — детекція облич на папері й на конкретному об’єкті розходяться сильно. Зберемо вихідні дані, зафіксуємо критерії якості й визначимо обсяг пілотного контуру. Нижче — що для цього знадобиться.
- Схема майданчика: кількість зон контролю, точки встановлення камер, перекриття, сходи й «сліпі» ділянки, де людина проходить поза полем зору.
- Джерела відео: власні камери або чинна система спостереження, як віддаються потоки, хто відповідає за доступ і права на записи.
- Сценарії: прохід на об’єкт, підрахунок відвідувачів, пошук за архівом, сигнал на заборонену зону — що запускаємо першим, а що залишаємо на другий етап.
- Умови зйомки: освітлення вдень і вночі, щільність потоку, головні убори й окуляри, ракурси, за яких обличчя видно частково.
- Інфраструктура: де розміщуємо обчислення — на об’єкті або в захищеному контурі, які канали зв’язку доступні, скільки зберігаємо кадри й розмітку.
- Правила обробки: вимоги до зберігання біометричних даних, терміни, ролі доступу до результатів, порядок знеособлення.
- Пілотний контур: одна зона й один сценарій, на яких перевіряємо точність і хибні спрацювання на ваших кадрах до масштабування.
Опишіть задачу у вільній формі — повернемося з оцінкою строків, етапами та складом робіт. Пілотний контур запускаємо першим: він дає вимірюваний результат на реальному потоці й знімає ризики перед розгортанням на весь об’єкт.
