Anchor Boxes
Les boîtes d’ancrage sont des boîtes prédéfinies de tailles et de rapports d’aspect fixes qu’un détecteur déplace et redimensionne pour ajuster aux objets. Comment elles sont dimensionnées, associées et utilisées.
Les boîtes d'ancrage sont des rectangles prédéfinis de taille et de rapport d'aspect fixes, répartis sur chaque position des cartes de caractéristiques d'un détecteur. Elles servent de premières estimations de l'emplacement et de la forme des objets. Un détecteur fondé sur des ancres attribue un score à chaque ancre pour chaque classe et prédit de petits décalages qui la déplacent et la redimensionnent pour l'ajuster à l'objet ; cette tâche est plus facile à apprendre que de prédire une boîte à partir de rien. Faster R-CNN place 9 ancres à chaque position : trois surfaces (128², 256² et 512² pixels) multipliées par trois rapports d'aspect (1:1, 1:2 et 2:1), soit environ 20 000 ancres pour une image de 1000 × 600.
Définition des ancres#
Un ensemble d'ancres est une liste de tailles et de rapports d'aspect répétée à chaque cellule d'une carte de caractéristiques ; le nombre d'ancres équivaut donc au nombre de cellules multiplié par le nombre de formes par cellule. Les détecteurs dotés d'un réseau pyramidal de caractéristiques (FPN) affectent les petites ancres aux niveaux fins à haute résolution et les grandes ancres aux niveaux grossiers : RetinaNet utilise 9 ancres par emplacement sur chacun de ses cinq niveaux, soit environ 100 000 par image. SSD les appelle boîtes par défaut, et SSD300 en répartit 8 732.
Les formes choisies manuellement s'adaptent mal à certains jeux de données. YOLOv2 a donc appliqué le regroupement k-means aux largeurs et hauteurs des boîtes d'entraînement, en utilisant 1 − IoU comme distance, et a conservé les 5 centres de groupes comme ancres. YOLOv3 a regroupé 9 ancres et les a réparties équitablement entre ses trois strides de sortie, de 10 × 13 pixels au niveau de stride 8 à 373 × 326 au niveau de stride 32.
Association des ancres aux objets#
Pendant l'entraînement, chaque ancre est comparée à chaque boîte annotée au moyen de l'intersection sur union (IoU). Les ancres qui chevauchent suffisamment un objet deviennent des exemples positifs et apprennent la classe de cet objet ainsi que les décalages de sa boîte englobante ; celles qui le chevauchent peu deviennent des exemples négatifs et apprennent la classe « arrière-plan », tandis que les ancres intermédiaires sont ignorées. Le réseau de propositions de régions de Faster R-CNN considère un IoU d'au moins 0,7 comme positif et un IoU inférieur à 0,3 comme négatif. Il rend également positive l'ancre la mieux appariée à chaque objet, afin qu'aucun objet ne soit laissé sans ancre.
import torch
from torchvision.ops import box_iou
# Nine anchors centered on one feature-map cell at (200, 200): 3 sizes x 3 aspect ratios (height / width)
shapes = [(size, ratio) for size in (64, 128, 256) for ratio in (0.5, 1.0, 2.0)]
anchors = []
for size, ratio in shapes:
w, h = size / ratio**0.5, size * ratio**0.5
anchors.append([200 - w / 2, 200 - h / 2, 200 + w / 2, 200 + h / 2])
# A labeled pedestrian box (x1, y1, x2, y2): tall and narrow
person = torch.tensor([[160.0, 110.0, 240.0, 290.0]])
# Faster R-CNN RPN rule: IoU >= 0.7 is positive, below 0.3 is negative, anything between is ignored
iou = box_iou(torch.tensor(anchors), person).squeeze(1)
for (size, ratio), value in zip(shapes, iou.tolist()):
label = "positive" if value >= 0.7 else "negative" if value < 0.3 else "ignored"
print(f"size {size}, ratio {ratio}: IoU {value:.2f} -> {label}")Seule l'ancre haute de 128 pixels (rapport 2,0) chevauche suffisamment le piéton pour être positive, avec un IoU de 0,88. Deux autres ancres de 128 pixels, avec des IoU de 0,31 et 0,50, sont ignorées, et les six ancres de taille incorrecte sont négatives. L'ancre positive apprend alors des décalages selon la paramétrisation standard : son centre se déplace d'une fraction de sa largeur et de sa hauteur, tandis que sa largeur et sa hauteur sont multipliées par l'exponentielle des valeurs prédites.
Choix des tailles d'ancre pour un jeu de données#
Des ancres adaptées aux formes des objets d'un jeu de données permettent à davantage d'objets d'avoir une ancre positive, ce qui augmente le rappel maximal du détecteur. Ultralytics YOLOv5 part des 9 ancres de YOLOv3 et les vérifie avant l'entraînement avec AutoAnchor : l'outil mesure le rappel maximal possible de ses ancres sur les annotations d'entraînement et, s'il ne dépasse pas 0,98, les réajuste avec k-means et 1 000 générations d'évolution génétique, en ne conservant les nouvelles ancres que si le rappel s'améliore.
Limites et détecteurs sans ancres#
Les ancres ont trois inconvénients. Presque toutes les dizaines de milliers d'ancres d'une image couvrent l'arrière-plan, ce qui submerge la fonction de perte d'exemples négatifs faciles ; RetinaNet a introduit la perte focale pour réduire leur poids. Plusieurs ancres voisines s'ajustent au même objet : la sortie nécessite donc une suppression non maximale (NMS) pour ne conserver qu'une boîte par objet. Les tailles, les rapports d'aspect et les seuils IoU sont également des hyperparamètres qui varient selon le jeu de données et la taille des images.
Les détecteurs sans ancres éliminent ces hyperparamètres en prédisant les boîtes à partir de points ou de points clés, et la plupart des détecteurs en temps réel publiés depuis YOLOX en 2021 sont sans ancres. Les ancres restent utilisées dans les détecteurs fondés sur des ancres, comme Faster R-CNN, Mask R-CNN et RetinaNet. En comparant RetinaNet au détecteur sans ancres FCOS, ATSS a constaté qu'une fois les exemples positifs sélectionnés de la même manière, RetinaNet avec 9 ancres par emplacement n'était pas plus précis qu'avec 1.










