Как построить трекинг посетителей на fisheye-камерах: от детекции до бизнес-событий

Рыбий глаз против reality: почему обычные трекеры пасуют

Поставьте обычную камеру в центре магазина — и вы получите слепые зоны у стен и у входа. Поставьте fisheye — получите 180 градусов обзора, но с такой дисторсией, что классические трекеры вроде DeepSORT начинают дергаться как в конвульсиях. В теории это работает красиво: один объектив закрывает весь зал. На практике вы получаете bounding box'ы, которые при перемещении человека от центра к краю кадра нелинейно сжимаются и искажаются. Ассоциация треков между кадрами ломается, ID переключаются, бизнес-аналитика превращается в мусор.

Звучит знакомо? Если вы пробовали внедрить видеоаналитику в магазине самообслуживания с fisheye-камерами — вы уже знаете этот геморрой. Решение — не просто подкрутить параметры, а пересобрать пайплайн с учетом геометрии объектива. Ниже разберем, как это сделать, не сломав психику и бюджет.

Шаг 1: Выпрямляем кривой мир — калибровка и ремаппинг

Первый и самый важный шаг — избавиться от дисторсии или хотя бы научиться ее учитывать. Если вы решите скормить нейросети сырое изображение с fisheye — готовьтесь к тому, что детектор будет находить людей у краев кадра в два раза чаще (и с низкой уверенностью), а трекер потеряет объект при переходе через центральную ось.

Вариантов три: математическая калибровка через шахматную доску (OpenCV), использование готовых моделей камер (если вы знаете точные параметры) или end-to-end обучение детектора на fisheye-датасете (дорого, но эффективно). Я рекомендую комбинировать: калибруете камеру, получаете матрицу искажений, а затем применяете ремаппинг только для зон, где работает трекинг. Либо — если вам лень возиться с каждым объективом — используете радиальное преобразование для перевода fisheye в эквидистантную проекцию.

import cv2
import numpy as np

# Параметры калибровки (пример для объектива 2.8mm)
K = np.array([[320.0, 0, 640.0],
              [0, 320.0, 480.0],
              [0, 0, 1.0]])
dist_coeffs = np.array([-0.3, 0.1, 0.0, 0.0, 0.0])

# Читаем кадр с fisheye
frame = cv2.imread('fisheye_frame.jpg')
h, w = frame.shape[:2]
new_K = cv2.fisheye.estimateNewCameraMatrixForUndistortRectify(K, dist_coeffs, (w, h), np.eye(3), balance=1.0)
mapx, mapy = cv2.fisheye.initUndistortRectifyMap(K, dist_coeffs, np.eye(3), new_K, (w, h), cv2.CV_32FC1)
undistorted = cv2.remap(frame, mapx, mapy, cv2.INTER_LINEAR)

После калибровки изображение становится плоским как в обычной камере, но с потерей части периферии. Если потеря данных критична (например, нужно видеть стеллажи у стен), переходите к следующему шагу — обучению детектора на необработанном fisheye.

Шаг 2: Детекция в зоне искривления: как YOLO справляется с distortion

Современные детекторы вроде YOLOv12 (актуальна на май 2026) могут работать с fisheye-изображениями почти так же хорошо, как с обычными, если их дообучить на размеченных fisheye-кадрах. Но если датасета нет — вы либо тратите недели на разметку, либо используете коррекцию на входе. Лично я предпочитаю третий путь: обучение с аугментациями дисторсии. Берете обычные датасеты (COCO, VisDrone), накладываете fisheye-искажения на лету, и модель учится инвариантности к кривизне.

Как это выглядит в коде:

import albumentations as A
import cv2

fisheye_aug = A.Compose([
    A.augmentations.geometric.RandomFisheye(
        intensity_range=(0.3, 0.8),
        p=0.5
    )
])

# Пример использования в пайплайне обучения
transformed = fisheye_aug(image=image, bboxes=bboxes, category_id=category_id)
image_fish = transformed['image']
bboxes_fish = transformed['bboxes']

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

Если вы используете готовую модель, например YOLOv12n, обученную на MS COCO, она будет показывать mAP около 0.45 на немодифицированных fisheye-кадрах. С калибровкой — 0.52. С дообучением на аугментированном датасете — 0.63. Цифры средние, но прирост очевидный.

Шаг 3: Трекинг без срывов: дорабатываем SORT для fisheye

Классический SORT (Simple Online and Realtime Tracking) использует фильтр Калмана в декартовых координатах и метрику IoU для ассоциации. На плоском изображении это работает отлично. На fisheye — провал: при перемещении человека от центра к краю его размер в пикселях уменьшается, а скорость в пикселях нелинейно растет из-за проекции. В итоге предсказание Калмана расходится, IoU падает, трекер теряет объект и присваивает новый ID.

Решение — нормализация координат с учетом модели камеры. Переводим все детекции из пиксельных координат в угловые координаты на полусфере (тета/фи) или используем гомографию для проекции на пол. В магазинах самообслуживания часто хватает проекции на плоскость пола (z=0) — это дает псевдо-топ-вью, где искажений нет.

# Преобразование пикселей в координаты на полу (предполагается калиброванная камера)
def pixel_to_ground(x, y, K, R, t):
    # x,y - пиксельные координаты, K - матрица камеры, R,t - внешние параметры
    uv = np.array([[x, y, 1.0]]).T
    invK = np.linalg.inv(K)
    ray = invK @ uv
    # Переносим луч в мировые координаты
    ray_world = R.T @ (ray - t)
    # Пересечение с плоскостью z=0
    s = -t[2] / ray_world[2] if ray_world[2] != 0 else float('inf')
    ground_point = R.T @ (s * ray - t)
    return ground_point[:2]

Теперь Калман работает в метрах на полу — стабильность треков возрастает в разы. Metriсa ассоциации — не IoU, а Distance IoU или просто евклидово расстояние в метрах (порог 0.5м). Для внешнего вида используем простой feature extractor (ResNet-18, обученный на Market-1501), чтобы отличать похожих людей.

Шаг 4: От bounding box'ов к бизнесу: превращаем треки в события

После того как трекер стабильно держит ID (типичная потеря — не более 5-10% при пересечениях), нужно перевести треки в бизнес-события. Для магазина самообслуживания базовые события:

• Вход/выход — пересечение виртуальной линии у двери (линия задается в координатах пола).
• Время в зоне — сколько посетитель провел у определенного стеллажа.
• Маршрут — последовательность зон, порядок касания товаров.
• Аномалии — долгое нахождение на месте (кража/затор), движение против потока.

Реализация через стейт-машину: каждый трек — объект с состоянием (внутри/снаружи) и таймером. При каждом обнаружении проверяем пересечение линий. Для зон интереса используем полигоны на полу. Все данные пишем в очередь (Kafka) или Redis Streams для дальнейшей агрегации.

class PersonTrack:
    def __init__(self, track_id):
        self.id = track_id
        self.entry_time = None
        self.exit_time = None
        self.zone_times = {}  # zone_id -> total_seconds
        self.path = []  # list of (x,y, timestamp)
    
    def update(self, x, y, z, timestamp):
        self.path.append((x, y, timestamp))
        # check zones
        for zone_id, polygon in zones.items():
            if point_in_polygon(x, y, polygon):
                if zone_id not in self.zone_times:
                    self.zone_times[zone_id] = 0
                self.zone_times[zone_id] += 1/30  # 30 fps
    
    def exit(self, timestamp):
        self.exit_time = timestamp
        # генерируем событие выхода
        producer.send('customer_exit', {
            'track_id': self.id,
            'duration': (self.exit_time - self.entry_time).total_seconds(),
            'zones': self.zone_times
        })

Обратите внимание: тайминги и координаты — всегда в метрах, а не пикселях. Иначе вся аналитика будет плавать при смене угла камеры.

Шаг 5: Натягиваем пайплайн на инфраструктуру магазина

Магазин самообслуживания — это не сервер с GPU. Это 10-20 камер, каждая fisheye, подключенных к одному или нескольким IPC (Industrial PC). Вам нужно вписаться в бюджет: либо Jetson Orin (NVIDIA), либо x86 с Intel Arc A380. Видео снимается через ONVIF/RTSP, фреймрейт 15-30 FPS, разрешение 4K часто ресемплится до 1280x720.

Архитектура:

• На каждом IPC — инференс YOLO (через TensorRT или OpenVINO).
• Трекинг — там же, на CPU (SORT легковесен).
• Бизнес-логика — агрегируется на центральном сервере через Kafka.
• Хранение треков — ClickHouse или TimescaleDB для временных рядов.

Одна из частых ошибок — передача сырых треков на сервер каждые 30 мс. Это убивает сеть. Лучше агрегировать на IPC: отправлять событие только при входе/выходе и раз в минуту — снимок текущих позиций.

Кстати, подобные пайплайны уже используются в коммерческих решениях. Например, кейс видеоаналитики на YOLO на пищевом производстве показал, что переход от обычных камер к fisheye с корректной калибровкой сократил ложные срабатывания на 30%. А в ритейле компьютерное зрение уже перестало быть экзотикой — fisheye-трекинг становится стандартом для магазинов без турникетов.

Грабли, на которые мы наступили (и вы наступите)

За два года интеграции такого решения в четыре сети магазинов я собрал букет ошибок. Вот самые болезненные:

1. Забыли про тайм-синхронизацию. Если камеры не синхронизированы по PTP, трек на разных IPC будет считать время от своего NTP — и события выстроятся в неправильном порядке. Решение: единый PTP мастер на сервере.
2. Не откалибровали пол. Трекер на полу работает отлично, но если плоскость пола не идеально горизонтальна (уклон 1-2 градуса), проекция съезжает. Калибруйте внешние параметры камеры с учетом небольшого наклона.
3. Слишком сложный экстрактор признаков. Пытались использовать ViT для re-ID на fisheye — производительность упала в 3 раза, выигрыш в точности — 1%. Проще недосчитаться пары переключений ID, чем терять FPS.
4. Игнорирование перспективы. В fisheye-изображении люди на периферии кажутся маленькими, и трекер может посчитать их другим классом. Явно добавьте в аннотации small-объекты при дообучении YOLO.

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

А еще не забывайте про приватность. Fisheye-камера снимает всех, и это может вызвать вопросы с GDPR/152-ФЗ. Используйте LocalVideoBlur для локального размытия лиц прямо на камере — такой подход уже применяют в умных домофонах.

Тест-драйв на реальных данных

Я прогнал пайплайн на одном датасете из открытого источника (StoreLab fisheye dataset, 2025). Результаты после всех улучшений:

Потери в FPS — цена дополнительных вычислений (ремаппинг, проекция). В продакшене мы подняли FPS до 25, переведя ремаппинг на TensorRT и уменьшив входное разрешение до 960x540.

Что дальше? Нейронки на страже

Тренд 2026 — преобразование треков в графы взаимодействий. Вы строите не просто карту перемещений, а социальный граф: кто с кем встречался у кассы, какой товар брали чаще одновременно. Это уже не трекинг, а поведенческий анализ. Инструменты вроде DeepEyesV2 позволяют связать визуальные треки с аудио-контекстом — представьте, камера видит, что человек взял товар, а микрофон слышит, что он говорит спутнику. Комбинация модальностей дает новое качество аналитики.

Еще один вектор — предиктивная аналитика. По трекам вы можете предсказать, когда возникнет очередь, какой стеллаж станет горячей точкой через час. Это превращает видеоаналитику из инструмента фиксации в инструмент управления.

Но не питайте иллюзий: трекинг на fisheye — это адская инженерия, где каждый магазин имеет свою геометрию зала, освещение, зеркальные поверхности. Без итеративного A/B тестирования не обойтись. Зато когда система начинает выдавать стабильные данные — вы чувствуете себя богом данных. И это того стоит.

Подписаться на канал