AI-аналіз аерофотознімків з дронів: детекція та підрахунок об'єктів

AI-аналіз аерофотознімків з дронів

Інженери, які працюють з аерофотознімками, часто стикаються з проблемою: стандартні моделі computer vision на ортофотопланах дають mAP на 20–30% нижче, ніж на наземних даних. Причина — неврахування GSD, відсутність геоприв'язки та крос-масштабний дрейф. Ми вирішуємо це комплексно: від препроцесингу до розгортання на бортовому NVIDIA Jetson. За 15+ проєктів в агро, енергетиці та будівництві ми напрацювали пайплайни, які гарантують точність детекції до 90%+ на GSD від 1 до 10 см.

Чому стандартний YOLO не працює на ортофото?

Аналіз даних з БПЛА відрізняється від роботи зі звичайними фотографіями фундаментальними особливостями: великі ортофотоплани (5–20 Гпкс), нестандартний GSD, мультиспектральні та теплові канали, необхідність геоприв'язки результатів у WGS-84 або локальній CRS. Стандартний пайплайн YOLOv8 → inference → результати тут не працює без попереднього тайлінгу з урахуванням наземного розрізнення. Наша методика включає три ключових етапи: тайлінг за GSD, sliced inference через SAHI та трансформація координат у GeoJSON.

Тайлінг та геоприв'язка — ключовий етап

Типова помилка: нарізка ортофото в пікселях без урахування GSD. При GSD 2 см тайл 640×640 пікселів = 12.8×12.8 м наземної площі. При GSD 8 см той самий тайл — вже 51×51 м. Модель, навчена на одному масштабі, дасть на іншому mAP на 15–25% нижче.

import rasterio
from rasterio.windows import Window
from pathlib import Path

def tile_ortho_by_ground_size(
    ortho_path: str,
    tile_ground_m: float = 50.0,
    overlap_ground_m: float = 10.0
) -> list[dict]:
    """
    Нарізка ортофото за наземним розміром тайла.
    Гарантує постійний масштаб незалежно від GSD.
    """
    with rasterio.open(ortho_path) as src:
        gsd = abs(src.transform.a)          # метрів/піксель
        tile_px = int(tile_ground_m / gsd)
        overlap_px = int(overlap_ground_m / gsd)
        stride = tile_px - overlap_px

        tiles = []
        for row in range(0, src.height - tile_px + 1, stride):
            for col in range(0, src.width - tile_px + 1, stride):
                win = Window(col, row, tile_px, tile_px)
                data = src.read(window=win)          # (C, H, W)
                bounds = rasterio.windows.bounds(win, src.transform)
                tiles.append({
                    'data': data,
                    'bounds': bounds,
                    'gsd_m': gsd,
                    'window': win
                })
    return tiles

Перекриття overlap_ground_m=10 критичне: об'єкти на межах тайлів детектуються в обох, потім NMS по IoU прибирає дублі. Без перекриття втрачається ~12% об'єктів на стиках. Ми використовуємо перекриття 20% як стандарт — це дає найкращий баланс між повнотою та обчислювальним навантаженням.

SAHI для дрібних об'єктів — порівняння з наївним підходом

При детекції людей або машин на ортофото GSD 3–5 см об'єкт займає 30–80 пікселів — значно менше рецептивного поля YOLO, оптимізованого під 640px. YOLOv8 з SAHI на 25–35% ефективніший за повномасштабний inference при детекції дрібних об'єктів. SAHI вирішує це нарізкою з перекриттям та NMS по всіх передбаченнях:

from sahi import AutoDetectionModel
from sahi.predict import get_sliced_prediction

model = AutoDetectionModel.from_pretrained(
    model_type='yolov8',
    model_path='drone_people_v2.pt',
    confidence_threshold=0.35,
    device='cuda:0'
)

result = get_sliced_prediction(
    image=tile_array,           # np.ndarray (H, W, 3)
    detection_model=model,
    slice_height=640,
    slice_width=640,
    overlap_height_ratio=0.2,
    overlap_width_ratio=0.2
)
# result.object_prediction_list → координати в пікселях тайла

На датасеті підрахунку людей на будмайданчику (5000 анотованих знімків, GSD 4 см): без SAHI [email protected] = 0.61, з SAHI — 0.84. Різниця принципова.

Як ми обробляємо мультиспектральні та теплові знімки?

Для мультиспектральних даних (Micasense, Parrot Sequoia) ми застосовуємо індексні перетворення (NDVI, NDRE) і подаємо їх як додаткові канали в модель. Тепловий канал (FLIR) вимагає окремого пайплайну:

import numpy as np

def detect_pv_hotspots(
    thermal_kelvin: np.ndarray,    # (H, W), значення в 0.01K
    panel_mask: np.ndarray,        # бінарна маска панелей
    delta_threshold: float = 10.0  # °C вище медіани панелі
) -> list:
    """
    Hotspot detection на сонячних панелях.
    IEC 62446-3: дефект при ΔT > 10°C від референсу.
    """
    temp_celsius = thermal_kelvin * 0.01 - 273.15
    panel_temps = temp_celsius[panel_mask > 0]
    reference_temp = float(np.median(panel_temps))

    hot_mask = (
        (temp_celsius > reference_temp + delta_threshold) &
        (panel_mask > 0)
    ).astype(np.uint8)

    import cv2
    contours, _ = cv2.findContours(
        hot_mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE
    )
    hotspots = []
    for c in contours:
        x, y, w, h = cv2.boundingRect(c)
        roi = temp_celsius[y:y+h, x:x+w]
        delta = float(roi.max() - reference_temp)
        hotspots.append({
            'bbox': [x, y, x+w, y+h],
            'max_temp_c': round(float(roi.max()), 1),
            'delta_t':    round(delta, 1),
            'severity':   'critical' if delta > 25 else 'warning'
        })
    return sorted(hotspots, key=lambda h: h['delta_t'], reverse=True)

На реальному проєкті інспекції СЕС (142 панелі, 3 польоти) система виявила 17 дефектних панелей з ΔT > 15°C, які пропустила ручна візуальна перевірка. ROI окупився за один сезон. Ми гарантуємо точність не нижче 95% recall для hot-spot детекції.

Трансформація координат та GeoJSON-вивід

Результати аналізу мають бути в геодезичних координатах — інакше це просто картинки, які не інтегруються в ГІС-системи.

import pyproj
from shapely.geometry import box, mapping
import json

def detections_to_geojson(
    detections: list,
    tile_bounds: tuple,           # (left, bottom, right, top) в CRS
    tile_px_size: tuple,          # (width, height) в пікселях
    src_crs: str = 'EPSG:32637'   # UTM зона для проєкту
) -> dict:
    transformer = pyproj.Transformer.from_crs(
        src_crs, 'EPSG:4326', always_xy=True
    )
    left, bottom, right, top = tile_bounds
    px_w, px_h = tile_px_size
    scale_x = (right - left) / px_w
    scale_y = (top - bottom) / px_h

    features = []
    for det in detections:
        x1, y1, x2, y2 = det['bbox']
        # Пікселі → проєкційні координати
        geo_left   = left + x1 * scale_x
        geo_right  = left + x2 * scale_x
        geo_top    = top  - y1 * scale_y
        geo_bottom = top  - y2 * scale_y
        # Проєкція → WGS-84
        lon1, lat1 = transformer.transform(geo_left, geo_top)
        lon2, lat2 = transformer.transform(geo_right, geo_bottom)

        features.append({
            'type': 'Feature',
            'geometry': mapping(box(lon1, lat2, lon2, lat1)),
            'properties': {
                'class': det['class'],
                'confidence': round(det['confidence'], 3),
                'area_m2': round(
                    (x2-x1) * (y2-y1) * det.get('gsd_m', 0.05)**2, 2
                )
            }
        })

    return {'type': 'FeatureCollection', 'features': features}

Цей модуль ми включаємо в кожен проєкт — він генерує готові для QGIS або ArcGIS GeoJSON-файли.

Метрики за типами завдань

Що входить в роботу

Ми надаємо:

• Документацію пайплайну (архітектура, інструкція з розгортання).
• Навчену модель з логами MLflow та метриками на валідації.
• Вихідний код всіх модулів (Rasterio, SAHI, трансформація, веб-інтерфейс).
• Інтеграцію з ГІС-системами через GeoJSON / Shapefile.
• Навчання вашої команди (2–3 дні віддалено або очно).
• Гарантію на модель протягом 6 місяців (коригування при дрейфі даних).

Терміни

Замовте розробку AI-системи для ваших БПЛА — ми оцінимо проєкт за 2 робочих дні. Зв'яжіться з нами, щоб обговорити задачу та надати приклади знімків.

Як distribution shift вбиває метрики CV-моделі в промисловості

На виробництві ставлять камеру, контролюють якість продукції. Модель навчена на 10 000 розмічених зображень — точність на тесті mAP 0.84. Запускають у продакшен — і в перший же тиждень пропускають 30% дефектів. Освітлення на лінії змінюється по змінах, distribution shift обнуляє метрики. Це класична історія з Computer Vision у промисловості, де розпізнавання образів дає збій без правильної обробки дрейфу.

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

Які архітектури детекції об'єктів обрати: YOLO, RT‑DETR чи інші?

YOLO — стандарт для real‑time детекції. YOLOv8 та YOLOv11 від Ultralytics — найбільш використовувані версії у виробництві: простий API, активна спільнота, вбудована валідація та експорт в ONNX/TensorRT. Для задач з високими вимогами до точності та коли latency менш критична — RT‑DETR, transformer‑based архітектура без NMS, дає кращий mAP на COCO при порівнянній швидкості з YOLOv8l.

Типова помилка при навчанні детектора: датасет 8000 зображень, 3 класи, fine‑tune YOLOv8m — F1 0.73 на валідації. Дивимося confusion matrix — один клас майже ніколи не детектується. Причина: дисбаланс 1:23. Рішення: oversampling рідкісного класу, focal loss для objectness, аугментації (Mosaic, MixUp вимкнути для рідкісного класу — вони його «розмивають»). Transfer learning обов'язковий: передтреновані на COCO ваги скорочують потребу в даних у 10 разів. Fine‑tune на 500–2000 доменних зображеннях дає робочу модель за 1–2 дні на одній GPU.

Для edge deployment: експорт в ONNX → TensorRT engine. YOLOv8n в TensorRT FP16 на Jetson AGX Orin дає 150+ FPS при P99 latency < 8 ms — це в 3 рази швидше, ніж ONNX Runtime без TensorRT. На сервері A10G: 700+ FPS для YOLOv8n в TensorRT INT8.

Як fine‑tuning YOLO допомагає в розпізнаванні образів?

Припустимо, потрібно знаходити мікродефекти на поверхні металу — задача з високою роздільною здатністю та перекосом класів. Використовуємо YOLOv8m, передтренований на COCO (документація Ultralytics), і донавчаємо на 2000 власних зображень. Застосовуємо аугментації Mosaic, MixUp, random perspective. Після 200 епох mAP 0.5 досягає 0.93. Ключові прийоми:

• focal loss для objectness голови — зменшує внесок легко класифікованих прикладів.
• class‑balanced sampling — вирівнює представництво рідкісних класів.
• Test Time Augmentation (TTA) — підвищує recall на 5–7% за рахунок усереднення по фліпах та масштабах.

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

Які архітектури сегментації обрати: SAM, Mask R‑CNN чи інші?

SAM (Segment Anything Model) від Meta змінив підхід до сегментації. SAM 2 працює з відео, підтримує трекінг об'єктів через кадри — для інтерактивного виділення об'єкта по точці або bbox це найкращий вибір з коробки. Для production instance segmentation без інтерактивного промпту — Mask R‑CNN або YOLOv8‑seg. YOLOv8‑seg навчається як звичайний детектор з додатковими масками, зручний у тих же пайплайнах. Семантична сегментація (кожен піксель — клас) — SegFormer, DeepLabV3+. SegFormer‑B5 дає хороший баланс точності та швидкості для аналізу супутникових знімків або медичної сегментації.

Кейс: сегментація клітин на мікроскопічних зображеннях. Датасет 400 зображень з ручною розміткою. Навчання Mask R‑CNN на ResNet‑50 backbone дало IoU 0.61 — погано. Проблема: об'єкти (клітини) перекриваються, стандартний NMS вбиває перекриваючі передбачення. Рішення: перехід на cellpose (спеціалізована архітектура для біомедичних задач) + soft‑NMS. IoU зріс до 0.79.

Коли Tesseract не справляється з OCR?

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

PaddleOCR — production‑grade рішення: виявлення текстових блоків + розпізнавання + структурний аналіз. Працює з коробки для 80+ мов, включаючи українську. Підтримує таблиці та документи зі складною структурою. Wikipedia: Оптичне розпізнавання символів. TrOCR (Microsoft) — трансформерний OCR з сильними результатами на рукописному тексті. Для українського рукописного тексту потрібен fine‑tuning: базова модель навчена переважно на латиниці.

Що робити, якщо Tesseract не справляється з розпізнаванням образів на документах?

Для задач «витягни дані з рахунку / договору / паспорта» використовуємо LayoutLMv3 або Donut — ці моделі розуміють layout документа, а не тільки текст. Інтеграція через Hugging Face Transformers, fine‑tuning на 200–500 розмічених документах. Типовий pipeline:

1. Preprocessing: deskew, denoising, binarization через OpenCV.
2. Виявлення текстових блоків: PaddleOCR detection або CRAFT.
3. Розпізнавання: PaddleOCR recognition або TrOCR.
4. Post‑processing: нормалізація, валідація через regex або LLM для структурованих полів.

Для документів з фіксованою структурою template matching + OCR точково по координатах часто надійніше за end‑to‑end рішення.

Face Recognition: ідентифікація та верифікація

Face recognition = detection + alignment + embedding + matching. Кожен етап важливий.

Detection: RetinaFace або InsightFace для точної локалізації обличчя та ключових точок. MTCNN — старіше, але надійне рішення. Embedding: ArcFace (InsightFace) — state‑of‑the‑art для face recognition embeddings. Моделі iresnet50/iresnet100 передтреновані на MS1MV3 (5M ідентичностей). Ембеддинг‑вектор 512 float32, порівняння за cosine similarity. Threshold tuning: поріг рішення — критичний параметр. При threshold 0.6 типовий FPR на LFW benchmark — 0.001, TPR — 0.985. У production threshold потрібно калібрувати під реальний distribution: люди в масках, зі зміненою зовнішністю, в різних умовах освітлення. Liveness detection обов'язковий: MiniFASNet — lightweight модель на CPU, FaceX‑Zoo містить кілька передтренованих liveness‑детекторів.

Відеоаналітика

Відео — послідовність кадрів плюс часовий вимір. Наївний підхід — детектувати на кожному кадрі — дорого.

Трекінг: ByteTrack та BoT‑SORT — стандарт для multi‑object tracking. Працюють поверх будь-якого детектора, додають persistent ID об'єктам між кадрами — це дає підрахунок об'єктів, трекі руху, velocity.

Оптимізація: не потрібно обробляти кожен кадр. Для статичних сцен детекція на кожному 5–10 кадрі, між ними — трекер. Для детекції подій (людина увійшла в зону) background subtraction (OpenCV MOG2) як lightweight pre‑filter перед нейромережевою детекцією. Action Recognition: SlowFast, VideoMAE для класифікації дій. Важкі моделі — для production використовуємо ONNX export + TensorRT або офлайн обробку.

Як виміряти якість моделі розпізнавання образів у продакшені?

Моніторинг якості — ключовий елемент MLOps. Відстежуємо:

• розподіл prediction confidence;
• частку low‑confidence передбачень (індикатор OOD‑даних);
• дрейф вхідних зображень через feature distribution (embeddings з backbone).

Падіння середньої confidence з 0.87 до 0.71 за тиждень — ранній сигнал про distribution shift. NVIDIA Triton Inference Server рекомендує відстежувати ці метрики через Prometheus. Наші сертифіковані інженери налаштовують моніторинг і гарантують SLA по якості інференсу.

Деплой CV‑моделей

Для онлайн інференсу використовуємо Triton Inference Server (NVIDIA) — production‑стандарт для serving CV‑моделей. Підтримує TensorRT, ONNX, PyTorch, dynamic batching, multiple instances. REST та gRPC API. Гарантуємо стабільну роботу під навантаженням.

Edge deployment: ONNX Runtime на ARM/x86 CPU. TensorFlow Lite для мобільних пристроїв. OpenVINO для Intel CPU/GPU/VPU — дає 2–3× приріст швидкості на Intel залізі порівняно з ONNX Runtime. Після деплою передаємо модель з документацією та навчаємо персонал.

Що входить в роботу

Терміни та вартість

Прототип детектора на існуючих даних — 1–2 тижні. Production‑система з оптимізацією під цільове залізо — 4–8 тижнів. Повний цикл включаючи розмітку даних (1000–5000 зображень) — 2–4 місяці. Вартість розраховується індивідуально під кожну задачу. Ми на ринку більше 5 років, реалізували 60+ проектів з комп'ютерного зору. Оцінимо ваш проект під ключ — замовте консультацію, щоб отримати розрахунок та технічну пропозицію.