Augmentation de Bounding Box en Détection : Formats, Erreurs et Meilleures Pratiques

Un article publié sur la plateforme Habr est consacré à une raison courante et souvent négligée de l'échec de l'entraînement des modèles de détection d'objets : non pas l'architecture du réseau elle-même, mais ce qui se passe avec les boîtes délimitatrices (bbox) — les rectangles d'annotation — après l'application des augmentations.

Où le balisage se rompt le plus souvent

L'auteur énumère les erreurs typiques qui ne causent pas l'arrêt du code avec une exception, mais qui corrompent silencieusement l'ensemble de données d'entraînement : format de coordonnées incorrectement spécifié (coord_format), confusion entre coordonnées normalisées et absolues, opérations de recadrage trop agressives et apparition de boîtes vides après filtrage des objets qui sont sortis du cadre. De telles erreurs ne causent pas d'échec explicite du pipeline — le modèle s'entraîne simplement sur un balisage déformé, et la baisse de qualité résultante est attribuée à l'architecture ou aux hyperparamètres, bien que la cause réside dans le prétraitement.

Le problème est aggravé par le fait que différents ensembles de données et différentes bibliothèques utilisent historiquement différentes conventions pour stocker les coordonnées de bbox : parfois ce sont les coordonnées de pixel absolues des coins supérieur gauche et inférieur droit, parfois des valeurs normalisées de zéro à un par rapport aux dimensions de l'image, et parfois — les coordonnées du centre de la boîte avec la largeur et la hauteur. Il suffit de confondre ces représentations une seule fois lors de la transmission du balisage entre les étapes du pipeline pour que l'entraînement se poursuive sans erreurs, mais le modèle apprend à localiser les objets non pas où ils sont réellement dans l'image.

• Bibliothèque discutée : Albumentations
• Formats de bbox supportés : COCO, YOLO, pascal_voc
• Paramètres clés : A.BboxParams, min_area, min_visibility
• Problème typique : RandomCrop fonctionne souvent mal pour les tâches de détection
• Source : Habr

Comment configurer correctement Albumentations ?

L'article détaille l'aspect pratique de la question à l'aide de l'exemple de la bibliothèque Albumentations — l'un des outils les plus courants d'augmentation d'images en vision par ordinateur. Il traite des formats de bbox supportés par la bibliothèque, de la configuration correcte du paramètre A.BboxParams, ainsi que de l'objectif des paramètres min_area et min_visibility, qui déterminent la taille minimale ou la visibilité d'un objet après transformation pour que la bbox soit considérée comme valide plutôt que d'être rejetée ou déformée.

Albumentations est largement utilisée précisément parce qu'elle peut transformer de manière synchrone une image et ses balisages associés — lors de la rotation, du retournement ou de la modification de l'échelle d'une image, la bibliothèque recalcule automatiquement les coordonnées de tous les bbox qu'elle contient, dispensant le développeur d'écrire cette logique manuellement. Mais cette même automatisation devient une source de problèmes si les paramètres A.BboxParams sont mal définis : la bibliothèque ne produira pas d'erreur, elle recalculera simplement les coordonnées conformément au format spécifié (même s'il est incorrect), et le développeur obtiendra un pipeline d'augmentation formellement correct mais en réalité corrompu.

Pourquoi RandomCrop n'est pas toujours un choix sûr

Une attention particulière dans le matériel est accordée à la raison pour laquelle RandomCrop ordinaire — une augmentation populaire pour la classification d'images — s'avère souvent être une mauvaise solution spécifiquement pour la détection d'objets. Lorsqu'un cadre est découpé aléatoirement, les objets sur les bords peuvent être découpés partiellement ou complètement, et sans un filtrage ultérieur prudent via min_area et min_visibility, le balisage contient soit des boîtes déformées, soit des boîtes complètement vides, que le modèle perçoit comme des données d'entraînement valides.

Le matériel s'adresse à ceux qui travaillent avec des formats de balisage populaires COCO, YOLO et pascal_voc et qui veulent comprendre pourquoi les augmentations "ne fonctionnent pas" — c'est-à-dire pourquoi l'ajout de transformations prêtes à l'emploi standard n'améliore pas, et parfois même aggrave, les métriques du modèle. La valeur pratique d'une telle analyse est qu'elle déplace l'accent du débogage des hyperparamètres et des architectures vers une source de problèmes beaucoup plus banale, mais fréquente — la correction des transformations géométriques du balisage, que les spécialistes de la vision par ordinateur sous-estiment souvent au début d'un projet.

Pour les équipes travaillant avec des ensembles de données de balisage industriel, une telle analyse est particulièrement précieuse au stade de la transition entre les formats : par exemple, lorsque les données sont balisées au format COCO, mais que l'entraînement est effectué sur une architecture attendant le format YOLO, ou vice versa. La conversion manuelle entre ces formats est une source fréquente d'erreurs insaisissables, et le matériel offre essentiellement une liste de contrôle des éléments à vérifier avant d'attribuer la basse qualité du modèle à l'architecture elle-même ou au manque de données.