Комп'ютерний зір · R&D

jumpsight

Аналіз стрибка у фігурному катанні з одного відео зі смартфона, де кожне число йде разом із тим, наскільки система в ньому впевнена.

Рік
2026
Статус
R&D, власний рушій
Обсяг
959 комітів
Стек
Python · YOLOX · RTMPose · ONNX Runtime · OpenCV · SciPy · FastAPI · PostgreSQL
  • ±0.54похибка обертів на 1 705 стрибках (MMFS)
  • 91%Axel розпізнано (FS-Jump3D)
  • ±0.5–1кадра на приземленні, контрольний кліп
  • ~13 sна кліп на CPU, перші події через ~2 с

Задача

Тренери знімають на звичайні телефони: 30 fps, стиснення, часто ще й пересилання через Telegram. Стрибок триває близько пів секунди, один оберт займає приблизно чотири кадри, тож більшість чисел на межі того, що є у відео. Система має виміряти те, що може, і прямо сказати, чого не може.

Як це працює

  1. 01

    Перевірка й декодування

    Справжні часові мітки кадрів (телефони пишуть змінну частоту), бітрейт, швидкий прохід 360×640 по всьому кліпу та аудіо для звуку приземлення.

  2. 02

    Детекція й трекінг

    YOLOX-tiny на кожному третьому кадрі, IoU-трекінг і стабілізація фону тримають одну фігуристку, поки телефон рухається.

  3. 03

    Пошук спроб

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

  4. 04

    Поза в кожному кадрі

    RTMPose-m працює на вікнах повної роздільності навколо кожної спроби й повертає суглоби, з якими працює решта конвеєра.

  5. 05

    Час, оберти, тип

    Відрив і приземлення беруться з балістичної межі навколо апексу. Оберти рахують два незалежні канали. Дерево правил із дзеркаленням за напрямком визначає тип.

  6. 06

    Звіт, що визнає межі

    Кожне значення — об'єкт з інтервалом 68%, рівнем і статусом. Те, що виміряти неможливо, повертається як "absent" з машинною причиною, а не як правдоподібна вигадка.

Зліва: прогін системи на потрійному лутці з FS-Jump3D (CC BY-NC-SA 4.0). Справа: оригінал.Кроки 2–4 малюють реальний розв'язаний рух з мого конвеєра.

Відомі обмеження

  • На зубцевих стрибках відрив може визначатися до двох кадрів раніше: відпускання зубця не видно на рівні щиколотки. 60 fps це виправляє.
  • При ~7 обертах на секунду й 30 fps підрахунок обертів може «перескакувати». Тоді система відмовляє з AZIMUTH_ALIASING_SUSPECT, а не вгадує.
  • Lutz і Flip відрізняються ребром леза, яке на стисненому відео 30 fps часто не видно (76,5% для цієї пари).

Потрібно щось схоже?

Розкажіть про задачу й дані. Я відповім, як би підійшов до неї.

Обговорити проєкт →