Власники торговельних центрів та організатори заходів часто стикаються з проблемою точного підрахунку відвідувачів. Старі лічильники на вході дають похибку до 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 кроків
- Обстеження приміщення та узгодження розташування камер.
- Встановлення та налаштування обладнання.
- Розробка моделі детекції та трекінгу під ваші умови.
- Інтеграція з InfluxDB, Grafana, вашою CRM або BI.
- Тестування та калібрування точності.
Чи відповідає система нормам 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-дашборду:
- InfluxDB — зберігання time-series даних (вхід/вихід по 5-хвилинних інтервалах).
- Apache Superset або Power BI — дашборди для менеджменту: трафік по днях, часові піки, аномалії.
- Prophet / SARIMA — прогноз відвідуваності на наступний тиждень з точністю MAE < 8%.
Прогнози використовуються для оптимізації розкладу персоналу: при очікуваному піку система рекомендує збільшити кількість касирів або відкрити додатковий вхід.
Відповідність нормам: GDPR та захист персональних даних
Система не зберігає персональних даних: трекінг ведеться за анонімними ID, зображення відвідувачів не зберігаються на диск. Для додаткового захисту передбачено розмиття облич в режимі реального часу (face blur). Це відповідає вимогам GDPR та українського законодавства про персональні дані. При необхідності — готуємо документацію для DPO та проводимо оцінку впливу на захист даних (DPIA).
Типові помилки при розгортанні
- Встановлення камер з горизонтальним кутом замість строго вертикального: точність падає на 10–15%.
- Недостатнє освітлення в нічний час: ставимо ІЧ-підсвітку або використовуємо камери з WDR.
- Перетин зон захоплення двох камер без дедуплікації: подвійний рахунок одного відвідувача.
- Ігнорування дрейфу моделі: через 3–6 місяців при зміні умов освітлення або одягу точність знижується — потрібне донавчання.
Ми гарантуємо точність не нижче заявленої, надаємо підтримку після запуску. Оцінимо ваш проєкт за 2 дні — зв'яжіться з нами. Отримайте консультацію щодо впровадження системи підрахунку відвідувачів.







