Підрахунок об'єктів у кадрі: де ламається точність на потоці
На тестовому ролику система підрахунку об'єктів майже збігається з ручною розміткою, а в реальну зміну рахунок розходиться. Річ не в моделі: тестовий ролик знято в зручних умовах — один ракурс, рівне світло, рідкі перекриття.
Потік на вході в цех або на прохідній поводиться інакше, і точність підрахунку на потоці визначається тим, як система переживає ці відхилення.
Перше джерело помилок — перекриття. У щільній групі детектор бачить силуети частково, і трекер або розриває один об'єкт на два, або склеює двох людей в один.
Контрове світло й нічний режим додають втрату контрасту: людина на тлі вікна перетворюється на пляму, а шум дає сплески, схожі на рух. Кожна така подія — плюс-мінус одиниця в підсумковому рахунку.
Друге джерело — хибні спрацьовування. Відблиски, відображення в склі, тіні від техніки й гойдалки гілки потрапляють у зону інтересу й враховуються як об'єкти. Підняти поріг впевненості — зростають пропуски, опустити — зростає сміття.
Тому в системі підрахунку об'єктів поріг і правила дедуплікації налаштовують не глобально, а за зонами: біля лінії перетину жорсткіше, на периферії кадру м'якше.
Облік об'єктів на відео живить звітність, тому розходження швидко стає помітним. Чергова зміна звіряє архів вручну: проганяє спірні інтервали покадрово, щоб знайти загублених двох, і витрачає на це години замість обходу. Далі система або втрачає довіру, або обростає постійною ручною правкою.
Розбираємо, як це закривається: які налаштування, зони й перевірки потрібні, щоб рахунок сходився не на демонстрації, а на всій зміні.
Що змінюється після впровадження: облік, точність, реакція служб
Ефект впровадження рахуємо не за відчуттями, а за вимірами на майданчику: беремо контрольні зміни з ручним перерахунком, розбираємо спірні епізоди й звіряємо журнал подій із цим еталоном. Так видно, де система реально знімає навантаження, а де розходження залишилося. Нижче три метрики, які замовник зазвичай бачить першими.
Частка епізодів, закритих без перегляду архіву
Кожна подія зберігається карткою: час, зона, клас об'єкта, траєкторія. Оператору не потрібно прокручувати запис — 8 із 10 спірних епізодів закриваються за карткою за хвилину замість п'ятнадцяти. Решта два потребують перегляду, і це вже усвідомлений вибір, а не щоденна рутина.
Час реакції на розходження
Подія формується в момент перетину лінії або входу в зону, тому сигнал іде в диспетчерську в ту саму зміну, а не на ранковому розборі. Розходження видно, поки його ще можна виправити: підмінити бригаду, перерахувати партію, поправити регламент завантаження. Раніше цей епізод спливав лише у підсумковому звіті, коли рішення вже нічого не змінювало.
Клас відмов, який зникає зовсім
Основне джерело недоналіку — щільний потік і короткі перекриття: люди й техніка заступають одне одного, вночі детекція провалюється. Трекер утримує ідентифікатори крізь перекриття, а підсвітка витягує нічні кадри, тому провал «загубили об'єкт у натовпі» перестає бути регулярним.
Модель на базі YOLO дообучаємо на кадрах конкретного майданчика — точність на потоці тримається, а не просідає через місяць.
Способи обліку на відео: порівняння підходів і обмежень
Точність підрахунку об'єктів у кадрі визначає не модель розпізнавання, а те, що система вважає подією: перетин межі, перебування в області або пройдений шлях. Неправильний вибір режиму дає систематичний недоналік або подвійний рахунок, який потім не лікується підбором порогів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| За лінією перетину | Створи входу, турнікети, коридори, смуги руху | Погойдування біля лінії та щільна група дають подвійний рахунок |
| За зонами перебування | Заповненість залів, паркувальних місць, ділянок | Перекриття й зміна світла зміщують межі, об'єкт залипає в зоні |
| За траєкторіями | Сцени з накладеннями, де об'єкт ведуть між кадрами | Тривале перекриття рве трек і перепризначає ідентифікатор |
| Комбінований | Кілька створів і зон в одному кадрі | Складніше налаштування, вищі вимоги до ресурсів |
Як вибирається режим під сцену
Спочатку фіксуємо, що рахуємо: факт входу, кількість одночасно присутніх або тривалість перебування.
Для створу достатньо однієї межі з контролем напрямку й підтвердженням події за кількома кадрами; для зони важливий гістерезис — об'єкт іде в облік після стійкого перебування, а не на першому торканні.
Коли в кадрі і потік, і заповненість, комбінований режим розділяє задачі: створ рахує входи, зона — поточну кількість. Загальні обмеження методів — щільні перекриття, ніч, контрове світло, відображення — знімаються підбором ракурсу, а не лише дообученням. Результат перевіряємо ручними перерахунками на коротких відрізках: видно, де шуму найбільше.
Як ми впроваджуємо систему: від аудиту камер до передачі
Етапи впровадження відеоаналітики однакові і для однієї камери на складі, і для мережі точок у залі: спочатку фіксуємо, що реально бачить камера, потім налаштовуємо правила, і лише після перевірки на минулих записах виводимо систему в експлуатацію.
Аудит умов зйомки та ракурсів
Інженер виїжджає на об'єкт і розбирає кожен ракурс: висота підвісу, нахил, контрове світло від вітрин, перекриття стелажами, зони, де об'єкти зливаються в потік.
Результат — схема розміщення камер і розмітка зон: де проходить лінія підрахунку, з якої області об'єкт не повинен виходити двічі.
Налаштування правил підрахунку та порогів
Правила формулюємо в термінах задачі: рахувати за лінією чи за зоною, як розділяти людей і візки, за якої тривалості перебування об'єкт вважається реальним, а не тінню. Пороги підбираємо на записах минулих змін — там же видно нічний режим і пікові години.
- Обстеження точок зйомки: ракурси, освітлення, сліпі зони.
- Узгодження схеми розміщення та зон підрахунку з керівником напряму.
- Розмітка ліній і областей, налаштування правил і порогів.
- Прогін на відеоархіві минулих змін і звірка з фактичними даними.
- Коригування розходжень: ракурс, пороги, розділення сцен.
- Приймання на живому потоці в пікові години.
- Передача в експлуатацію: інструкції щодо звітів, доступи, регламент обслуговування.
Що залишається у замовника: схеми, правила, регламенти
Система підрахунку об'єктів живе не в моделі, а у зв'язці «камера — зона — правило — оператор». Тому передаємо не лише працюючий сервіс, а й комплект документації, за яким ваша команда зможе експлуатувати, перевіряти й розвивати його без нас.
- Схеми розміщення камер і зон обліку — топологія точок зйомки, напрямок огляду, розмітка ліній підрахунку та областей інтересу з прив'язкою до плану об'єкта.
- Опис правил і порогів — які класи об'єктів рахуємо, як виставлені пороги впевненості, гістерезис треку й напрямок перетину лінії, і чому вибрані саме ці значення.
- Матриця типових розходжень — таблиця «симптом → причина → дія»: хибні спрацьовування на тінях, подвійний облік об'єкта, що повернувся, злипання при щільному потоці.
- Інструкція для оператора — як читати панель, що робити при розходженні з ручним перерахунком, куди ескалювати й які фрагменти запису додати.
- Регламент експлуатації — періодичність перевірки каналів і якості зображення, порядок дій при втраті потоку, оновленні прошивок камер і перенесенні точки зйомки.
- Порядок дообучення під нові сцени — як зібрати й розмітити вибірку, які метрики вважати прийнятними, як перевірити модель на еталонних записах до публікації.
- Журнал змін конфігурації — версії правил, зон і моделей із зазначенням, що змінювалося й навіщо.
Кейс на складі: помилки обліку скоротилися втричі
На складі логістичного оператора кількість одиниць під час приймання звіряли вручну, а спірні епізоди розбирали, переглядаючи архів камер.
Впровадження підрахунку об'єктів Склад-Обзор охопило вісім точок зйомки на зоні завантаження: приймання, відвантаження, комплектацію та виїзні ворота.
Що було до
Розходження за змінами сягали до 12% від добового обороту, у нічну — вище: змішане світло, палети перекривають одна одну, у кадр потрапляють одразу дві зони. Пороги спрацьовування виставлялися на око, тому система або втрачала одиниці, або рахувала їх двічі. Пошук одного спірного епізоду займав до години — перегляд архіву без прив'язки до події.
Що стало після
Ракурси розвели за зонами, для палет і коробів завели окрему детекцію, мінімальний розмір об'єкта прив'язали до одиниці обліку. Перекриття обробляються за траєкторією: об'єкт, що сховався за іншим, не рахується повторно.
| Показник | До | Після |
|---|---|---|
| Розходження за змінами | до 12% | 3-4% |
| Пошук спірного епізоду | 40-60 хвилин | до 3 хвилин |
| Час приймання фури | ~70 хвилин | ~50 хвилин |
| Епізоди з авто-підтвердженням | немає | близько 80% |
Передача результатів — не лише звіт: зміна бачить свої розходження в панелі, спірний епізод відкривається відрізком запису з відміткою часу. Регламент розбору й навчання комірників закріпили за обліковцями, щоб автоматика не сперечалася з людиною, а підтверджувала її рішення.
Як рахувати людей на вході й не плутати їх із тінями в кадрі?
Рахувати об'єкти в кадрі «в лоб» — глухий кут: тінь від портального світильника йде поруч із людиною й читається як друга ціль, відображення у скляних дверях додає третю.
Тому в підрахунку людей на вході ми фіксуємо не окремі цілі, а перетини лінії обліку всередині зони інтересу, підтверджені стійким супроводом за кадрами.
Ракурс вирішує більше, ніж модель. Камеру ставимо під кутом до лінії обліку, а не «в лоб»: тоді тінь іде вбік від осі руху й перестає зливатися із силуетом. Світильники й вітрини виводимо із зони інтересу, відображення в склі гасимо блендою та експозицією.
Виявлення людей будуємо на сімействі моделей YOLO і дообучаємо на кадрах конкретного входу — але без геометрії сцени це мало що дає.
У вузькому проході одна лінія обліку майже завжди рахує двічі: люди йдуть впритул і перекривають одне одного. Допомагає винесення лінії за «горлечко» і правило гістерезису — подія фіксується один раз на об'єкт за заданий інтервал.
Зустрічні потоки розділяємо за напрямком: вхід і вихід рахуються за знаком перетину й своєю зоною, тому одночасний рух в обидва боки не ламає баланс.
Перевіряємо не на око, а на записі складної години: проганяємо потік через налаштовану конфігурацію й звіряємо з ручним перерахунком за відрізками. Дивимося частку хибних спрацьовувань на тінях і відображеннях, розходження «увійшло мінус вийшло» та втрати при щільному потоці.
За цими вимірами правимо поріг впевненості, розмір зони й положення лінії — поки розходження з ручним рахунком не стане одиничним.
Технічні сумніви: камери, погода, перекриття й натовп
Перед пілотом замовники ставлять одні й ті самі питання: чи підійдуть уже наявні камери, що буде в дощ і сніг, чи не «злипнеться» рахунок у натовпі й як бути з постійно закритими зонами. Кожен пункт перевіряємо на записі реального об'єкта, а не на демонстраційному ролику.
Чи вистачить камер, які вже встановлені?
Зазвичай так, якщо камера дивиться на сцену зверху й дає достатню деталізацію — детектор має впевнено розрізняти межу голови. Перевіряємо це на тестовому записі типового дня: звіряємо автоматичний рахунок із ручною розміткою за ділянками. При пологому ракурсі допомагає доворот камери або один додатковий ракурс.
Що відбувається в дощ, сніг і туман?
Частіше заважає не сама погода, а мокрий об'єктив: бризки й розмиті плями модель приймає за об'єкти. Звідси вимоги до кожуха з підігрівом і навчання на нічних, снігових і туманних серіях кадрів.
При слабкій видимості рахуємо за траєкторіями — короткі пропуски відновлюються, рахунок залишається безперервним.
Як поводиться рахунок у щільному натовпі?
У щільному потоці люди перекривають одне одного, тому детекція йде по головах, а не по фігурі цілком. Ідентифікатор утримується при короткому перекритті завдяки передбаченню траєкторії — людина не рахується двічі, входячи в групу й виходячи з неї. На найщільніших ділянках рахунок ведемо за контрольною лінією, а не по всій площі кадру.
Частина сцени завжди закрита — колона, стовп, транспорт
Постійне перекриття вирішується постановкою задачі, а не моделлю: зміщуємо точку зйомки, додаємо другий ракурс або переносимо рахунок на лінію перед перешкодою.
Появу людини із сліпої зони фіксуємо як відоме обмеження в паспорті системи — оператор бачить, де цифра точна, а де потрібна перевірка.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою та планом робіт, а не із загальними словами, нам потрібен мінімум ввідних по сцені й по тому, як результат буде використовуватися.
Ці дані визначають і конфігурацію моделі, і обсяг розмітки, і те, які метрики стануть критерієм приймання — тому обговорити задачу краще до, а не після старту розробки.
- Характер сцени й типи об'єктів: статична камера чи рухома, щільність потоку, перекриття, нічні та погодні умови, що вважається одним об'єктом при частковому потраплянні в кадр.
- Доступ до записів: архів за 2-4 тижні в вихідній якості плюс кілька еталонних відрізків, на яких ви вручну знаєте правильну відповідь.
- Очікувана точність і допустимий клас помилок: що критичніше — пропуск об'єкта чи хибне спрацьовування, і яка частка розходжень із ручним підрахунком вважається прийнятною.
- Межі пілота на одній ділянці: яку ділянку беремо, на якому інтервалі часу рахуємо, хто з боку замовника звіряє результат.
- Точки інтеграції: звідки забираємо відеопотік, куди віддаємо лічильники й події, чи потрібен перегляд історії за інтервалами.
- Формат звітності: як часто і в якому вигляді потрібна зведення, чи потрібні вивантаження й наочні зрізи за зонами та годинами.
За підсумками обговорення ми фіксуємо схему розгортання й повертаємося з оцінкою та планом робіт: терміни впровадження за етапами, склад команди, порядок перевірки точності та умови переходу від пілота на одній ділянці до масштабування на решту. Опишіть задачу — повернемося з оцінкою та планом.
