Augmentation de bounding boxes en détection : formats, erreurs et bonnes pratiques

Habr a publié un article consacré à une cause fréquente et discrète d'échecs lors de l'entraînement de modèles de détection d'objets : non pas l'architecture du réseau, mais ce qu'il advient des bounding boxes (bbox), les cadres rectangulaires d'annotation, après l'application des augmentations.

Où l'annotation casse le plus souvent

L'auteur énumère des erreurs typiques qui ne font pas planter le code avec une exception, mais dégradent discrètement le jeu d'entraînement : un format de coordonnées mal indiqué (coord_format), une confusion entre coordonnées normalisées et absolues, des opérations de recadrage trop agressives, ainsi que l'apparition de boîtes vides après le filtrage des objets sortis du cadre. Ces erreurs ne provoquent aucune défaillance visible du pipeline : le modèle s'entraîne simplement sur des annotations faussées, et la baisse de qualité qui en résulte est imputée à l'architecture ou aux hyperparamètres, alors que la cause se trouve dans le prétraitement.

Le problème est aggravé par le fait que les datasets et les bibliothèques utilisent historiquement des conventions différentes pour stocker les coordonnées des bbox : tantôt des coordonnées absolues en pixels des coins supérieur gauche et inférieur droit, tantôt des valeurs normalisées de zéro à un par rapport à la taille de l'image, tantôt les coordonnées du centre de la boîte accompagnées de sa largeur et de sa hauteur. Il suffit de confondre une seule fois ces représentations lors du passage des annotations d'une étape à l'autre du pipeline pour que l'entraînement se poursuive sans erreur, tandis que le modèle apprend à chercher les objets là où ils ne se trouvent pas réellement dans l'image.

• Bibliothèque étudiée : Albumentations
• Formats de bbox pris en charge : COCO, YOLO, pascal_voc
• Paramètres clés : A.BboxParams, min_area, min_visibility
• Problème typique : RandomCrop convient souvent mal aux tâches de détection
• Source : Habr

Comment bien configurer Albumentations ?

L'article aborde le versant pratique avec Albumentations, l'un des outils d'augmentation d'images les plus répandus en vision par ordinateur. Il passe en revue les formats de bbox pris en charge par la bibliothèque, la configuration correcte de A.BboxParams, ainsi que le rôle de min_area et min_visibility, qui déterminent la taille ou la visibilité minimale qu'un objet doit conserver après la transformation pour que sa boîte soit encore considérée comme valide, plutôt qu'écartée ou déformée.

Albumentations est largement utilisée précisément parce qu'elle transforme de façon synchronisée l'image et ses annotations : lors d'une rotation, d'un miroir ou d'un changement d'échelle, la bibliothèque recalcule automatiquement les coordonnées de toutes les bbox, ce qui évite au développeur d'écrire cette logique à la main. Mais cette même automatisation devient une source de problèmes si les paramètres de A.BboxParams sont mal définis : la bibliothèque ne renverra aucune erreur, elle recalculera simplement les coordonnées selon le format indiqué (même erroné), et le développeur se retrouvera avec un pipeline d'augmentation qui fonctionne en apparence, mais qui est en réalité corrompu.

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

L'article s'attarde sur les raisons pour lesquelles le RandomCrop classique, une augmentation populaire en classification d'images, se révèle souvent une mauvaise solution pour la détection d'objets. Lors d'un recadrage aléatoire, les objets situés en bordure peuvent être coupés en partie ou en totalité, et sans filtrage rigoureux ensuite via min_area et min_visibility, l'annotation conserve des boîtes déformées, voire vides, que le modèle traite comme des données d'entraînement valides.

Le texte s'adresse à ceux qui travaillent avec les formats d'annotation courants COCO, YOLO et pascal_voc et veulent comprendre pourquoi les augmentations « ne fonctionnent pas », c'est-à-dire pourquoi l'ajout de transformations standard prêtes à l'emploi n'améliore pas les métriques du modèle, et les dégrade parfois. L'intérêt pratique de cette analyse est de déplacer le centre du débogage des hyperparamètres et des architectures vers une source de problèmes bien plus prosaïque mais fréquente : la justesse des transformations géométriques appliquées aux annotations, que les spécialistes de la vision par ordinateur sous-estiment souvent au démarrage d'un projet.

Pour les équipes qui travaillent avec des datasets d'annotation industriels, un tel décryptage est particulièrement utile lors du passage d'un format à l'autre : par exemple, quand les données sont annotées au format COCO alors que l'entraînement se fait sur une architecture attendant du YOLO, ou inversement. La conversion manuelle entre ces formats est une source fréquente d'erreurs difficiles à repérer, et l'article propose en substance une liste de vérifications à effectuer avant d'imputer la faible qualité du modèle à l'architecture elle-même ou à un manque de données.