Vision par ordinateur · R&D

jumpsight

Analyse d’un saut de patinage artistique à partir d’une seule vidéo de téléphone, chaque chiffre étant livré avec le degré de certitude du système.

Année
2026
Statut
R&D, moteur maison
Ampleur
959 commits
Stack
Python · YOLOX · RTMPose · ONNX Runtime · OpenCV · SciPy · FastAPI · PostgreSQL
  • ±0.54erreur de rotation sur 1 705 sauts (MMFS)
  • 91%Axel reconnu (FS-Jump3D)
  • ±0.5–1images à la réception, clip de contrôle
  • ~13 spar clip sur CPU, premiers résultats après ~2 s

Le problème

Les entraîneurs filment avec des téléphones ordinaires : 30 i/s, compressé, souvent renvoyé via Telegram. Un saut dure environ une demi-seconde et une rotation à peu près quatre images, donc la plupart des chiffres sont à la limite de ce que contient la vidéo. Le système doit mesurer ce qu’il peut et dire clairement ce qu’il ne peut pas.

Comment ça marche

  1. 01

    Analyse et décodage

    Vrais horodatages des images (les téléphones enregistrent à cadence variable), débit, un passage rapide en 360×640 sur tout le clip et une piste audio pour le bruit de réception.

  2. 02

    Détection et suivi

    YOLOX-tiny une image sur trois, suivi IoU et stabilisation de l’arrière-plan gardent une patineuse au centre pendant que le téléphone bouge.

  3. 03

    Trouver les tentatives

    La cinématique du cadre du corps et une parabole balistique indiquent où la patineuse quitte la glace. Les spirales et portés qui y ressemblent sont rejetés avec une raison.

  4. 04

    La pose à chaque image

    RTMPose-m tourne sur des fenêtres en pleine résolution autour de chaque tentative et renvoie les articulations que le reste du pipeline mesure.

  5. 05

    Temps, rotation, type

    L’impulsion et la réception viennent de la borne balistique autour de l’apex. La rotation utilise deux canaux indépendants. Un arbre de règles, inversé selon le sens, nomme le saut.

  6. 06

    Un rapport qui reconnaît ses limites

    Chaque valeur est un objet avec un intervalle à 68 %, un niveau et un statut. Ce qui ne peut pas être mesuré revient comme "absent" avec une raison lisible par machine, jamais comme une estimation plausible.

À gauche : l’exécution du système sur un triple lutz de FS-Jump3D (CC BY-NC-SA 4.0). À droite : l’original.Les étapes 2 à 4 tracent un vrai mouvement calculé par mon pipeline.

Limites connues

  • Sur les sauts piqués, l’impulsion peut être lue jusqu’à deux images trop tôt : le dégagement de la pointe est invisible au niveau de la cheville. Filmer à 60 i/s corrige cela.
  • À environ sept tours par seconde et 30 i/s, le comptage des rotations peut subir un repliement. Le système refuse alors avec AZIMUTH_ALIASING_SUSPECT au lieu de deviner.
  • Le lutz et le flip diffèrent par la carre de la lame, que la vidéo compressée à 30 i/s montre rarement (76,5 % sur cette paire).

Besoin de quelque chose de similaire ?

Parlez-moi de votre tâche et de vos données. Je vous répondrai avec ma façon de l’aborder.

Parler d’un projet →