Aumento de Bounding Box en Detección: Formatos, Errores y Mejores Prácticas

Un artículo publicado en la plataforma Habr está dedicado a una razón común y frecuentemente ignorada para los fracasos en el entrenamiento de modelos de detección de objetos: no la arquitectura de la red en sí, sino lo que sucede con los cuadros delimitadores (bbox) — rectángulos de anotación — después de que se aplican aumentaciones.

Dónde se rompe más frecuentemente el marcado

El autor enumera errores típicos que no causan que el código falle con una excepción, pero corrompen silenciosamente el conjunto de datos de entrenamiento: formato de coordenadas especificado incorrectamente (coord_format), confusión entre coordenadas normalizadas y absolutas, operaciones de recorte demasiado agresivas y la aparición de cuadros vacíos después de filtrar objetos que se han salido del marco. Tales errores no causan un fallo explícito del pipeline — el modelo simplemente se entrena en marcado distorsionado, y la caída de calidad resultante se atribuye a la arquitectura o hiperparámetros, aunque la causa radica en el preprocesamiento.

El problema se agrava por el hecho de que diferentes conjuntos de datos y diferentes bibliotecas usan históricamente diferentes convenciones para almacenar coordenadas de bbox: a veces son coordenadas de píxeles absolutas de las esquinas superior izquierda e inferior derecha, a veces valores normalizados de cero a uno relativos a las dimensiones de la imagen, y a veces — coordenadas del centro del cuadro junto con ancho y alto. Es suficiente confundir estas representaciones una sola vez al pasar marcado entre etapas de pipeline para que el entrenamiento continúe sin errores, pero el modelo aprende a encontrar objetos no donde realmente están en la imagen.

• Biblioteca discutida: Albumentations
• Formatos de bbox admitidos: COCO, YOLO, pascal_voc
• Parámetros clave: A.BboxParams, min_area, min_visibility
• Problema típico: RandomCrop a menudo funciona mal para tareas de detección
• Fuente: Habr

¿Cómo configurar correctamente Albumentations?

El artículo desglosa el lado práctico del asunto usando el ejemplo de la biblioteca Albumentations — una de las herramientas de aumento de imágenes más comunes en visión por computadora. Discute los formatos de bbox admitidos por la biblioteca, la configuración correcta del parámetro A.BboxParams, así como el propósito de los parámetros min_area y min_visibility, que determinan el tamaño mínimo o la visibilidad de un objeto después de la transformación para que el bbox aún se considere válido en lugar de descartarse o distorsionarse.

Albumentations se usa ampliamente precisamente porque puede transformar sincrónicamente una imagen y su marcado asociado — al rotar, reflejar o cambiar la escala de una imagen, la biblioteca recalcula automáticamente las coordenadas de todos los bbox en ella, eximiendo al desarrollador de escribir esta lógica manualmente. Pero esta misma automatización se convierte en una fuente de problemas si los parámetros de A.BboxParams se configuran incorrectamente: la biblioteca no producirá un error, simplemente recalculará las coordenadas de acuerdo con el formato especificado (aunque sea incorrecto), y el desarrollador obtendrá un pipeline de aumento formalmente correcto pero de hecho corrupto.

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

La atención especial en el material se dedica a por qué RandomCrop ordinario — un aumento popular para clasificación de imágenes — frecuentemente resulta ser una solución deficiente específicamente para detección de objetos. Cuando un marco se recorta aleatoriamente, los objetos en los bordes pueden ser recortados parcial o completamente, y sin un filtrado posterior cuidadoso a través de min_area y min_visibility, el marcado contiene cuadros distorsionados u cuadros completamente vacíos, que el modelo percibe como datos de entrenamiento válidos.

El material se dirige a quienes trabajan con formatos de marcado populares COCO, YOLO y pascal_voc y desean entender por qué las aumentaciones "no funcionan" — es decir, por qué agregar transformaciones estándar listas para usar no mejora, e incluso a veces empeora, métricas de modelos. El valor práctico de tal desglose es que cambia el enfoque de depuración de hiperparámetros y arquitecturas a una fuente de problemas mucho más mundana, pero frecuente — la corrección de las transformaciones geométricas del marcado, que los especialistas en visión por computadora frecuentemente subestiman al inicio de un proyecto.

Para equipos que trabajan con conjuntos de datos de marcado industrial, tal desglose es especialmente valioso en la etapa de transición entre formatos: por ejemplo, cuando los datos se marcan en formato COCO, pero el entrenamiento se realiza en una arquitectura que espera formato YOLO, o viceversa. La conversión manual entre tales formatos es una fuente frecuente de errores elusivos, y el material esencialmente ofrece una lista de verificación de cosas que vale la pena verificar antes de atribuir la baja calidad del modelo a la arquitectura en sí o falta de datos.