Visión por computador · I+D

jumpsight

Análisis de un salto de patinaje artístico a partir de un único vídeo de móvil, entregando cada número junto con lo seguro que está el sistema de él.

Año
2026
Estado
I+D, motor propio
Escala
959 commits
Stack
Python · YOLOX · RTMPose · ONNX Runtime · OpenCV · SciPy · FastAPI · PostgreSQL
  • ±0.54error de rotación en 1705 saltos (MMFS)
  • 91%Axel reconocido (FS-Jump3D)
  • ±0.5–1fotogramas en el aterrizaje, clip de control
  • ~13 spor clip en CPU, primeros resultados en ~2 s

El problema

Los entrenadores graban con móviles normales: 30 fps, comprimido, a menudo reenviado por Telegram. Un salto dura cerca de medio segundo y una vuelta unos cuatro fotogramas, así que la mayoría de los números están al límite de lo que contiene el vídeo. El sistema debe medir lo que puede y decir claramente lo que no.

Cómo funciona

  1. 01

    Revisión y decodificación

    Marcas de tiempo reales de los fotogramas (los móviles graban con frecuencia variable), bitrate, una pasada rápida a 360×640 por todo el clip y una pista de audio para el sonido del aterrizaje.

  2. 02

    Detección y seguimiento

    YOLOX-tiny en uno de cada tres fotogramas, seguimiento IoU y estabilización del fondo mantienen enfocada a una patinadora mientras el móvil se mueve.

  3. 03

    Encontrar los intentos

    La cinemática del recuadro del cuerpo y una parábola balística marcan dónde la patinadora deja el hielo. Las espirales y elevaciones parecidas se descartan indicando el motivo.

  4. 04

    Pose en cada fotograma

    RTMPose-m trabaja sobre ventanas a resolución completa alrededor de cada intento y devuelve las articulaciones que mide el resto del pipeline.

  5. 05

    Tiempo, rotación, tipo

    El despegue y el aterrizaje salen del límite balístico alrededor del punto más alto. La rotación usa dos canales independientes. Un árbol de reglas, reflejado según el sentido, nombra el salto.

  6. 06

    Un informe que reconoce sus límites

    Cada valor es un objeto con un intervalo del 68 %, un nivel y un estado. Lo que no se puede medir vuelve como "absent" con un motivo legible por máquina, nunca como una suposición plausible.

Izquierda: ejecución del sistema sobre un triple lutz de FS-Jump3D (CC BY-NC-SA 4.0). Derecha: el original.Los pasos 2–4 dibujan movimiento real calculado por mi pipeline.

Límites conocidos

  • En los saltos de puntera el despegue puede detectarse hasta dos fotogramas antes: la liberación de la puntera no se ve a la altura del tobillo. Grabar a 60 fps lo soluciona.
  • A unas siete vueltas por segundo y 30 fps, el conteo de rotaciones puede sufrir aliasing. Entonces el sistema se niega con AZIMUTH_ALIASING_SUSPECT en lugar de adivinar.
  • El lutz y el flip se distinguen por el filo de la cuchilla, que el vídeo comprimido a 30 fps a menudo no muestra (76,5 % en ese par).

¿Necesitas algo parecido?

Cuéntame tu tarea y tus datos. Te responderé con cómo lo abordaría.

Hablemos de tu proyecto →