Розробка системи підрахунку відвідувачів (People Counting)

Власники торговельних центрів та організатори заходів часто стикаються з проблемою точного підрахунку відвідувачів. Старі лічильники на вході дають похибку до 20%, а дані про переміщення всередині приміщень відсутні. Ми розробили систему на основі комп'ютерного зору, яка вирішує ці завдання: ми буду

Напрямки AI-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1441
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1301
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    998
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1267
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    713
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1006

Власники торговельних центрів та організатори заходів часто стикаються з проблемою точного підрахунку відвідувачів. Старі лічильники на вході дають похибку до 20%, а дані про переміщення всередині приміщень відсутні. Ми розробили систему на основі комп'ютерного зору, яка вирішує ці завдання: ми будуємо систему підрахунку відвідувачів під ключ, використовуючи сучасні методи детекції та трекінгу. Наш досвід — понад 5 років у відеоаналітиці, 50+ реалізованих проєктів. Ефективна система підрахунку відвідувачів (people counting) забезпечує точність до 99%, що в 10 разів краще за ручний підрахунок.

Чому верхній огляд (top-view) оптимальний?

Камера, встановлена на стелі перпендикулярно підлозі, дає мінімальні перекриття об'єктів. Люди видно як силуети, що спрощує детекцію. Це стандартний підхід для people counting: точність досягає 97–99%. Ми використовуємо моделі YOLO (Ultralytics) з трекінгом ByteTrack, що дозволяє відстежувати кожного відвідувача. Ultralytics YOLOv8 documentation

from ultralytics import YOLO import numpy as np import cv2 class PeopleCounter: def __init__(self, model_path: str, count_line: tuple, # ((x1,y1), (x2,y2)) direction: str = 'both'): # 'in', 'out', 'both' self.model = YOLO(model_path) self.count_line = count_line self.direction = direction # ByteTrack вбудований в Ultralytics self.tracker_config = 'bytetrack.yaml' self.track_history = {} self.count_in = 0 self.count_out = 0 self.counted_ids = set() def process(self, frame: np.ndarray) -> dict: # Детекція людей з трекінгом results = self.model.track( frame, persist=True, conf=0.4, classes=[0], # тільки люди tracker=self.tracker_config ) if results[0].boxes.id is None: return self._get_counts() for box, track_id in zip(results[0].boxes.xyxy, results[0].boxes.id): tid = int(track_id) x1, y1, x2, y2 = map(int, box) cx, cy = (x1 + x2) // 2, (y1 + y2) // 2 if tid not in self.track_history: self.track_history[tid] = [] self.track_history[tid].append((cx, cy)) # Перевіряємо перетин лінії if len(self.track_history[tid]) >= 2 and tid not in self.counted_ids: prev_pos = self.track_history[tid][-2] curr_pos = self.track_history[tid][-1] crossing = self._check_line_crossing(prev_pos, curr_pos) if crossing: if crossing == 'forward': self.count_in += 1 else: self.count_out += 1 self.counted_ids.add(tid) return self._get_counts() def _check_line_crossing(self, prev: tuple, curr: tuple) -> str | None: """Визначення факту та напрямку перетину лінії""" lx1, ly1 = self.count_line[0] lx2, ly2 = self.count_line[1] # Векторний добуток для визначення сторони d1 = self._cross_product(prev, (lx1, ly1), (lx2, ly2)) d2 = self._cross_product(curr, (lx1, ly1), (lx2, ly2)) if d1 * d2 < 0: # перетин return 'forward' if d1 < 0 else 'backward' return None def _cross_product(self, point, line_start, line_end): return ((line_end[0] - line_start[0]) * (point[1] - line_start[1]) - (line_end[1] - line_start[1]) * (point[0] - line_start[0])) def _get_counts(self) -> dict: return { 'count_in': self.count_in, 'count_out': self.count_out, 'current_occupancy': self.count_in - self.count_out } 

Теплова карта переміщень

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

class MovementHeatmap: def __init__(self, frame_shape: tuple): h, w = frame_shape[:2] self.accumulator = np.zeros((h, w), dtype=np.float32) self.decay = 0.995 # забуваємо старі дані def update(self, track_positions: list[tuple]): self.accumulator *= self.decay for x, y in track_positions: if 0 <= x < self.accumulator.shape[1] and \ 0 <= y < self.accumulator.shape[0]: self.accumulator[y, x] += 1.0 # Gaussian blur для згладжування self.accumulator = cv2.GaussianBlur( self.accumulator, (21, 21), 0 ) def get_heatmap(self, frame: np.ndarray) -> np.ndarray: normalized = cv2.normalize( self.accumulator, None, 0, 255, cv2.NORM_MINMAX ).astype(np.uint8) colormap = cv2.applyColorMap(normalized, cv2.COLORMAP_JET) return cv2.addWeighted(frame, 0.6, colormap, 0.4, 0) 

Аналітика та звітність

Дані підрахунку надходять до time-series бази InfluxDB і доступні в Grafana. Ми налаштовуємо дашборди з трафіком за день/тиждень/місяць, піковими годинами, конверсійною воронкою по зонах та контролем наповнюваності.

Як впровадити систему: 5 кроків

  1. Обстеження приміщення та узгодження розташування камер.
  2. Встановлення та налаштування обладнання.
  3. Розробка моделі детекції та трекінгу під ваші умови.
  4. Інтеграція з InfluxDB, Grafana, вашою CRM або BI.
  5. Тестування та калібрування точності.

Чи відповідає система нормам GDPR?

Так, система не зберігає персональних даних: трекінг ведеться за анонімними ID, зображення відвідувачів не зберігаються на диск. Для додаткового захисту передбачено розмиття облич в режимі реального часу (face blur). Це відповідає вимогам GDPR та українського законодавства про персональні дані. При необхідності — готуємо документацію для DPO та проводимо оцінку впливу на захист даних (DPIA).

Які типові помилки при розгортанні?

  • Встановлення камер з горизонтальним кутом замість строго вертикального: точність падає на 10–15%.
  • Недостатнє освітлення в нічний час: ставимо ІЧ-підсвітку або використовуємо камери з WDR.
  • Перетин зон захоплення двох камер без дедуплікації: подвійний рахунок одного відвідувача.
  • Ігнорування дрейфу моделі: через 3–6 місяців при зміні умов освітлення або одягу точність знижується — потрібне донавчання.

Точність систем підрахунку

Умови Accuracy
Top-view, гарне освітлення 97–99%
Боковий огляд, помірна щільність 93–96%
Щільні натовпи (>30 осіб/м²) 85–91%
Погане освітлення 88–93%
Масштаб Термін
1–4 входи, базовий підрахунок 2–3 тижні
Торговельний центр, теплові карти 4–7 тижнів
Мережа об'єктів + аналітика 7–12 тижнів

Вартість та економія

Впровадження системи для одного входу коштує від 15 000 грн, для мережі об'єктів — від 100 000 грн. Зменшення помилок підрахунку дозволяє зекономити до 30% на оплаті праці персоналу.

Про нас

Ми — компанія з 5+ роками на ринку, реалізували 50+ проєктів відеоаналітики. Наша система підрахунку відвідувачів використовується в торговельних центрах, офісах та на заходах.

Багатокамерна система: синхронізація та дедуплікація

Для об'єктів з кількома входами дані з кожної камери підсумовуються, але важливо виключити подвійний рахунок при переході відвідувача з зони в зону. Ми використовуємо глобальний трекер на основі Re-ID (ReID): кожен відвідувач отримує унікальний ембендинг за зовнішнім виглядом (BoT-SoRT / StrongSORT), зберігається в Redis і перевіряється при появі в іншій камері протягом заданого часового вікна.

Приклад конфігурації для торговельного центру з 8 входами:

  • Камери: 8 × Hikvision DS-2CD2185G1 (8 МП, 30fps).
  • Сервер обробки: 1 × NVIDIA A10G (24 ГБ VRAM), обробляє всі 8 потоків із затримкою менше 150 мс.
  • Redis TTL для дедуплікації: 30 хвилин (час переходу між входами).
  • Точність дедуплікації: >97% при гарному освітленні.

Як працює дедуплікація?

Система використовує Re-ID для ідентифікації одного відвідувача в різних камерах, що запобігає подвійному рахунку.

Інтеграція з BI та прогнозування відвідуваності

Дані про відвідуваність цінні не лише в реальному часі, а й як історичний ряд для планування. Ми будуємо pipeline від лічильника до BI-дашборду:

  1. InfluxDB — зберігання time-series даних (вхід/вихід по 5-хвилинних інтервалах).
  2. Apache Superset або Power BI — дашборди для менеджменту: трафік по днях, часові піки, аномалії.
  3. Prophet / SARIMA — прогноз відвідуваності на наступний тиждень з точністю MAE < 8%.

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

Відповідність нормам: GDPR та захист персональних даних

Система не зберігає персональних даних: трекінг ведеться за анонімними ID, зображення відвідувачів не зберігаються на диск. Для додаткового захисту передбачено розмиття облич в режимі реального часу (face blur). Це відповідає вимогам GDPR та українського законодавства про персональні дані. При необхідності — готуємо документацію для DPO та проводимо оцінку впливу на захист даних (DPIA).

Типові помилки при розгортанні

  • Встановлення камер з горизонтальним кутом замість строго вертикального: точність падає на 10–15%.
  • Недостатнє освітлення в нічний час: ставимо ІЧ-підсвітку або використовуємо камери з WDR.
  • Перетин зон захоплення двох камер без дедуплікації: подвійний рахунок одного відвідувача.
  • Ігнорування дрейфу моделі: через 3–6 місяців при зміні умов освітлення або одягу точність знижується — потрібне донавчання.

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