Qué se midió
El pipeline es el mismo de la tesis: YOLOv8 detecta personas, un tracker les asigna identidad, y de esa identidad sale una serie de tiempo (x, y, w, h) que alimenta al clasificador.
La medición se corrió sobre MOT16, el mismo banco de pruebas sobre el que se publicó ByteTrack. Su ventaja no es el video: es que cada persona está anotada a mano en cada frame, incluido el porcentaje de su cuerpo que está visible. Eso convierte la oclusión en una variable medible en lugar de una impresión.
Eslabón 1El detector se queda ciego
La intermitencia descrita como azar es, medida contra el ground truth, una curva monótona.
No hay nada estocástico aquí. La probabilidad de detección está determinada por la oclusión, y el rango va del 99% con la persona despejada al 28% cuando queda tapada.
Eslabón 2La trayectoria queda con huecos
Cuando el detector no ve a alguien, ese frame simplemente no existe en su serie de tiempo.
A una quinta parte de cada trayectoria le faltan frames. Un clasificador de series temporales que recibe ventanas con vacíos irregulares no está viendo el movimiento: está viendo un movimiento entrecortado, distinto en cada pasada.
Eslabón 3La identidad se rompe
Y aquí los dos eslabones anteriores se combinan con un parámetro de fábrica.
ByteTrack mantiene viva una pista perdida durante track_buffer frames — 30 por defecto, un segundo a 30 fps. Si el hueco dura más que eso, la pista se da por muerta y la persona recibe una identidad nueva al reaparecer.
El 10.0% de los huecos supera ese umbral. El resultado: 63 cambios de identidad sobre 25 personas reales, con una visibilidad mediana de 0.0% en el momento de la rotura.
El 72.0% de las personas terminó repartida entre varias trayectorias, a un promedio de 2.88 identidades por persona. Si el evento a clasificar ocurre durante la oclusión, su firma queda partida entre dos muestras y ninguna la contiene entera.
Una hipótesis que los datos descartaron
Se esperaba encontrar un segundo mecanismo de falla. No apareció.
La hipótesis era que bajo oclusión parcial el detector recortaría la caja a la porción visible, entregando al clasificador un vector que dice «el cuerpo se acortó» —la firma de agacharse o caer— y produciendo falsos positivos.
El alto reportado se mantiene cerca del 97% del real en todos los niveles de oclusión. YOLOv8, entrenado sobre anotaciones que marcan la extensión completa de personas parcialmente tapadas, aprende a extrapolar la parte oculta en vez de recortar la caja.
El efecto existe pero es marginal: se registraron 24 caídas bruscas de altura en todo el metraje, y el 100.0% coincide con oclusión. Es un ruido real, no el mecanismo dominante. Bajo oclusión el detector no entrega una caja equivocada: no entrega ninguna.
Qué arregla cada cosa
Cuatro configuraciones sobre el mismo metraje, aislando una variable por vez.
| Configuracion | Personas partidas | IDs por persona | Cambios de ID | Recall sin oclusion | Recall con oclusion fuerte |
|---|---|---|---|---|---|
| ByteTrack (uso correcto)Configuracion de referencia: el tracker recibe tambien las detecciones de baja confianza, que es para lo que ByteTrack fue disenado. | 72.0% | 2.88 | 63 | 98.9% | 28.2% |
| ByteTrack con detecciones pre-filtradasEl error comun: filtrar por confianza antes del tracker (conf=0.50). Desactiva la segunda ronda de asociacion de ByteTrack. | 58.3% | 2.46 | 43 | 98.3% | 19.3% |
| ByteTrack con track_buffer 90El arreglo barato: mantener vivas las pistas perdidas 90 frames (3 s) en vez de 30 (1 s). | 68.0% | 2.8 | 62 | 98.9% | 28.2% |
| BoT-SORT con ReID «auto»Tracker con apariencia, pero en su ajuste por defecto: reutiliza las features del detector, entrenadas para encontrar personas, no para distinguirlas. | 72.0% | 3.44 | 82 | 99.5% | 28.3% |
| BoT-SORT con modelo ReID realEl mismo tracker con un modelo de re-identificacion dedicado, entrenado especificamente para reconocer a la misma persona. | 76.0% | 3.64 | 100 | 99.5% | 28.1% |
| ByteTrack + reparacion offlineEl mismo ByteTrack, pero con una segunda pasada que cose los fragmentos y rellena los huecos aprovechando que sobre un archivo el futuro ya esta grabado. | 60.0% | 2.4 | 66 | 99.2% | 55.8% |
Escena saturada
La misma medición sobre MOT16-04, con aproximadamente seis veces más personas por frame.
| Configuracion | Personas partidas | IDs por persona | Cambios de ID | Recall sin oclusion | Recall con oclusion fuerte |
|---|---|---|---|---|---|
| ByteTrack (uso correcto)Configuracion de referencia: el tracker recibe tambien las detecciones de baja confianza, que es para lo que ByteTrack fue disenado. | 53.4% | 2.52 | 155 | 96.2% | 10.9% |
| BoT-SORT con ReID «auto»Tracker con apariencia, pero en su ajuste por defecto: reutiliza las features del detector, entrenadas para encontrar personas, no para distinguirlas. | 63.0% | 3.01 | 237 | 96.2% | 11.6% |
| ByteTrack + reparacion offlineEl mismo ByteTrack, pero con una segunda pasada que cose los fragmentos y rellena los huecos aprovechando que sobre un archivo el futuro ya esta grabado. | 53.4% | 2.42 | 168 | 97.1% | 14.1% |
Lo que sí funciona: reparar en vez de cambiar de tracker
Un tracker en línea decide en el frame 143 sin saber qué pasa después. Sobre un archivo, esa es una limitación autoimpuesta.
El video completo ya está grabado: el futuro se puede consultar. Una segunda pasada recorre el resultado entero, une los fragmentos que evidentemente pertenecen a la misma persona —el fragmento A termina donde la inercia predice que empieza el B— rellena por interpolación los frames ausentes, y marca cuáles son reales y cuáles inventados.
Es post-proceso sobre una tabla de coordenadas: sin GPU, sin reentrenar, sin modelo nuevo. El mismo detector y el mismo tracker de antes.
Con cámaras en vivo no se puede ver todo el futuro, pero sí un poco: basta retener dos o tres segundos en un buffer y reparar dentro de esa ventana. No cuesta latencia adicional, porque el clasificador ya necesita una ventana temporal de ese tamaño para decidir.
Lo que la reparación no arregla: los frames interpolados son datos inventados. Si la conducta a detectar ocurrió dentro de la oclusión, ninguna reconstrucción la recupera — se obtiene una trayectoria suave y plausible que puede estar equivocada. Por eso el canal que marca qué frames son reales no es opcional: es lo que permite al clasificador desconfiar de lo que no se vio.
El mismo instante, antes y después de reparar
La caja blanca punteada es la persona real según el ground truth. La de color es la identidad que le asigna el sistema.
Qué cambia al pasar de archivos a cámaras
Todo lo anterior se midió procesando cada frame. Un sistema en vivo no siempre puede.
Con un archivo, si la inferencia tarda más de lo que dura un frame, el archivo simplemente demora más: no se pierde ninguno. Con una cámara, los frames llegan a ritmo fijo se procesen o no, y si el sistema no alcanza, los descarta. Para medir el efecto se submuestreó la misma secuencia, simulando un sistema que solo llega a procesar una fracción de lo que la cámara entrega.
| Ritmo de procesamiento | Personas partidas | IDs por persona | Cobertura |
|---|---|---|---|
| 30 fps efectivostodos los frames procesados · 525 frames evaluados | 72.0% | 2.88 | 77.8% |
| 15 fps efectivos1 de cada 2 frames · 263 frames evaluados | 66.7% | 2.46 | 80.0% |
| 10 fps efectivos1 de cada 3 frames · 175 frames evaluados | 70.8% | 3.12 | 74.2% |
| 6 fps efectivos1 de cada 5 frames · 105 frames evaluados | 83.3% | 4.17 | 72.4% |
El resultado no es una degradación lineal. A 15 fps el tracking incluso mejora levemente, y recién a 6 fps se derrumba: la fragmentación sube a 83% y las identidades por persona pasan de 2.88 a 4.17.
Son dos efectos opuestos. Al descartar frames, la gente se desplaza más entre un frame procesado y el siguiente, el solapamiento entre cajas cae y la asociación falla: eso empeora. Pero al mismo tiempo, track_buffer se cuenta en frames, no en segundos, así que los mismos 30 frames pasan a cubrir dos o cinco segundos de tiempo real en vez de uno: eso ayuda, porque tolera oclusiones más largas. Hasta 15 fps el segundo efecto compensa al primero; más abajo, el primero domina.
La consecuencia práctica es un parámetro que cambia de significado sin avisar: track_buffer mide frames. Si el sistema descarta frames, ese valor deja de representar el tiempo que se pensó al configurarlo, y conviene fijarlo como segundos deseados × fps efectivos en lugar de dejarlo en su valor de fábrica.
La detección apenas varía entre ritmos, lo cual es esperable: es una operación por frame, independiente de la cadencia. Las diferencias de recall en la tabla completa son ruido de muestreo, porque cada ritmo evalúa un subconjunto distinto y más pequeño de frames.
Lo que esto implica
- La falla no está en el clasificador. Está en los datos que recibe. Cambiar la arquitectura del modelo no mueve ninguno de estos números.
- Tampoco está en el hardware. Todo este análisis corrió en CPU, sin GPU de ningún tipo. Descartar frames hasta 15 fps no degrada el seguimiento; recién por debajo de 10 fps empieza a doler.
- Cambiar de tracker no alcanza. Se probaron cinco configuraciones, incluido BoT-SORT con un modelo de re-identificación dedicado: ninguna mejora la fragmentación. El que más identidades recupera es también el que más las confunde, porque mantiene vivas más pistas y toma más decisiones en una escena concurrida.
- Falta una capa intermedia. Entre el tracker y el clasificador no hay nada que marque los frames ocluidos, interpole los huecos ni propague un canal de confianza. El clasificador trata todos los frames como igual de fiables.