Aumento de datos con bounding boxes en detección: formatos, errores y buenas prácticas

En Habr ha aparecido un artículo sobre una causa frecuente y poco visible de los fallos al entrenar modelos de detección de objetos: no la arquitectura de la red, sino lo que ocurre con los bounding boxes (bbox), los marcos rectangulares de anotación, tras aplicar aumentaciones.

Dónde se rompe con más frecuencia la anotación

El autor enumera errores típicos que no hacen caer el código con una excepción, pero estropean en silencio el conjunto de entrenamiento: un formato de coordenadas mal indicado (coord_format), confusión entre coordenadas normalizadas y absolutas, operaciones de recorte demasiado agresivas y la aparición de cajas vacías tras filtrar los objetos que quedan fuera del encuadre. Estos errores no provocan un fallo evidente del pipeline: el modelo simplemente entrena con etiquetas distorsionadas, y la caída de calidad resultante se atribuye a la arquitectura o a los hiperparámetros, aunque la causa está en el preprocesamiento.

El problema se agrava porque distintos datasets y bibliotecas han usado históricamente convenciones diferentes para guardar las coordenadas de los bbox: unos emplean coordenadas absolutas en píxeles de las esquinas superior izquierda e inferior derecha, otros valores normalizados de cero a uno respecto al tamaño de la imagen, y otros las coordenadas del centro de la caja junto con su ancho y alto. Basta con confundir una sola vez estas representaciones al pasar las anotaciones entre etapas del pipeline para que el entrenamiento siga sin errores mientras el modelo aprende a buscar los objetos donde realmente no están en la imagen.

• Biblioteca analizada: Albumentations
• Formatos de bbox compatibles: COCO, YOLO, pascal_voc
• Parámetros clave: A.BboxParams, min_area, min_visibility
• Problema típico: RandomCrop suele encajar mal en tareas de detección
• Fuente: Habr

¿Cómo configurar Albumentations correctamente?

El artículo aborda el lado práctico con Albumentations, una de las herramientas de aumentación de imágenes más extendidas en visión artificial. Repasa los formatos de bbox que admite la biblioteca, la configuración correcta de A.BboxParams y la función de min_area y min_visibility, que determinan qué tamaño o visibilidad mínimos debe conservar un objeto tras la transformación para que su caja siga considerándose válida, en lugar de descartarse o distorsionarse.

Albumentations se usa mucho precisamente porque transforma de forma sincronizada la imagen y sus anotaciones: al girar, reflejar o reescalar la imagen, la biblioteca recalcula automáticamente las coordenadas de todos los bbox, de modo que el desarrollador no tiene que escribir esa lógica a mano. Pero esa misma automatización se convierte en fuente de problemas si los parámetros de A.BboxParams son incorrectos: la biblioteca no lanzará ningún error, simplemente recalculará las coordenadas según el formato indicado (aunque sea erróneo), y el desarrollador acabará con un pipeline de aumentación que formalmente funciona, pero que en la práctica está estropeado.

Por qué RandomCrop no siempre es una opción segura

El texto presta atención especial a por qué el RandomCrop habitual, una aumentación popular en clasificación de imágenes, resulta a menudo una mala solución para la detección de objetos. Al recortar el encuadre de forma aleatoria, los objetos de los bordes pueden quedar cortados parcial o totalmente, y sin un filtrado posterior cuidadoso mediante min_area y min_visibility, en la anotación quedan cajas distorsionadas o directamente vacías que el modelo toma como datos de entrenamiento válidos.

El material está dirigido a quienes trabajan con los formatos de anotación populares COCO, YOLO y pascal_voc y quieren entender por qué las aumentaciones «no funcionan», es decir, por qué añadir transformaciones estándar de serie no mejora las métricas del modelo e incluso a veces las empeora. El valor práctico del análisis está en que desplaza el foco de la depuración desde los hiperparámetros y las arquitecturas hacia una fuente de problemas mucho más prosaica pero frecuente: la corrección de las transformaciones geométricas de las anotaciones, que los especialistas en visión artificial suelen subestimar al arrancar un proyecto.

Para los equipos que trabajan con datasets de anotación industriales, un repaso así resulta especialmente útil en la transición entre formatos: por ejemplo, cuando los datos están anotados en COCO pero el entrenamiento se hace con una arquitectura que espera YOLO, o al revés. La conversión manual entre estos formatos es una fuente habitual de errores difíciles de detectar, y el artículo ofrece en esencia una lista de comprobación de cosas que conviene revisar antes de achacar la baja calidad del modelo a la propia arquitectura o a la falta de datos.