Розробка системи трекінгу об'єктів на відео (Object Tracking) під ключ

Чому трекінг об'єктів зривається на реальному відео

На демонстраційному ролику супроводження виглядає бездоганно: об'єкт проходить через кадр, рамка тримається рівно, ідентифікатор не змінюється. На бойовому потоці та сама модель розсипається за кілька хвилин.

Причина в тому, що детектор оцінює кожен кадр окремо, а трекінг об'єктів на відео — це задача про зв'язки між кадрами, і рвуться насамперед саме зв'язки.

Помилки супроводження повторюються зі сцени в сцену. Об'єкт заходить за колону, кузов або іншу машину — і після виходу з перекриття отримує новий ідентифікатор, а попередній залишається висіти на тіні.

При зміні ракурсу рамка дрейфує по фону й чіпляє сусідній об'єкт, через що дві траєкторії склеюються в одну. Уночі хибні спрацювання детектора на відблиски, відображення та фари дають десятки коротких траєкторій там, де пройшов один об'єкт.

Окрема історія — втрата об'єкта в кадрі: вона майже ніколи не збігається з моментом зникнення. Супроводження зривається за секунди до нього, коли об'єкт сповільнюється, змінює напрямок або зливається з фоном.

За галузевими наборами на кшталт MOT Challenge видно, наскільки лабораторна якість розходиться з бойовою: різниця в частці правильних ідентифікаторів вимірюється десятками відсотків.

Обчислюється це не картинкою, а подіями. Розірвана траєкторія або перетворюється на зайве спрацювання, або втрачає подію цілком, і рішення ухвалюється за неповною картиною.

Далі розбираємо, як це закривається: від вибору моделі під конкретну сцену до логіки зіставлення та перевірки траєкторій.

Що дає система відеоаналітики: вимірювані ефекти

Ефект перевіряємо метриками, знятими на вашому об'єкті до й після запуску: частка пропусків, розриви треків, час реакції чергової зміни, обсяг ручного перегляду архіву. Демонстрація на чужому відео нічого не доводить — рахуємо на ваших записах, включно з нічними змінами.

Менше пропусків об'єктів

Частку пропусків рахуємо на розміченій вибірці з ваших записів, розбираючи її за сценаріями: щільний потік, поодинокі об'єкти, краї кадру. Пороги впевненості детектора й трекера підбираємо під сцену — для щільного потоку та дрібних рідкісних об'єктів вони різні. На виході отримуємо стійкі трек-ID: видно, скільки об'єктів пройшло через зону.

Стійкість до перекриттів

Трек не рветься, коли об'єкт заходить за колону або в натовп: зіставлення йде за зовнішнім виглядом і передбаченням траєкторії, а не лише за позицією на кадрі.

Розриви треків рахуємо окремою метрикою — кожен розрив перетворюється на подвійний рахунок подій і зайві спрацювання чергової зміни.

Слабке світло та нічні зміни

Уночі частина кадру втрачається через шум і засвітку, тому налаштовуємо передобробку кадру й режим підсвічування. Якщо сцена фізично не покривається, система позначає зону як непокриту, а не видає хибні події.

Способи трекінгу об'єктів: порівняння та обмеження

Вибір способу трекінгу визначає не точність моделі, а те, як поводитиметься система в реальній сцені.

Покадрове супроводження зіставляє рамки між сусідніми кадрами й тримає траєкторію, поки об'єкт видно; наскрізна ідентифікація додає ознаку зовнішності й відновлює зв'язок після перекриття, розвороту або виходу з кадру.

Помилка на цьому рівні коштує найдорожче: один розірваний трек дає зайві події та завищений лічильник.

Як вибираємо режим під сцену

Рішення ухвалюється за трьома вхідними: скільки об'єктів одночасно в кадрі, як часто вони перекривають один одного й чи є вимога тримати відео всередині контуру замовника.

На магнітно-логічних задачах (підрахунок входу, зони) достатньо покадрового супроводження — воно дешевше за обчисленнями й передбачуваніше в налаштуванні. Наскрізну ідентифікацію вмикаємо точково, лише на камерах, де розрив треку спотворює результат.

Гібридна схема — первинний трекінг на локальному контурі, а звірка й агрегація в хмарі — знімає обмеження обох варіантів: на майданчик ідуть лише події та метадані, а не сирий потік.

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

Як ми впроваджуємо відеоаналітику: етапи робіт

Перш ніж писати код, ми з'ясовуємо, з якими даними доведеться працювати: ракурси камер, перепади освітлення, щільність потоку, типи об'єктів. Порядок робіт однаковий для складу, периметра й торговельної зали — змінюються зони контролю та логіка подій.

1. Аудит відеоархіву. Дивимося записи з кожної камери в різні години й за різної погоди: пересвітлення, взаємні перекриття, тремтіння кадру. На виході — перелік камер зі стійкою картинкою та точки, де потрібне виправлення розстановки.
2. Розмітка сцен. Позначаємо цільові об'єкти, хибні цілі та проблемний фон: відблиски, тіні, відображення у вітринах, рух гілок. Пропуск етапу обертається перенавчанням уже після запуску.
3. Калібрування зон контролю. Лінії та області прив'язуємо до реальної геометрії майданчика, а не до пікселів — при зсуві камери зона залишається коректною. Перевіряємо, що об'єкт не «стрибає» між зонами на межі.
4. Налаштування порогів спрацювання. Підбираємо час перебування в зоні, мінімальний розмір об'єкта й кількість підтверджувальних кадрів: зникають спрацювання на птаха, що пролітає, і на перехожого поряд із зоною.
5. Перевірка на історичних записах. Проганяємо готову конфігурацію по архіву за різні зміни й рахуємо частку хибних подій і пропусків, а не оцінюємо «на око».
6. Приймання системи. Вимірюємо точність на живому потоці в години пік і фіксуємо показники в протоколі. Передаємо регламенти: як додати камеру, оновити зону, розібрати спірну подію.

Кожен етап закінчується перевірюваним артефактом — звітом, налаштованим профілем, протоколом приймання. Тому конфігурацію можна повторити на другому майданчику, а не збирати заново.

Склад постачання: конфігурації, схеми зон, регламенти

Після введення в експлуатацію в замовника залишається не лише працююча система, а й повний комплект артефактів, за якими її можна експлуатувати, розширювати й передавати іншій команді.

Конфігурації та правила зберігаються в репозиторії з історією змін — видно, хто й коли змінював параметри під конкретну камеру та навіщо.

• Конфігурації детектора й трекера по кожній камері: ракурс, зона інтересу, пороги чутливості, поведінка при перекриттях і зупинках.
• Схема зон контролю: розмітка зон і ліній, напрямки перетину, пріоритет зон, прив'язка до плану об'єкта.
• Правила спрацювань: що вважається подією, вікна придушення повторних повідомлень, умови склейки спостережень одного об'єкта в один трек.
• Схема інтеграцій: приймання відеопотоків, публікація подій у зовнішні системи, вивантаження фрагментів і метаданих для розбору.
• Документація на систему: архітектура, словник подій, опис параметрів та їхнього впливу на якість трекінгу, порядок калібрування.
• Регламент чергової зміни: реакція на кожен тип події, що перевіряти перед ескалацією, які дії не виконуються без інженера.
• Передача системи: приймальні сценарії, навчання операторів і служби експлуатації, точка входу для доопрацювань.

Такий комплект знімає залежність від підрядника: виправлення зон або зміну правил можна доручити іншій команді, не відновлюючи логіку за кодом.

Кейс: скоротили хибні спрацювання на складі втричі

Майданчик — розподільчий склад із навантаженням у чотири доки та щільним потоком техніки: навантажувачі, тягачі з напівпричепами й пішоходи ділять одні й ті самі проїзди.

Система має фіксувати в'їзд і виїзд, контролювати зайнятість зон розвантаження й знаходити людей у небезпечній зоні. До нас на майданчику працювала покадрова детекція: кожне спрацювання моделі йшло в окрему подію, без прив'язки до об'єкта в часі.

Що було до впровадження

За зміну накопичувалося понад 40 хибних спрацювань. Причина — відсутність зв'язку між кадрами: навантажувач, що заїхав за штабель, зникав і з'являвся знову, і система відкривала по ньому другу подію.

Тіні від сонця, відображення на мокрому бетоні й відблиски від фар давали «об'єкти», яких фізично не було. Оператор до середини зміни перестав реагувати на сигнали, а розбір спірних ситуацій ішов за окремими кадрами — довести щось за ними було неможливо.

Що змінили й що отримали

Трекінг побудували поверх виявлення: об'єкту присвоюється ідентифікатор, який зберігається при перекриттях і коротких зникненнях з кадру. Правила прив'язали до зон і напрямку руху — подія з'являється, лише якщо трек стійко тримається в зоні довше порога.

Техніку й людей рахуємо різними правилами, оцінка йде на модулях NVIDIA, тому всі потоки обробляються без пропуску кадрів.

За перший місяць експлуатації: хибні спрацювання впали з 40+ до 12–14 за зміну, частка пропущених порушень — нижче 2%, затримка від події до сигналу оператору — 1–2 секунди.

Журнал треків зберігається 30 днів, тому спірний випадок розбирається за фрагментом з ідентифікатором, а не за вирваним кадром.

Що робити, якщо камери й архів уже розгорнуто?

Міняти парк камер не потрібно. Аналітика підключається до тих потоків, які камери й реєстратори вже віддають у мережу, тому запис продовжує йти своїм ходом, а трекінг працює паралельно на окремому обчислювальному вузлі й нічого не перехоплює в наявній схемі.

Ключовий момент — розділення потоків. Трекінг забирає потік зниженої роздільності й працює за ним, а потік основної якості залишається на запис в архіві, тому якість і глибина зберігання не просідають.

Якщо камера не віддає окремий потік, аналітику ставлять на копію основного через окремий мережевий інтерфейс, щоб відеореєстратор не втрачав кадри.

Різні виробники камер і реєстраторів зводяться до єдиного входу через профілі сумісності ONVIF, а для закритих моделей потік знімається прямо з реєстратора — так рішення не прив'язується до однієї марки обладнання.

З архівом працюють у двох режимах. Живий трекінг пише події в спільну із записами шкалу часу: мітки синхронізуються, і об'єкт у треку збігається з об'єктом в архіві до частки секунди — пошук ведеться за маршрутом і ознаками, а не за ручним перемотуванням.

За вже накопиченим архівом запускається окремий перерахунок: він читає записи порціями й не конкурує із записом нових даних, тож глибина зберігання й цілісність старого масиву не страждають.

Впровадження йде поетапно. Спочатку пілот на кількох камерах, де заміряємо точність трекінгу й навантаження на мережу та диски; потім хвилями підключаємо зони, починаючи з тих, де ефект помітний одразу.

Відкат простий: вимикається вузол аналітики, а камери й архів продовжують працювати в попередньому режимі — наявну систему спостереження ми не ламаємо.

Часті технічні питання та обмеження

Сумніви на етапі оцінки майже завжди про межі: як система поводиться в щільному потоці, у темряві, при перекриттях і на вже встановлених камерах. Нижче — короткі відповіді інженерів, без маркетингових обіцянок: там, де в методу є межа, ми говоримо про це до старту.

Що зі слабким освітленням і перекриттями?

Модель дообучаємо на записах конкретного майданчика: ніч, тіні та відблиски від фар дають більше помилок, ніж нестача світла як така. Коротке перекриття закриваємо передбаченням позиції за попередніми кадрами — трек переживає прохід за колоною й відновлює ідентифікатор.

Чи потрібно міняти камери на об'єкті?

Як правило, ні: працюємо з потоком, який уже віддають камери замовника за відкритими стандартами, а на слабких моделях оцінюємо достатність якості зйомки до підписання. Вузькі місця за оглядом фіксуємо у звіті з обстеження, щоб не з'ясовувати їх на прийманні.

Хто відповідає за хибні спрацювання?

Цільові метрики узгоджуємо заздалегідь і перевіряємо на відкладеній вибірці записів замовника, а не на показових роликах. Під час здачі розбираємо помилки за джерелами — детектор, утримання треку чи правила подій — і правимо той шар, де вони виникають.

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

Щоб обговорити задачу предметно, а не загальними словами, нам потрібен від вас мінімум: кілька відеозаписів з реальних камер — із тим світлом, ракурсами й щільністю сцени, у яких система працюватиме.

Плюс короткий перелік об'єктів, які потрібно розрізняти, і що вважається подією: перетин лінії, поява в зоні, втрата супроводження.

Цього достатньо, щоб порахувати навантаження й зібрати план впровадження під ваш контур — без довгого листування й припущень навмання.

У відповідь ви отримуєте пакет, за яким можна ухвалювати рішення:

• Технічну оцінку: досяжну точність супроводження на ваших записах, вузькі місця сцени (перекриття, щільний потік, ніч), класи відмов і що з ними робимо.
• План впровадження з етапами, порядком робіт і точками, де ви приймаєте результат.
• Межі робіт: що входить у нашу зону, а що залишається на вас або на підряднику по камерах і серверах.
• Схему потоків даних — від захоплення кадру до події у вашій обліковій системі.
• Вимоги до зйомки й майданчика, якщо частина проблем вирішується налаштуванням камер, а не кодом.
• Критерії приймання: показники, за якими ми разом перевіримо результат на записах, що не брали участі в налаштуванні.

Опишіть задачу в зручній формі — записи, потрібні об'єкти, куди мають іти події. Повернемося з оцінкою, планом і зрозумілими межами відповідальності, і вже за ними ви вирішите, чи стартуємо.