Computer Vision · F&E

jumpsight

Analyse eines Eiskunstlaufsprungs aus einem einzigen Handyvideo – jede Zahl wird zusammen mit der Angabe geliefert, wie sicher sich das System ist.

Jahr
2026
Status
F&E, eigene Engine
Umfang
959 Commits
Stack
Python · YOLOX · RTMPose · ONNX Runtime · OpenCV · SciPy · FastAPI · PostgreSQL
  • ±0.54Rotationsfehler bei 1.705 Sprüngen (MMFS)
  • 91%Axel erkannt (FS-Jump3D)
  • ±0.5–1Frames bei der Landung, Kontrollclip
  • ~13 spro Clip auf der CPU, erste Ergebnisse nach ~2 s

Die Aufgabe

Trainer filmen mit gewöhnlichen Handys: 30 fps, komprimiert, oft über Telegram weitergeleitet. Ein Sprung dauert etwa eine halbe Sekunde, eine Umdrehung rund vier Frames, also liegen die meisten Zahlen am Rand dessen, was das Video enthält. Das System muss messen, was es kann, und klar sagen, was nicht.

So funktioniert es

  1. 01

    Prüfen und dekodieren

    Echte Frame-Zeitstempel (Handys nehmen mit variabler Bildrate auf), Bitrate, ein schneller 360×640-Durchlauf über den ganzen Clip und eine Tonspur für das Landegeräusch.

  2. 02

    Erkennen und verfolgen

    YOLOX-tiny auf jedem dritten Frame, IoU-Tracking und Hintergrundstabilisierung halten eine Läuferin im Fokus, während das Handy schwenkt.

  3. 03

    Sprungversuche finden

    Kinematik der Körperbox und eine ballistische Parabel markieren, wo die Läuferin das Eis verlässt. Ähnlich aussehende Pirouetten und Hebungen werden mit Begründung verworfen.

  4. 04

    Pose in jedem Frame

    RTMPose-m läuft auf Fenstern in voller Auflösung um jeden Versuch und liefert die Gelenke, die der Rest der Pipeline misst.

  5. 05

    Timing, Rotation, Sprungart

    Absprung und Landung ergeben sich aus der ballistischen Grenze um den Scheitelpunkt. Die Rotation nutzt zwei unabhängige Kanäle. Ein für die Drehrichtung gespiegelter Regelbaum benennt den Sprung.

  6. 06

    Ein Bericht, der Grenzen zugibt

    Jeder Wert ist ein Objekt mit 68-%-Intervall, Stufe und Status. Was nicht messbar ist, kommt als "absent" mit maschinenlesbarem Grund zurück, nie als plausible Schätzung.

Links: Durchlauf des Systems auf einem dreifachen Lutz aus FS-Jump3D (CC BY-NC-SA 4.0). Rechts: das Original.Schritte 2–4 zeigen echte berechnete Bewegung aus meiner Pipeline.

Bekannte Grenzen

  • Bei Zackensprüngen kann der Absprung bis zu zwei Frames zu früh erkannt werden: Das Lösen der Zacke ist auf Knöchelhöhe unsichtbar. Filmen mit 60 fps behebt das.
  • Bei etwa sieben Umdrehungen pro Sekunde und 30 fps kann das Zählen der Rotationen Aliasing erzeugen. Das System lehnt dann mit AZIMUTH_ALIASING_SUSPECT ab, statt zu raten.
  • Lutz und Flip unterscheiden sich durch die Kufenkante, die komprimiertes 30-fps-Video oft nicht zeigt (76,5 % bei diesem Paar).

Brauchen Sie etwas Ähnliches?

Erzählen Sie mir von Ihrer Aufgabe und Ihren Daten. Ich antworte mit einem Vorschlag, wie ich es angehen würde.

Projekt besprechen →