Трекинг и реидентификация между камерами

Это инженерное руководство, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.

Кратко

Трекинг объектов – это аналитика, которая связывает обнаруженный объект из одного кадра видео со следующим, чтобы система перестала видеть каждый кадр нового незнакомца и вместо этого вела один непрерывный «трек» – того же человека или машину, момент за моментом, с устойчивым номером. Реидентификация (re-ID) – куда более трудный шаг: узнать тот же объект снова на другой камере, которая его никогда не видела, сверяя сигнатуру внешнего вида, а не лицо и не номер. Вместе они позволяют системе ответить «куда этот человек ходил по всему объекту?» – что огромно полезно для поиска по архиву и анализа маршрутов, и одновременно момент, когда небиометрическое видео тихо превращается в профиль перемещений с реальным весом для приватности. Статья объясняет, как работают трекинг и re-ID, честный разрыв в точности между слежением на одной камере и между многими, как трек попадает в Video Management System (VMS) через стандарт ONVIF Profile M, и где проходит юридическая граница между «следить за красной курткой» и «опознать Ивана Петрова».

Зачем это нужно

В момент, когда покупатель спрашивает «а сможет она проследить человека от парковки до погрузочной?», он оставил позади детекцию объектов и вошёл в трекинг и реидентификацию – и разрыв между демо и реальным внедрением здесь шире, чем почти где-либо ещё в наблюдении. Трекинг на одной камере зрел и работает прямо на камере; межкамерная реидентификация – задача исследовательского уровня, резко деградирующая с расстоянием, светом и временем, и вендор, называющий вам одно число точности, это скрывает. Статья написана для системного интегратора, руководителя розницы или продакт-менеджера, которым нужно разумно сформулировать требования к межкамерному трекингу, понять, что он может и чего не может обещать, и – критично – осознать, что трасса перемещений это персональные данные даже без привязанного имени. Старший видеоинженер найдёт метрики и стандарты корректными; но письмо служит сначала неспециалисту.

От детекции к треку: что добавляет трекинг

Начнём с того, что идёт до трекинга, потому что трекинг строится прямо поверх этого. Как разобрано в статье детекция и классификация объектов в видеонаблюдении, детектор смотрит на один кадр и рисует маркированную рамку вокруг каждого объекта – «человек тут, машина там». Но у детектора нет памяти. Запустите его на 30 кадрах одной секунды видео – он выдаст 30 независимых наборов рамок, не зная, что человек в кадре 2 – тот же, что в кадре 1. Для голого детектора каждый кадр – свежая толпа незнакомцев.

Трекинг объектов добавляет память. Он берёт покадровые рамки и связывает их во времени в треки – непрерывные траектории, каждая со стабильным ID трека. Трек №7 – «вот этот конкретный человек», кадр за кадром, пока он не покинет сцену. Доминирующий метод называется tracking-by-detection: детектировать объекты в каждом кадре, затем связать каждую новую рамку с существующим треком (тот же объект, чуть сдвинулся) или начать новый трек для всего по-настоящему нового. Детекция отвечает «что тут?»; трекинг отвечает «и это то же, что я видел мгновение назад?».

Шаг связывания дешевле и механичнее, чем ожидают. Основную работу делают два классических инструмента. Фильтр Калмана прогнозирует, где каждый отслеживаемый объект должен появиться в следующем кадре по его недавнему движению – идущий влево человек продолжает двигаться влево, – так система знает, примерно где смотреть. Венгерский алгоритм (Hungarian) затем сопоставляет новые детекции с этими прогнозами при наименьшей суммарной «стоимости» (ближайшая рамка, наиболее похожий вид). Современные трекеры вроде ByteTrack и BoT-SORT уточняют это: идея ByteTrack – связывать каждую рамку детекции, включая низкоуверенные, что восстанавливает объекты при кратком перекрытии; BoT-SORT добавляет компенсацию движения камеры, чтобы трекинг переживал поворот или тряску камеры, плюс модель внешнего вида для трудных сопоставлений (ByteTrack, arXiv 2110.06864; BoT-SORT, arXiv 2206.14651).

Нажмите, чтобы увеличить

Лёгкий случай: трекинг в пределах одной камеры

Слежение за одним объектом внутри поля зрения одной камеры – зрелая, достаточно решённая часть этой истории. Объекты остаются примерно того же размера, свет постоянен, паузы между кадрами крошечны, так что прогноз движения обычно верен. Этот трекинг на одной камере достаточно лёгкий, чтобы идти в реальном времени на собственном ИИ-чипе камеры или малом edge-сервере, и именно он питает длинный список повседневной аналитики: подсчёт, сколько людей пересекли линию и в каком направлении, измерение, как долго кто-то задержался в проходе (dwell time, время пребывания), детекция праздношатания и питание правил поведенческой аналитики – праздношатание, вторжение, зоны. Ничто из этого не работает без стабильного трека; нельзя измерить время пребывания, если каждый кадр – новый незнакомец.

У характерного отказа трекинга на одной камере есть имя, которое стоит знать: смена идентичности («identity switch», «ID switch»). Когда два человека пересекаются или один заходит за колонну и выходит снова, трекер может потерять нить и присвоить вышедшему новый ID трека – или, хуже, поменять ID двух людей местами. Высокий счёт смен идентичности – это разница между «человек №7 пробыл 40 секунд» и искажённой трассой, дробящей одного посетителя на трёх. Перекрытие – один объект прячет другой – обычная причина, и именно её призван снизить трюк ByteTrack «связывать каждую рамку».

Трудный случай: реидентификация между камерами

Теперь сделаем задачу по-настоящему трудной. Человек выходит из поля камеры A и через двадцать секунд появляется на камере B за углом. Трекер камеры B этого человека никогда не видел; для камеры B это совершенно новый трек. Связать «трек №7 камеры A» с «треком №3 камеры B» – узнать, что это тот же человек – это реидентификация, и она другая и куда более трудная задача, чем трекинг в одном поле.

Re-ID работает, превращая каждый объект в сигнатуру внешнего вида – компактную числовую сводку («эмбеддинг») того, как объект выглядит: цвета и текстуры одежды, форма тела, марка и цвет машины. Когда новый человек появляется на камере B, система вычисляет его сигнатуру и ищет ближайшее совпадение среди недавно виденных людей с других камер. Достаточно близкое совпадение говорит «тот же человек». Принципиально: само по себе это сверка вида, а не лица или номера – это «человек в красной куртке с чёрным рюкзаком», а не «Иван Петров».

Почему так трудно? Потому что две камеры могут вообще не пересекаться, так что нет момента, когда обе видят объект разом, чтобы закрепить совпадение. Между ними переворачивается ракурс (вид спереди на A, сзади на B), меняется свет (дневной вход, флуоресцентный коридор), объект частично скрыт, и проходит время. Исследователи формулируют межкамерный трекинг – формально multi-target multi-camera tracking (MTMC) – как три уложенные друг на друга задачи: трекинг в каждой камере, реидентификация между камерами и сшивка результата в одну сетевую траекторию (Ristani et al., «Features for Multi-Target Multi-Camera Tracking and Re-Identification», CVPR 2018). Каждый слой добавляет ошибку. И внешний вид хрупок особым образом, который должен услышать каждый покупатель: смените одежду – и re-ID по виду ломается. Снявший куртку может стать для системы другим «человеком».

Нажмите, чтобы увеличить

Реальность точности: диапазон, и между камерами он обрывается

Вот правило, на котором построен весь раздел, применённое к трекингу: точность – диапазон, привязанный к сцене, свету, ракурсу и времени; никогда не одно число и никогда не 100%. У трекинга свои честные метрики, и разрыв между числом на одной камере и числом между камерами – самое важное, что может понять покупатель.

Сначала метрики, простым языком. Качество трекинга на одной камере отчитывается тремя связанными оценками. MOTA (Multi-Object Tracking Accuracy) в основном измеряет качество детекции – сколько объектов пропущено или выдумано. IDF1 (Identity F1) измеряет качество идентичности – насколько стабильно каждый объект держал один и тот же ID на всём пути, что и важно для слежения. HOTA (Higher Order Tracking Accuracy) – современный баланс двух: геометрическое среднее того, как хорошо система детектирует объекты и как хорошо связывает их во времени (Luiten et al., HOTA, IJCV 2021). Когда вендор показывает числа трекинга, спросите, какая метрика – высокий MOTA при низком IDF1 значит «хорошо замечает объекты, плохо держит их личности».

Теперь числа. На стандартном пешеходном бенчмарке одной камеры MOT17 лучшие трекеры реального времени дают примерно 80% MOTA, 77–80% IDF1 и 63–65% HOTA – например ByteTrack около 80,3 MOTA / 77,3 IDF1 / 63,1 HOTA при 30 кадрах в секунду, и BoT-SORT чуть впереди на ~80,5 / 80,2 / 65,0 (ByteTrack, arXiv 2110.06864; BoT-SORT, arXiv 2206.14651). Реидентификация как задача поиска выглядит ещё лучше на своём домашнем бенчмарке: на наборе re-ID людей Market-1501 сильные модели 2025 достигают около 96% Rank-1 и 91–93% mAP (то есть верное совпадение – топ-результат в ~96% случаев). Но перейдите к более трудному и реалистичному набору MSMT17 – больше камер, больше вариаций света – и тот же класс моделей падает примерно до 86–87% Rank-1 и 70–75% mAP (свежая литература по re-ID, 2025). Это падение, от одного чистого бенчмарка к более грязному, – вся история в миниатюре.

Теперь обрыв. Сшейте трекинг и re-ID в полный межкамерный трекинг – и сквозная оценка личности падает заметно ниже числа на одной камере. На городском бенчмарке транспорта CityFlow – 40 камер на перекрёстках до 2,5 км друг от друга – ведущие межкамерные системы отчитываются о межкамерном IDF1 в полосе 70–85%, а заявка 2025 на AI City Challenge по одним камерам показала сквозной HOTA около 45% (CityFlow, arXiv 1903.09254; AI City Challenge 2025). Честный вывод: система, прекрасно трекающая на одной камере, теряет ощутимую долю личностей каждый раз, когда объект переходит между камерами, и чем больше камер и длиннее паузы, тем больше она теряет. Никогда не принимайте «мы трекаем людей по всему вашему объекту с точностью 99%». Просите оценку межкамерной личности на схеме как у вас, с вашим расстоянием между камерами.

Нажмите, чтобы увеличить

Как трек попадает в VMS – и оговорка ONVIF, на которой спотыкаются команды

Трек полезен, только если Video Management System – ПО, которое принимает и записывает множество потоков камер, называемое VMS – может его прочитать. Для этого есть отраслевой стандарт, и это часть, которой владеет именно этот курс по наблюдению, а не курс по ИИ. ONVIF – общий язык, позволяющий камерам и ПО разных производителей понимать друг друга, а ONVIF Profile M – профиль, созданный для метаданных аналитики. Profile M стандартизирует общую классификацию объектов и поток метаданных, несущий детекции, и позволяет этим метаданным ехать внутри видеопотока, через сервис событий ONVIF или поверх MQTT, лёгкого протокола обмена сообщениями в системах подключённых устройств (ONVIF, Profile M).

Трекинг конкретно попадает наружу через идентификатор объекта в scene description ONVIF. Каждый отслеживаемый объект получает ObjectId, и аналитический интерфейс стандарта моделирует даже грязную реальность трекинга: он определяет операции переименовать (Rename) ID объекта, когда алгоритм собрал достаточно свидетельств о личности, разделить (Split) один объект на два (присваивая свежий ID, когда пока нельзя сказать, кто есть кто), слить (Merge) и удалить (Delete) объект, когда тот покинул память алгоритма (ONVIF Analytics Service Specification). Иначе говоря, стандарт сам кодирует проблему смены идентичности, описанную выше – он даёт камере чистый способ сказать «я думал, это один объект; теперь их два».

Вот оговорка, на которой спотыкаются интеграторские команды, и это самый важный практический пункт статьи: ObjectId ONVIF локален для аналитики одного устройства. Это не межкамерная личность. «Объект 7» камеры A и «объект 7» камеры B не имеют отношения друг к другу – номера переиспользуются независимо. ONVIF стандартизирует, как одна камера отчитывается о своих собственных треках; он не стандартизирует реидентификацию между камерами. Сшивка треков по сети камер – задача VMS или выделенного слоя аналитики поверх, и именно там живут ПО и настройка вендора. Как всегда с ONVIF, соответствие – это база, а не гарантия каждой функции – держите «совместимо с ONVIF» и «межкамерный трекинг работает из коробки» твёрдо раздельно. Про стандартный слой под этим – события, метаданные и интерфейс аналитики ONVIF; коммерческий обзор – статья-компаньон Фора Софт про Profile M.

Где работают трекинг и Re-ID

Две половины этой задачи сидят в разных местах, и это задаёт стоимость, задержку и приватность. Трекинг на одной камере лёгкий и живёт на краю – на собственном нейропроцессоре (NPU) камеры или малом сервере на объекте – потому что математика связывания (фильтр Калмана плюс венгерский алгоритм) дешева и должна успевать за живой частотой кадров. Межкамерная реидентификация обычно идёт на сервере или в облаке, по структурной причине: чтобы сверить объект, виденный на камере A, с объектом на камере B, что-то должно видеть данные обеих камер разом, так что шаг re-ID нуждается в точке обзора выше любой одной камеры. Эта центральная сверка к тому же хочет больше вычислений, чтобы прогнать модель эмбеддинга вида и искать по многим недавним трекам.

Для покупателя следствие – знакомый компромисс. Делать re-ID централизованно значит слать вверх с каждой камеры сигнатуры вида (малые) или иногда вырезанные кадры (крупнее), что стоит трафика и концентрирует самые чувствительные для приватности данные – индекс для поиска кто-был-где – в одном месте. Держать больше на краю режет трафик и оставляет сырое видео на устройстве, но ограничивает, насколько богато можно сверять по сети. Где идёт аналитика – камера, сервер на объекте или облако – это отдельное решение со своим профилем задержки, трафика и приватности, подробно разобранное в аналитике на краю против облака и задержке и точности по уровням. Эта статья владеет тем, что делают трекинг и re-ID и как они попадают наружу; те – тем, где.

Нажмите, чтобы увеличить

Модель – в другом разделе, и это намеренно

Одна граница держит эту статью честной. Как устроены трекер и сеть re-ID – архитектуры эмбеддинга вида, обучение метрики, что стягивает образы одной личности вместе и расталкивает разные, алгоритмы связывания за ByteTrack и BoT-SORT – это территория нашего раздела ИИ для видеоинженерии. Тот раздел инженерит модель; эта статья по наблюдению владеет применением: как трек подключается к камере, VMS и хранилищу, что он даёт на практике и чего стоит в точности и приватности. Нужны внутренности модели – идите по кросс-ссылкам; нужно сформулировать и внедрить трекинг в работающей системе – оставайтесь здесь.

Вес для приватности: трасса – персональные данные, даже без имени

Это часть, которую покупатель не может пропустить, потому что межкамерный трекинг меняет характер приватности системы наблюдения, даже когда никакой биометрии нет. Три пункта проводят границу.

Первое: трасса перемещений сама по себе может быть персональными данными. Европейский GDPR определяет персональные данные как любую информацию, относящуюся к человеку, которого можно идентифицировать – и закон прямо включает того, кого можно «выделить» (singled out), прямо или косвенно, даже без имени (GDPR, Рег. (ЕС) 2016/679, ст. 4(1)). Постоянная трасса re-ID – «этот человек вошёл в 09:02, посетил эти четыре зоны, ушёл в 10:15 и вернулся во вторник» – выделяет человека в пространстве и времени. Так что построение межкамерных трасс – это обработка персональных данных со всеми вытекающими обязанностями GDPR, даже если система никогда не узнаёт, кто этот человек. Отсутствие имени – не отсутствие веса для приватности.

Второе: re-ID по виду, как правило, не биометрия, но два близких родственника – биометрия. Сверка людей по цвету одежды – это сверка вида, и European Data Protection Board трактует такие «мягкие» черты – те, что сами по себе не опознают человека однозначно – как, как правило, вне правил особой категории «биометрических данных» (EDPB, Guidelines 3/2019 о обработке персональных данных через видеоустройства). Но граница тонкая. Распознавание лиц измеряет лицо в шаблон, чтобы ответить «это Личность X?», а распознавание походки – опознание по тому, как человек идёт – поведенческая биометрия; обе обрабатывают человека с целью однозначного опознания, что и запускает защиту особой категории по ст. 9 GDPR. В тот миг, когда ваш «трекинг» опирается на лицо или сигнатуру походки, чтобы держать личность между камерами, вы перешли от сверки вида к биометрическому опознанию, и юридический барьер захлопывается. Это свои темы: распознавание лиц в видеонаблюдении и полный закон в GDPR для видеонаблюдения.

Третье: масштаб и место поднимают планку. Систематический трекинг людей по публично доступному пространству в большом масштабе – ровно тот вид обработки, для которого GDPR требует оценки воздействия на защиту данных (DPIA) до того, как вы её включите (GDPR ст. 35; EDPB Guidelines 3/2019). А в ЕС AI Act идёт дальше на остром конце: реальное время удалённой биометрической идентификации людей в публично доступных пространствах – живое сличение толпы по лицам, чтобы опознать всех в ней – это запрещённая практика для большинства применений, в силе с 2 февраля 2025, лишь с узкими исключениями для правоохраны при строгой авторизации (EU AI Act, Рег. (ЕС) 2024/1689, ст. 5). Трекинг по виду – это не тот запрет, но чем ближе ваш дизайн движется к опознанию названных людей в публичном месте в реальном времени, тем ближе он к жёсткой юридической стене. Чистое инженерное правило: следить за красной курткой – не то же, что назвать человека, но построенная трасса всё равно персональные данные, а добавление лица или походки превращает её в биометрическое опознание. Это инженерное руководство, а не юридическая консультация.

Нажмите, чтобы увеличить

Трекинг и Re-ID в одном взгляде

Таблица 1. Трекинг на одной камере против межкамерной реидентификации в том, что нужно знать покупателю. Точность, место работы и вес приватности – все растут, когда переходишь от одной камеры ко многим. Добавьте лицо или сигнатуру походки – и вес приватности растёт снова, в биометрический закон (статья 4.4).

Частая ошибка

Самый дорогой паттерн, что мы видим, – считать, что ID трека одной камеры переносится между камерами – собирать систему так, будто «объект 7» значит того же человека везде, – когда ObjectId ONVIF локален для одного устройства, а межкамерная личность это отдельный, теряющий шаг re-ID, который надо построить и настроить. Близкий второй – формулировать межкамерный трекинг по числу точности одной камеры: вендорское демо, безупречно ведущее одного актёра по одной комнате, говорит почти ничего об удержании личности по двенадцати камерам и двухминутной паузе. Третья, тише, ошибка – трактовать трассу по виду как нейтральную для приватности, потому что нет лица – трасса re-ID выделяет людей и есть персональные данные, и заслуживает DPIA, лимитов хранения и контроля доступа, как любые персональные данные. Требуйте пилот на многокамерном срезе вашего реального объекта, с отчётом по межкамерной метрике личности (IDF1 или HOTA), прежде чем верить любому «следим за кем угодно где угодно».

Где здесь Фора Софт

Фора Софт строит ПО для видео реального времени, стриминга и компьютерного зрения с 2005 года, на 250+ выпущенных проектах, и межкамерный трекинг – одна из функций, где мы чаще всего сбрасываем ожидания до того, как писать код. Команды приходят, ожидая один тумблер «трекать людей по объекту»; честная сборка – слоистая: надёжный трекинг на одной камере на краю, слой re-ID по виду, настроенный под реальное расстояние между камерами и свет, и VMS, что сшивает и хранит треки, не притворяясь, что оценка личности идеальна. Рамка, с которой мы ведём, – сначала как система ведёт себя под реальной нагрузкой: реалистичное межкамерное удержание личности на вашей схеме, трафик и хранение центрального индекса re-ID, и поза приватности при хранении трассы кто-был-где – и лишь затем возможности. Трекер, честный в том, где он теряет личности, лучше того, что демонстрируется безупречным и разочаровывает в поле.

Ключевые выводы

• Трекинг связывает покадровые детекции в непрерывные треки со стабильными ID; re-ID сверяет объект между разными камерами.
• Трекинг на одной камере зрел и идёт на краю; межкамерный re-ID труден и идёт на сервере или в облаке.
• Точность – диапазон и падает между камерами: ~80% IDF1 на одной камере против ~70–85% межкамерно, никогда 100%.
• ONVIF Profile M несёт ObjectId на устройство – это не межкамерная личность; сшивка – задача VMS.
• Re-ID по виду, как правило, не биометрия; распознавание лица или походки – биометрия, и переходит юр. барьер.
• Трасса выделяет человека, так что это персональные данные даже без имени – относитесь соответственно.

Что читать дальше

• Детекция и классификация объектов в видеонаблюдении
• Поиск по событию: как сделать месяцы архива находимыми
• Распознавание лиц в видеонаблюдении: как работает и где ограничено