{"notes":[{"id":"object-detection/dino-detr","category":"object-detection","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"DINO","subtitle":"Proche, mais pas assez","author":"Z. Yuan","paperDate":"2022-03-07","publishedOn":"2024-12-19","world":"external/dino-detector","paperTitle":"DINO: DETR with Improved DeNoising Anchor Boxes for End-to-End Object Detection","paperUrl":"https://arxiv.org/abs/2203.03605","bibliography":{"title":"DINO: DETR with Improved DeNoising Anchor Boxes for End-to-End Object Detection","authors":["Hao Zhang","Feng Li","Shilong Liu","Lei Zhang","Hang Su","Jun Zhu","Lionel M. Ni","Heung-Yeung Shum"],"url":"https://arxiv.org/abs/2203.03605","pdfUrl":"https://arxiv.org/pdf/2203.03605v4","codeUrl":"https://github.com/IDEA-Research/DINO","preprint":{"id":"2203.03605","submittedOn":"2022-03-07","url":"https://arxiv.org/abs/2203.03605"},"publication":{"venue":"ICLR","year":2023,"kind":"conference","url":"https://iclr.cc/virtual/2023/poster/11884"},"citation":"@misc{objectdetectiondinodetr2022,\n  title = {{DINO: DETR with Improved DeNoising Anchor Boxes for End-to-End Object Detection}},\n  author = {Hao Zhang and Feng Li and Shilong Liu and Lei Zhang and Hang Su and Jun Zhu and Lionel M. Ni and Heung-Yeung Shum},\n  year = {2022},\n  eprint = {2203.03605},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2203.03605}\n}\n","citationPath":"/content/papers/citations/object-detection/dino-detr.d8c8af775089.bib"},"thumbnail":{"src":"/content/papers/assets/6c328e7125d4762c3a4346a1c537cb4e917d47a640869bbf212de53f74ba64fc.png","width":942,"height":319},"locale":"fr","path":"/content/papers/fr/object-detection/dino-detr.8af15f0a0be1.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"vue-densemble","text":"Vue d'ensemble","depth":3},{"id":"débruitage-contrastif","text":"Débruitage contrastif","depth":3},{"id":"sélection-de-requêtes-mixte","text":"Sélection de requêtes mixte","depth":3},{"id":"look-forward-twice","text":"Look forward twice","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"12-époques","text":"12 époques","depth":3},{"id":"entraîner-plus-longtemps","text":"Entraîner plus longtemps","depth":3},{"id":"la-case-du-classement","text":"La case du classement","depth":3},{"id":"ablation-comment-sempilent-les-494","text":"Ablation : comment s'empilent les 49,4","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"contrastive-learning/dino","relation":"referenced","topic":""},{"id":"object-detection/detr","relation":"referenced","topic":""},{"id":"object-detection/deformable-detr","relation":"referenced","topic":""}]},{"id":"contrastive-learning/dino","category":"contrastive-learning","legacyPath":"contrastive-learning/2104-dino","legacySlug":"2104-dino","legacyPaths":[],"title":"DINO","subtitle":"L'autodistillation sans étiquettes","author":"Z. Yuan","paperDate":"2021-04-29","publishedOn":"2025-03-18","paperTitle":"Emerging Properties in Self-Supervised Vision Transformers","paperUrl":"https://arxiv.org/abs/2104.14294","bibliography":{"title":"Emerging Properties in Self-Supervised Vision Transformers","authors":["Mathilde Caron","Hugo Touvron","Ishan Misra","Hervé Jégou","Julien Mairal","Piotr Bojanowski","Armand Joulin"],"url":"https://arxiv.org/abs/2104.14294","pdfUrl":"https://arxiv.org/pdf/2104.14294","codeUrl":null,"preprint":{"id":"2104.14294","submittedOn":"2021-04-29","url":"https://arxiv.org/abs/2104.14294"},"publication":{"venue":"ICCV","year":2021,"kind":"conference","url":"https://doi.org/10.1109/iccv48922.2021.00951"},"citation":"@misc{contrastivelearningdino2021,\n  title = {{Emerging Properties in Self-Supervised Vision Transformers}},\n  author = {Mathilde Caron and Hugo Touvron and Ishan Misra and Hervé Jégou and Julien Mairal and Piotr Bojanowski and Armand Joulin},\n  year = {2021},\n  eprint = {2104.14294},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2104.14294}\n}\n","citationPath":"/content/papers/citations/contrastive-learning/dino.20875c1e301c.bib"},"thumbnail":{"src":"/content/papers/assets/c2d0ab75afb02750e17183e186f29b0ef6e184eda12673a31c96f199e338188f.jpg","width":664,"height":642},"locale":"fr","path":"/content/papers/fr/contrastive-learning/dino.aa46b375c3ec.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"éviter-leffondrement","text":"Éviter l'effondrement","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"comparaison-avec-dautres-méthodes","text":"Comparaison avec d'autres méthodes","depth":3},{"id":"importance-des-composants","text":"Importance des composants","depth":3},{"id":"tester-leffondrement","text":"Tester l'effondrement","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"contrastive-learning/dinov2","relation":"next","topic":"Auto-distillation des représentations visuelles"}]},{"id":"object-detection/detr","category":"object-detection","legacyPath":"object-detection/2005-detr","legacySlug":"2005-detr","legacyPaths":[],"title":"DETR","subtitle":"Un pionnier entre deux domaines","author":"Z. Yuan","paperDate":"2020-05-26","publishedOn":"2024-06-04","paperTitle":"End-to-End Object Detection with Transformers","paperUrl":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/html/832_ECCV_2020_paper.php","bibliography":{"title":"End-to-End Object Detection with Transformers","authors":["Nicolas Carion","Francisco Massa","Gabriel Synnaeve","Nicolas Usunier","Alexander Kirillov","Sergey Zagoruyko"],"url":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/html/832_ECCV_2020_paper.php","pdfUrl":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/papers/123460205.pdf","codeUrl":"https://github.com/facebookresearch/detr","preprint":{"id":"2005.12872","submittedOn":"2020-05-26","url":"https://arxiv.org/abs/2005.12872"},"publication":{"venue":"ECCV","year":2020,"kind":"conference","url":"https://www.ecva.net/papers/eccv_2020/papers_ECCV/html/832_ECCV_2020_paper.php"},"citation":"@misc{objectdetectiondetr2020,\n  title = {{End-to-End Object Detection with Transformers}},\n  author = {Nicolas Carion and Francisco Massa and Gabriel Synnaeve and Nicolas Usunier and Alexander Kirillov and Sergey Zagoruyko},\n  year = {2020},\n  eprint = {2005.12872},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2005.12872}\n}\n","citationPath":"/content/papers/citations/object-detection/detr.5258ffe0b9a0.bib"},"thumbnail":{"src":"/content/papers/assets/dd7e8441e6460ff562cf558374789924518fafaed7ecde0e3e35ee778c316330.jpg","width":1024,"height":266},"locale":"fr","path":"/content/papers/fr/object-detection/detr.5137ffe05d95.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"architecture-du-modèle","text":"Architecture du modèle","depth":3},{"id":"conception-de-la-perte","text":"Conception de la perte","depth":3},{"id":"jeu-de-données","text":"Jeu de données","depth":3},{"id":"détails-techniques","text":"Détails techniques","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"alors-ça-marche-cette-fois-","text":"Alors, ça marche cette fois ?","depth":3},{"id":"analyse-des-composants-du-modèle","text":"Analyse des composants du modèle","depth":3},{"id":"analyse-du-comportement-du-modèle","text":"Analyse du comportement du modèle","depth":3},{"id":"généralisation-à-un-nombre-dobjets-inédit","text":"Généralisation à un nombre d'objets inédit","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/deformable-detr","relation":"next","topic":"Prédiction d’ensembles et détection par attention"},{"id":"object-detection/smca-detr","relation":"comparison","topic":"Accélérer la convergence des détecteurs Transformer"}]},{"id":"object-detection/deformable-detr","category":"object-detection","legacyPath":"object-detection/2010-deformable-detr","legacySlug":"2010-deformable-detr","legacyPaths":[],"title":"Deformable DETR","subtitle":"Une attention déformable","author":"Z. Yuan","paperDate":"2020-10-08","publishedOn":"2024-09-20","paperTitle":"Deformable DETR: Deformable Transformers for End-to-End Object Detection","paperUrl":"https://arxiv.org/abs/2010.04159","bibliography":{"title":"Deformable DETR: Deformable Transformers for End-to-End Object Detection","authors":["Xizhou Zhu","Weijie Su","Lewei Lu","Bin Li","Xiaogang Wang","Jifeng Dai"],"url":"https://arxiv.org/abs/2010.04159","pdfUrl":"https://arxiv.org/pdf/2010.04159","codeUrl":null,"preprint":{"id":"2010.04159","submittedOn":"2020-10-08","url":"https://arxiv.org/abs/2010.04159"},"publication":{"venue":"ICLR","year":2021,"kind":"conference","url":"https://arxiv.org/abs/2010.04159"},"citation":"@misc{objectdetectiondeformabledetr2020,\n  title = {{Deformable DETR: Deformable Transformers for End-to-End Object Detection}},\n  author = {Xizhou Zhu and Weijie Su and Lewei Lu and Bin Li and Xiaogang Wang and Jifeng Dai},\n  year = {2020},\n  eprint = {2010.04159},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2010.04159}\n}\n","citationPath":"/content/papers/citations/object-detection/deformable-detr.df721a30472e.bib"},"thumbnail":{"src":"/content/papers/assets/36edfc5595a85c73fcdc9a4bbb9e1ca512e1f100676eb7c37203d71c84905c05.jpg","width":1224,"height":752},"locale":"fr","path":"/content/papers/fr/object-detection/deformable-detr.b9cc2a2d8b0f.md","headings":[{"id":"définition-du-problème","text":"Définition du problème","depth":2},{"id":"résolution-du-problème","text":"Résolution du problème","depth":2},{"id":"attention-déformable","text":"Attention déformable","depth":3},{"id":"calcul-multi-échelle","text":"Calcul multi-échelle","depth":3},{"id":"architecture-du-modèle","text":"Architecture du modèle","depth":3},{"id":"lecture-du-code","text":"Lecture du code","depth":3},{"id":"stratégie-dentraînement","text":"Stratégie d'entraînement","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"comparaison-avec-detr","text":"Comparaison avec DETR","depth":3},{"id":"étude-dablation","text":"Étude d'ablation","depth":3},{"id":"comparaison-avec-les-meilleures-méthodes","text":"Comparaison avec les meilleures méthodes","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/detr","relation":"background","topic":"Prédiction d’ensembles et détection par attention"},{"id":"object-detection/h-detr","relation":"next","topic":"Prédiction d’ensembles et détection par attention"},{"id":"object-detection/smca-detr","relation":"comparison","topic":"Accélérer la convergence des détecteurs Transformer"}]}],"text":"Ici, DINO est l'abréviation de DETR with Improved deNoising anchOr boxes. Il n'a rien à voir avec le [DINO](/blog/papers/contrastive-learning/dino) d'apprentissage auto-supervisé présenté dans une autre note du site ; seuls les noms se télescopent.\n\nDébut 2022, les détecteurs en tête du classement COCO test-dev, comme SwinV2-G et Florence, branchent tous de grands backbones sur des têtes de détection classiques comme HTC++ ou DyHead, et ont encore besoin de la NMS à l'inférence pour supprimer les doublons. Les articles de la lignée DETR comparent surtout, avec ResNet-50, qui converge le plus vite ; les auteurs écrivent en introduction que personne n'avait encore rapporté ce que donne un modèle de type DETR une fois doté d'un grand backbone et nourri de grandes quantités de données.\n\nDINO comble ce manque. Avec un backbone SwinL préentraîné sur Objects365, il obtient 63,3 AP sur COCO test-dev. Selon les auteurs, c'est la première fois qu'un détecteur Transformer de bout en bout dépasse au classement COCO le meilleur modèle de l'époque. La même conception, ramenée à ResNet-50 et entraînée seulement 12 époques, atteint aussi 49,4 AP.\n\nL'architecture générale de DETR reste en place. Le squelette vient de Deformable DETR, DAB-DETR et DN-DETR, et les auteurs y apportent trois modifications, dont la première concerne l'entraînement par débruitage. DN-DETR apprend seulement au modèle à corriger des boîtes décalées ; DINO lui apprend en plus à répondre « il n'y a rien ici » pour certaines boîtes.\n\n## Définir le problème\n\nUn peu de contexte d'abord. DETR prépare un ensemble de requêtes (query) en nombre fixe, et chaque requête produit une classe et une boîte. À l'entraînement, l'algorithme hongrois attribue chaque objet annoté à une seule requête, et les autres requêtes ont pour cible « pas d'objet ». Un modèle entraîné ainsi se passe de NMS à l'inférence, au prix d'une convergence très lente.\n\nAu cours des deux années suivantes, plusieurs articles ont chacun comblé une lacune, et DINO s'appuie directement sur ces trois-là :\n\n- **Deformable DETR** : l'attention ne regarde qu'un petit nombre de points d'échantillonnage autour d'un point de référence, ce qui accélère le calcul comme la convergence. Il propose aussi une initialisation des requêtes en deux étapes (two-stage) et la correction des boîtes couche par couche dans le décodeur.\n- **DAB-DETR** : la requête est séparée en une partie position et une partie contenu ; la partie position s'écrit directement comme une boîte d'ancrage $(x, y, w, h)$, que chaque couche du décodeur corrige une fois. Dans la suite, « boîte d'ancrage » a toujours ce sens.\n- **DN-DETR** : selon lui, la lenteur de convergence vient de l'instabilité de l'appariement, une même requête pouvant être appariée à un objet à un tour et à un autre au tour suivant. Pendant l'entraînement, il fournit au décodeur des boîtes annotées bruitées comme requêtes supplémentaires et lui demande de retrouver les boîtes d'origine. Les réponses de ces requêtes sont connues d'avance, sans besoin d'appariement hongrois.\n\nSur cette base, les auteurs voient trois lacunes.\n\nLa première concerne le débruitage. Les boîtes bruitées de DN-DETR restent toutes proches de la boîte annotée, et le modèle apprend qu'« une boîte d'ancrage avec un objet à proximité doit être corrigée vers cet objet ». Les auteurs relèvent qu'il n'apprend jamais à faire répondre « pas d'objet » à une boîte d'ancrage sans objet à proximité.\n\nQuel problème cela pose-t-il ? D'après l'analyse des auteurs au §3.3, quand plusieurs boîtes d'ancrage sont proches d'un même objet, le modèle a du mal à décider laquelle utiliser. S'il choisit mal, le même objet peut être encadré plusieurs fois, ou bien c'est une boîte d'ancrage plus éloignée qui est retenue. DETR compte à l'origine sur l'appariement un à un et sur l'auto-attention entre requêtes pour étouffer les doublons ; les auteurs reconnaissent que cette capacité est limitée.\n\nLa deuxième concerne l'initialisation des requêtes. Les boîtes d'ancrage de DN-DETR sont des valeurs fixes apprises, et chaque image part du même ensemble de positions. L'approche en deux étapes de Deformable DETR, elle, choisit dans l'encodeur les positions de score le plus élevé et s'en sert pour initialiser les requêtes, position et contenu compris. Les auteurs jugent la moitié contenu peu fiable, car les caractéristiques choisies dans l'encodeur sont encore grossières et peuvent couvrir deux objets à la fois, ou seulement une partie d'un objet.\n\nLa troisième concerne la correction couche par couche. Deformable DETR fait corriger par chaque couche du décodeur la boîte de la couche précédente, mais coupe le gradient entre les couches, si bien que chaque couche n'apprend que de sa propre perte. Les auteurs supposent qu'une boîte mieux corrigée par la couche suivante devrait aussi pouvoir aider la couche précédente.\n\nDes trois lacunes, la première touche directement aux doublons. Si, pendant le débruitage, on n'apprend au modèle qu'à ramener les boîtes vers leur cible, saura-t-il lâcher prise ?\n\n\n> [!TIP]\n> \n> Pour le détail de DETR, Deformable DETR et DN-DETR, voir nos notes :\n> \n> - **[[20.05] DETR : un pionnier entre deux domaines](/blog/papers/object-detection/detr)**\n> - **[[20.10] Deformable DETR : une attention déformable](/blog/papers/object-detection/deformable-detr)**\n> - **[[22.03] DN-DETR : aujourd'hui le chien, demain le chat](/blog/papers/object-detection/dn-detr)**\n\n\n## Résoudre le problème\n\n### Vue d'ensemble\n\nComme un modèle de type DETR ordinaire, DINO se compose d'un backbone, de six couches d'encodeur Transformer, de six couches de décodeur, et de têtes de prédiction pour la classe et la boîte. Le schéma d'architecture de l'article indique où se placent les nouvelles modifications :\n\n[![Schéma d'architecture de DINO. À gauche, les caractéristiques multi-échelles et l'encodage positionnel sont aplatis puis envoyés dans l'encodeur ; au-dessus de l'encodeur, Query Selection choisit des positions, transmises via Init Anchors au décodeur comme boîtes d'ancrage initiales, à côté des requêtes de contenu apprenables ; à droite du décodeur, une ligne en tirets délimite le CDN, qui produit des requêtes positives et négatives à partir des boîtes annotées bruitées](/content/papers/assets/6c328e7125d4762c3a4346a1c537cb4e917d47a640869bbf212de53f74ba64fc.png)](/content/papers/assets/6c328e7125d4762c3a4346a1c537cb4e917d47a640869bbf212de53f74ba64fc.png)\n\n*Zhang et al., Figure 2 de l'article original, extraite de la [**page 6 du PDF v4**](https://arxiv.org/pdf/2203.03605v4#page=6). Architecture d'ensemble de DINO.*\n\nPartons de la gauche. Les caractéristiques multi-échelles, aplaties et additionnées de l'encodage positionnel, entrent dans l'encodeur. Au-dessus de l'encodeur, Query Selection choisit des positions dans la sortie et les transmet, le long de la ligne Init Anchors, jusqu'au bas du décodeur, où elles servent de boîtes d'ancrage initiales ; à côté, les Learnable Content Queries sont des vecteurs de contenu apprenables, et l'ensemble forme la sélection de requêtes mixte. Le CDN, isolé par une ligne en tirets à droite du décodeur, correspond aux requêtes de débruitage ajoutées à l'entraînement ; produites à partir des boîtes annotées bruitées (GT+Noise), elles se divisent en positifs (Pos) et négatifs (Neg). Look forward twice intervient entre les couches du décodeur et n'est pas dessiné sur la figure.\n\nDans l'ordre du flux de données, une image passe par les étapes suivantes :\n\n1. Le backbone extrait des caractéristiques multi-échelles. La version 4-scale prend les sorties des étages 2 à 4 du backbone et sous-échantillonne une fois de plus l'étage 4 pour obtenir quatre niveaux ; la version 5-scale ajoute l'étage 1, c'est-à-dire le niveau de plus haute résolution.\n2. L'encodeur organise ces caractéristiques avec l'attention déformable.\n3. **Sélection de requêtes mixte** : les 900 positions de score le plus élevé sont choisies dans la sortie de l'encodeur, et les boîtes qu'elles prédisent servent de boîtes d'ancrage initiales au décodeur.\n4. Le décodeur corrige ces 900 boîtes d'ancrage couche par couche, en propageant le gradient avec **look forward twice**. À l'entraînement, le décodeur reçoit en plus un lot de requêtes de **débruitage contrastif** (Contrastive DeNoising, CDN).\n5. Les têtes de prédiction produisent classes et boîtes. Les 900 requêtes sont appariées aux annotations par l'algorithme hongrois ; les réponses des requêtes de débruitage étant connues d'avance, leur perte se calcule directement.\n\nÀ l'inférence, le lot de requêtes de débruitage disparaît entièrement, et il ne reste que les 900 requêtes. Le [code officiel](https://github.com/IDEA-Research/DINO) aplatit les scores des 900 requêtes sur toutes les classes et garde les 300 plus élevés comme sortie ; une même requête peut donc apparaître deux fois, avec deux classes différentes. Aucune NMS ne suit ; le fichier de configuration garde un interrupteur NMS (`nms_iou_threshold`), réglé par défaut à -1, c'est-à-dire désactivé.\n\n### Débruitage contrastif\n\nDN-DETR n'a qu'une échelle de bruit $\\lambda$, et toute boîte dont le bruit ne dépasse pas $\\lambda$ doit être ramenée à la boîte annotée. DINO utilise deux échelles $\\lambda_1 < \\lambda_2$ et répartit les boîtes bruitées en deux catégories :\n\n- **Positifs** : bruit inférieur à $\\lambda_1$, à ramener à la boîte annotée. La perte combine L1 et GIoU pour la boîte, plus la focal loss de classification.\n- **Négatifs** : bruit compris entre $\\lambda_1$ et $\\lambda_2$, avec pour réponse « pas d'objet ». Seule la focal loss de classification est calculée, sans perte sur la boîte.\n\nChaque boîte annotée produit un positif et un négatif. Pour une image à $n$ boîtes annotées, un groupe CDN compte donc $2n$ requêtes ; comme dans DN-DETR, plusieurs groupes sont utilisés à l'entraînement. La Figure 3 de l'article en montre deux :\n\n[![Schéma du CDN. À gauche, deux CDN groups, chacun avec trois requêtes positives jaunes et trois requêtes négatives brunes, passent ensemble dans le décodeur ; les positifs correspondent à reconstruction loss, les négatifs à no object. À droite, des carrés concentriques ; le carré intérieur porte positive et λ1, l'espace entre le carré intérieur et le carré extérieur porte negative et λ2](/content/papers/assets/2016ccac10bf8f058a0d252c75ab4adf790e4c28f042f38eeddd61a2c18c94e5.png)](/content/papers/assets/2016ccac10bf8f058a0d252c75ab4adf790e4c28f042f38eeddd61a2c18c94e5.png)\n\n*Zhang et al., Figure 3 de l'article original, extraite de la [**page 8 du PDF v4**](https://arxiv.org/pdf/2203.03605v4#page=8). Structure d'un groupe CDN et schéma des positifs et des négatifs.*\n\nRegardons d'abord la gauche. L'image comporte trois boîtes annotées ; chaque groupe contient donc trois positifs jaunes et trois négatifs bruns, et les deux groupes passent ensemble dans le décodeur. La sortie des positifs sert à la perte de reconstruction (reconstruction loss), et les négatifs ont pour cible no object. Les carrés concentriques de droite sont un schéma. Le point central représente la boîte annotée ; un bruit qui tombe dans le carré intérieur (moins de $\\lambda_1$) donne un positif, un bruit qui tombe entre les deux carrés (de $\\lambda_1$ à $\\lambda_2$) un négatif. Les boîtes d'ancrage ont en réalité quatre dimensions $(x, y, w, h)$ ; les auteurs les dessinent comme des points du plan pour simplifier le schéma.\n\nL'article fixe $\\lambda_1 = 1.0$ et $\\lambda_2 = 2.0$. Dans le code officiel, le bruit s'applique aux quatre côtés de la boîte, et chaque côté se déplace au hasard vers l'intérieur ou vers l'extérieur. Un positif se déplace de moins d'une demi-largeur de boîte (d'une demi-hauteur pour les côtés haut et bas), un négatif d'une demi-largeur à une largeur entière. Le script d'entraînement officiel fixe `dn_box_noise_scale` à 1,0, ce qui donne exactement ces distances.\n\nLe nombre de groupes est déterminé dynamiquement. DINO utilise un nombre fixe d'environ 100 paires, soit 200 requêtes de débruitage, et ajuste le nombre de groupes selon l'image du batch qui compte le plus d'annotations ; le code officiel divise 200 par le double du nombre d'objets de cette image et garde la partie entière. Si l'image la plus chargée du batch contient 7 objets, par exemple, on obtient 14 groupes de 14 requêtes, soit 196 au total. Avec les 900 requêtes d'origine, le décodeur traite donc à l'entraînement 1 096 requêtes par image.\n\nCes requêtes sont séparées par un masque d'attention. Les 900 requêtes d'origine ne voient aucune requête de débruitage, faute de quoi les réponses annotées fuiraient par l'auto-attention ; les groupes ne se voient pas non plus entre eux. À l'intérieur d'un même groupe, en revanche, positifs et négatifs se voient.\n\nÀ quelle distance de la boîte annotée se trouvent donc les négatifs ? En suivant la façon dont le code officiel ajoute le bruit, nous tirons cent mille positifs et cent mille négatifs pour une boîte annotée et calculons leur IoU avec celle-ci :\n\n```python\nimport numpy as np\n\nrng = np.random.default_rng(0)\n\ndef iou(boxes, gt):\n    # boxes : (N, 4) ; gt : (4,) ; format (x1, y1, x2, y2) pour les deux\n    x1 = np.maximum(boxes[:, 0], gt[0])\n    y1 = np.maximum(boxes[:, 1], gt[1])\n    x2 = np.minimum(boxes[:, 2], gt[2])\n    y2 = np.minimum(boxes[:, 3], gt[3])\n    inter = np.clip(x2 - x1, 0, None) * np.clip(y2 - y1, 0, None)\n    area = np.clip(boxes[:, 2] - boxes[:, 0], 0, None) * np.clip(boxes[:, 3] - boxes[:, 1], 0, None)\n    gt_area = (gt[2] - gt[0]) * (gt[3] - gt[1])\n    return inter / (area + gt_area - inter)\n\ndef cdn_noise(gt, n, negative):\n    # imite prepare_for_cdn du code officiel : chaque côté se déplace vers l'intérieur ou vers l'extérieur\n    w, h = gt[2] - gt[0], gt[3] - gt[1]\n    half = np.array([w / 2, h / 2, w / 2, h / 2])\n    u = rng.random((n, 4)) + (1.0 if negative else 0.0)  # positifs [0, 1), négatifs [1, 2)\n    sign = rng.choice([-1.0, 1.0], size=(n, 4))\n    return np.clip(gt + sign * u * half, 0.0, 1.0)\n\ngt = np.array([0.40, 0.35, 0.60, 0.65])  # boîte annotée de largeur 0.2 et de hauteur 0.3, coordonnées normalisées\nfor name, negative in ((\"positifs\", False), (\"négatifs\", True)):\n    boxes = cdn_noise(gt, 100_000, negative)\n    v = iou(boxes, gt)\n    p10, p50, p90 = np.percentile(v, [10, 50, 90])\n    crossed = ((boxes[:, 2] <= boxes[:, 0]) | (boxes[:, 3] <= boxes[:, 1])).mean()\n    print(f\"{name} : IoU médiane {p50:.2f}, 10 %–90 % entre {p10:.2f} et {p90:.2f}, \"\n          f\"max {v.max():.2f}, côtés croisés {crossed:.0%}\")\n```\n\n```text\npositifs : IoU médiane 0.38, 10 %–90 % entre 0.21 et 0.56, max 0.94, côtés croisés 0%\nnégatifs : IoU médiane 0.01, 10 %–90 % entre 0.00 et 0.12, max 0.24, côtés croisés 44%\n```\n\nLes positifs sont déjà nettement décalés, avec une IoU médiane de seulement 0,38, et le modèle doit les ramener vers la boîte annotée. Les négatifs sont encore plus loin, avec une médiane proche de 0 et un maximum de 0,24 seulement. Pour plus de quatre négatifs sur dix, en outre, les côtés gauche et droit, ou haut et bas, se sont croisés ; dans le code officiel, une telle boîte devient une boîte d'ancrage de largeur ou de hauteur quasi nulle, et la simulation compte son IoU comme 0.\n\nCe 0,24 est déjà proche d'une borne qu'on peut calculer à la main. Tant que l'objet ne touche pas le bord de l'image, chaque côté d'un négatif doit se déplacer d'au moins une demi-largeur ou une demi-hauteur de boîte. Le cas le plus proche de la boîte annotée est celui où les quatre côtés se déplacent tous d'exactement une demi-boîte vers l'extérieur ; la boîte devient deux fois plus large et deux fois plus haute, enveloppe la boîte annotée en son centre, et l'IoU vaut $\\frac{wh}{2w \\cdot 2h} = \\frac{1}{4}$.\n\nCes négatifs ne ressemblent donc pas du tout à des doublons. Avec les seuils de NMS courants de 0,5 ou 0,7, ils sont encore très loin d'être des « doublons ».\n\nQu'enseignent-ils alors ? Revenons à la façon dont le décodeur utilise les boîtes d'ancrage. Une boîte d'ancrage est un point de départ ; le décodeur prélève des caractéristiques autour d'elle, puis la corrige couche après couche. Avec seulement des positifs, DN-DETR fait prendre au modèle l'habitude de corriger toute boîte d'ancrage voisine vers l'objet en question. Quand plusieurs boîtes d'ancrage se trouvent près du même objet et qu'elles sont toutes corrigées selon cette habitude, la sortie contient plusieurs boîtes presque identiques. Les doublons apparaissent en sortie, alors que les boîtes d'ancrage de départ peuvent être très différentes les unes des autres.\n\nLes négatifs complètent l'autre moitié. Ils restent eux aussi près de l'objet, chaque côté décalé d'au plus une largeur de boîte, et le décodeur y prélève aussi les caractéristiques du même objet, mais la réponse est « pas d'objet ». Le même groupe contient aussi des positifs plus proches, à ramener vers la boîte annotée. C'est en comparant ces deux sortes de boîtes d'ancrage que le modèle doit apprendre à partir de quel décalage du point de départ il faut lâcher prise.\n\nUne issue du dépôt officiel a soulevé l'inquiétude inverse. Supposons qu'une boîte d'ancrage ait une IoU de 0,7 avec un objet et une autre de 0,5, et que le CDN fasse de celle à 0,5 un négatif ; si, dans l'image suivante, il ne reste qu'une boîte d'ancrage à IoU 0,5, le modèle va-t-il l'abandonner aussi ? [IDEA-Research/DINO #176, 2023-03-23](https://github.com/IDEA-Research/DINO/issues/176) D'après la simulation ci-dessus, avec les réglages officiels, une boîte d'ancrage à IoU 0,5 se situe dans la plage des positifs, et les négatifs ne montent pas au-delà de 0,25 environ. Hao Zhang, l'un des auteurs de l'article, a répondu que chaque groupe du CDN contient toujours à la fois des positifs et des négatifs, si bien qu'une boîte d'ancrage finit toujours appariée à l'objet ; selon lui, le cas décrit dans la question ne se produit pas du côté de l'appariement, et tout dépend du réglage des seuils. Quant à savoir si le CDN aggrave ce genre de situation, ils ne l'ont pas encore étudié.\n\nLe CDN aide-t-il vraiment le modèle à choisir de meilleures boîtes d'ancrage ? Les auteurs définissent un indicateur, l'ATD(k) (Average Top-K Distance). Pour chaque boîte annotée de l'ensemble de validation, on prend la requête qui lui est finalement appariée, on mesure l'écart entre sa boîte d'ancrage de départ et la boîte annotée (distance L1 sur les quatre coordonnées), puis on fait la moyenne des $k$ écarts les plus grands. Moins il y a d'appariements à des boîtes d'ancrage éloignées, plus ce nombre est petit.\n\nDans la configuration ResNet-50, caractéristiques multi-échelles, 12 époques, l'ATD(100) calculée sur tous les objets est comparable entre DN et CDN ; sur les seuls petits objets, la distance est plus courte avec le CDN, et l'AP des petits objets gagne aussi 1,3. La seule preuve directe concernant les doublons est un exemple, dans la Figure 8 de l'article :\n\n[![Deux photos de groupe d'enfants identiques côte à côte, avec seulement les boîtes de personnes. Sur l'image de gauche, une flèche blanche désigne un petit garçon sur lequel se superposent trois boîtes rouges presque confondues ; sur celle de droite, une seule boîte au même endroit](/content/papers/assets/4aed72dc0127639f2eb01d2a2d681c46fbb1112ac82ea7dc1b2126a3559de642.png)](/content/papers/assets/4aed72dc0127639f2eb01d2a2d681c46fbb1112ac82ea7dc1b2126a3559de642.png)\n\n*Zhang et al., Figure 8 de l'article original, extraite de la [**page 15 du PDF v4**](https://arxiv.org/pdf/2203.03605v4#page=15). À gauche, le modèle entraîné avec des requêtes DN ; à droite, DINO ; les deux images ne montrent que les boîtes de la classe « personne ».*\n\nRegardez le petit garçon désigné par la flèche blanche sur l'image de gauche ; trois boîtes presque confondues se superposent sur lui, alors qu'à droite, au même endroit, il n'en reste qu'une. L'article ne donne aucune statistique sur la proportion de doublons.\n\nEt si c'était simplement l'effet d'un plus grand nombre de requêtes ? La Table 7 de l'annexe compare différents nombres de requêtes de débruitage :\n\n| Requêtes de débruitage | AP |\n| --- | ---: |\n| Sans débruitage | 45,1 |\n| 10 DN | 46,0 |\n| 50 DN | 46,7 |\n| 100 DN | 47,4 |\n| 200 DN | 47,4 |\n| 1 000 DN | 47,6 |\n| 100 paires CDN (200 requêtes) | 47,9 |\n\n*Tableau : établi d'après la Table 7 de l'article original, ResNet-50, COCO val2017.*\n\nEn passant de 0 à 100 requêtes DN, l'AP monte de 45,1 à 47,4, puis ne bouge presque plus ; même à 1 000 requêtes, il n'atteint que 47,6. À nombre égal de 200 requêtes, remplacer la moitié par des négatifs apporte 0,5 AP de plus.\n\n### Sélection de requêtes mixte\n\nPour le point de départ des 900 requêtes du décodeur, il existe trois approches :\n\n| Approche | Boîte d'ancrage (position) | Contenu |\n| --- | --- | --- |\n| Statique (DETR, DN-DETR, etc.) | Valeur fixe apprise | Tout à 0, ou valeur fixe apprise |\n| Sélection de requêtes pure (Deformable DETR en deux étapes) | Boîtes prédites aux K positions de meilleur score de l'encodeur | Les mêmes caractéristiques de l'encodeur, après transformation linéaire |\n| Sélection de requêtes mixte (DINO) | Boîtes prédites aux K positions de meilleur score de l'encodeur | Valeur fixe apprise |\n\n*Tableau : établi d'après le §3.4 et la Figure 5 de l'article original.*\n\nDINO ne prend à l'encodeur que les positions et garde pour le contenu des vecteurs apprenables. Dans le code officiel, K vaut 900 ; le score de chaque position est son score maximal sur toutes les classes, et les boîtes retenues sont d'abord détachées du gradient avant de servir de boîtes d'ancrage.\n\nPour les auteurs, les caractéristiques choisies dans l'encodeur ne sont pas encore affinées et peuvent mêler deux objets ou n'en contenir qu'une moitié ; les utiliser comme contenu induirait plutôt en erreur, alors que les positions constituent un a priori utile. Guidé par de meilleures positions, le décodeur va chercher les caractéristiques dans l'encodeur, et le contenu se construit couche après couche.\n\n### Look forward twice\n\nDans Deformable DETR, la correction couche par couche est branchée ainsi. La couche $i$ reçoit la boîte $b_{i-1}$ de la couche précédente et prédit un décalage $\\Delta b_i$ ; leur combinaison donne la boîte de cette couche, dont le gradient est coupé avant qu'elle ne passe à la couche suivante. Les paramètres de la couche $i$ ne sont donc mis à jour que par la perte de la couche $i$. Les auteurs appellent cela look forward once.\n\nDINO procède ainsi :\n\n$$\n\\begin{aligned}\n\\Delta b_i &= \\mathrm{Layer}_i(b_{i-1}), & b_i' &= \\mathrm{Update}(b_{i-1}, \\Delta b_i), \\\\\nb_i &= \\mathrm{Detach}(b_i'), & b_i^{(\\mathrm{pred})} &= \\mathrm{Update}(b_{i-1}', \\Delta b_i)\n\\end{aligned}\n$$\n\n$b_i'$ est la boîte qui porte encore le gradient, $b_i$ sa version détachée, et l'entrée de la couche suivante reste $b_i$. Le changement porte sur la boîte prédite utilisée pour la perte, $b_i^{(\\mathrm{pred})}$, qui se raccroche au $b_{i-1}'$ de la couche précédente, encore porteur de gradient. Le même décalage $\\Delta b_i$ sert ainsi deux fois, une fois pour former le $b_i'$ de cette couche, une fois, à travers $b_i'$, dans la boîte prédite de la couche suivante, d'où le nom look forward twice.\n\n$\\mathrm{Update}$ est le même que dans Deformable DETR ; les coordonnées normalisées entre 0 et 1 passent d'abord par une sigmoïde inverse, on y ajoute le décalage, puis une sigmoïde les ramène dans l'intervalle.\n\nPrenons une coordonnée et deux couches de décodeur pour voir si la perte de la couche 2 remonte jusqu'au décalage de la couche 1 :\n\n```python\nimport torch\n\ndef update(box, delta):\n    # note 3 de l'article : addition dans l'espace de la sigmoïde inverse, puis retour dans 0–1\n    return torch.sigmoid(torch.logit(box) + delta)\n\ntarget = torch.tensor(0.60)  # une coordonnée de la boîte annotée\nb0 = torch.tensor(0.40)      # coordonnée de la boîte d'ancrage reçue par la couche 1\n\nfor mode in (\"look forward once\", \"look forward twice\"):\n    d1 = torch.tensor(0.30, requires_grad=True)  # décalage Δb1 prédit par la couche 1\n    d2 = torch.tensor(0.20, requires_grad=True)  # décalage Δb2 prédit par la couche 2\n\n    b1_prime = update(b0, d1)   # b1' : garde le gradient\n    b1 = b1_prime.detach()      # b1 : gradient coupé, transmis à la couche 2 comme boîte d'ancrage\n\n    if mode == \"look forward once\":\n        pred2 = update(b1, d2)\n    else:\n        pred2 = update(b1_prime, d2)\n\n    loss2 = (pred2 - target).abs()  # seule la perte L1 de la couche 2\n    loss2.backward()\n    g1 = 0.0 if d1.grad is None else d1.grad.item()\n    print(f\"{mode} : prédiction de la couche 2 {pred2.item():.4f}, \"\n          f\"gradient sur Δb1 {g1:+.4f}, gradient sur Δb2 {d2.grad.item():+.4f}\")\n```\n\n```text\nlook forward once : prédiction de la couche 2 0.5236, gradient sur Δb1 +0.0000, gradient sur Δb2 -0.2494\nlook forward twice : prédiction de la couche 2 0.5236, gradient sur Δb1 -0.2494, gradient sur Δb2 -0.2494\n```\n\nLes deux branchements donnent exactement la même boîte prédite, 0,5236 ; ils ne diffèrent que par le gradient. Avec look forward once, la perte de la couche 2 n'atteint pas $\\Delta b_1$ ; avec look forward twice, elle remonte aussi jusqu'à $\\Delta b_1$. Ici, le décalage de chaque couche est simplifié en un nombre apprenable ; dans le vrai modèle, $\\Delta b_i$ est la sortie de la couche $i$, et le gradient continue jusque dans les paramètres de cette couche. Le gradient ne remonte que d'une couche, puisque $b_{i-1}$ a déjà été détaché avant d'entrer dans la couche $i$.\n\nLe calcul à l'inférence ne change pas du tout ; cette modification n'affecte que l'entraînement.\n\n## Discussion\n\n### 12 époques\n\nVoyons d'abord la comparaison en ResNet-50, sur COCO val2017, avec 12 époques d'entraînement :\n\n| Modèle | AP | AP_S | GFLOPs | Paramètres | FPS |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| Faster-RCNN (5-scale) | 37,9 | 22,4 | 207 | 40M | 21 |\n| Deformable DETR (4-scale) | 41,1 | — | 196 | 40M | 24 |\n| DN-Deformable-DETR (4-scale) | 43,4 | 24,8 | 265 | 48M | 23 |\n| DINO-4scale | 49,0 | 32,0 | 279 | 47M | 24 |\n| DINO-5scale | 49,4 | 32,3 | 860 | 47M | 10 |\n\n*Tableau : établi d'après la Table 1 de l'article original. Les FPS sont tous mesurés sur la même A100, ceux de Faster-RCNN avec mmdetection.*\n\nFace à DN-Deformable-DETR, DINO-4scale gagne 5,6 AP pour un calcul et un nombre de paramètres comparables, et l'AP_S des petits objets progresse de 7,2. Les nombres de requêtes sont eux aussi comparables, 900 pour DINO, et 300 requêtes avec 3 patterns pour DN-Deformable-DETR, ce qui équivaut selon les auteurs à 900 ; Deformable DETR en utilise 300.\n\nLa différence entre 4-scale et 5-scale tient à l'utilisation ou non des caractéristiques de l'étage 1 du backbone. Ce niveau a la plus haute résolution ; les GFLOPs passent de 279 à 860, environ le triple, et les FPS tombent de 24 à 10, pour 0,4 AP de plus. Le 49,4 du résumé est le chiffre du 5-scale.\n\n### Entraîner plus longtemps\n\nÀ 24 et 36 époques, le 4-scale obtient 50,4 et 50,9, le 5-scale 51,3 et 51,2 (Table 2). Le groupe de comparaison, DN-Deformable-DETR, entraîné 50 époques, obtient 48,6. Quand le résumé annonce 2,7 AP de plus que DN-DETR à 24 époques, il compare les 24 époques de DINO aux 50 époques de DN-DETR. Entre 24 et 36 époques, le score du 5-scale ne progresse plus.\n\nLe coût d'entraînement figure dans l'annexe B. Sur les mêmes 8 A100, DINO prend environ 55 minutes par époque et 16 Go par carte, soit environ 11 heures pour 12 époques. Deformable DETR (version de base, sans deux étapes ni correction couche par couche) prend le même temps par époque ; entraîné 50 époques, il demande environ 46 heures pour 45,4 AP. DETR ne prend que 16 minutes par époque, mais il lui faut 300 époques, soit environ 80 heures, pour 41,2 AP. Dans ce tableau, DINO obtient 47,9, ce qui correspond à la même période d'implémentation que le tableau d'ablation plus bas.\n\n### La case du classement\n\nLe DINO qui s'est hissé en tête du classement a été obtenu dans des conditions très différentes :\n\n- Le backbone passe à SwinL, préentraîné sur ImageNet-22K.\n- Le détecteur est d'abord préentraîné 26 époques sur Objects365 (environ 1,7 million d'images annotées), avec 64 A100.\n- Il est ensuite affiné 18 époques sur COCO, avec 16 A100 et des images agrandies 1,5 fois (côté le plus long à 2 000) ; selon les auteurs, cette étape rapporte environ 0,5 AP.\n- Les requêtes de débruitage passent à 1 000.\n\nVoici le résultat, aux côtés de quelques grands modèles :\n\n| Modèle | Paramètres | Données de préentraînement du backbone | Données de préentraînement de détection | De bout en bout | AP test-dev (sans / avec TTA) |\n| --- | ---: | --- | --- | :---: | ---: |\n| Florence-CoSwin-H | ≥ 637M | FLD-900M | FLD-9M | | — / 62,4 |\n| SwinV2-G | 3,0B | IN-22K-ext-70M | O365 | | — / 63,1 |\n| DINO-SwinL | 218M | IN-22K-14M | O365 | ✓ | 63,2 / 63,3 |\n\n*Tableau : établi d'après la Table 3 de l'article original. IN désigne ImageNet, O365 Objects365 ; SwinV2-G a en outre été entraîné avec des annotations de segmentation d'instances.*\n\nSans augmentation au moment du test (TTA), les 63,2 de DINO dépassent déjà les 63,1 de SwinV2-G avec TTA, pour 218M de paramètres contre 3,0B. Sur val2017, DINO obtient 63,1, et 63,2 avec TTA. Les auteurs soulignent que les précédents modèles SOTA de la Table 3 utilisent tous HTC++ ou DyHead comme tête de détection, et que DINO est le premier détecteur Transformer de bout en bout à occuper cette place. L'annonce du dépôt officiel du 8 mars 2022 indique elle aussi la première place du classement MS-COCO, avec 63,3 AP.\n\nCe 63,3 utilise la TTA, c'est-à-dire le test multi-échelle avec retournement horizontal. Quand un détecteur classique combine les résultats de plusieurs inférences, il rassemble toutes les boîtes, puis supprime les doublons par NMS ou box voting. Selon les auteurs, cette méthode fait au contraire perdre des points à DINO, car les modèles de type DETR produisent naturellement peu de doublons, et la NMS supprime facilement des boîtes correctes. Ils utilisent plutôt une combinaison un à un, qui prend pour base les prédictions de l'une des augmentations ; pour chaque boîte, on cherche dans les résultats des autres augmentations celle dont l'IoU est la plus élevée et dépasse un seuil, puis on fait une moyenne pondérée.\n\nDans le même article, l'annexe affirme que les modèles de type DETR produisent peu de doublons, tandis que le §3.3 reconnaît que la perte d'appariement et l'auto-attention n'étouffent les doublons que dans une certaine mesure. Lues ensemble, ces deux phrases reviennent plutôt à « la plupart du temps, pas de doublon, mais il en passe parfois entre les mailles du filet », et le petit garçon encadré trois fois est justement de ceux qui passent entre les mailles.\n\n### Ablation : comment s'empilent les 49,4\n\nVoyons enfin ce que chacune des trois nouvelles conceptions apporte :\n\n| Configuration | Sélection de requêtes | CDN | LFT | AP | AP_S |\n| --- | :---: | :---: | :---: | ---: | ---: |\n| 1. DN-DETR | Aucune | | | 43,4 | 24,8 |\n| 2. DN-DETR à l'implémentation remaniée | Aucune | | | 44,9 | 26,9 |\n| 3. Référence forte (2 avec sélection de requêtes pure) | Pure | | | 46,5 | 29,6 |\n| 4. 3 avec sélection de requêtes mixte | Mixte | | | 47,0 | 31,1 |\n| 5. 4 avec look forward twice | Mixte | | ✓ | 47,4 | 29,9 |\n| 6. DINO (5 avec CDN) | Mixte | ✓ | ✓ | 47,9 | 31,2 |\n\n*Tableau : établi d'après la Table 4 de l'article original, ResNet-50, COCO val2017.*\n\nLes chiffres de ce tableau sont ceux de la première version de l'article ; ils n'intègrent pas les ajustements d'ingénierie qui ont ensuite porté la Table 1 à 49,0, d'où le 47,9 de la dernière ligne.\n\nDe 43,4 pour DN-DETR à 47,9 pour DINO, le gain total est de 4,5 AP. Les deux plus grandes marches sont le remaniement de l'implémentation de DN-DETR par les auteurs (+1,5) et l'emprunt de la sélection de requêtes pure de Deformable DETR (+1,6). Les trois nouvelles conceptions ajoutent successivement 0,5, 0,4 et 0,5, soit 1,4 au total.\n\nLa colonne des petits objets fluctue un peu. Après l'ajout de look forward twice, l'AP_S tombe de 31,1 à 29,9, et ne remonte à 31,2 qu'avec le CDN ; l'article n'explique pas cette baisse.\n\nLe « 49,4 AP en 12 époques » du résumé est donc un score obtenu en empilant beaucoup de choses. Les négatifs eux-mêmes valent, dans ce tableau, 0,5 AP.\n\nLa sélection de requêtes mixte a aussi un effet secondaire, décrit dans l'annexe C. En gardant 6 couches d'encodeur et en réduisant le décodeur de 6 à 2 couches, DINO perd 3,0 AP (de 47,4 à 44,4) ; Dynamic DETR, cité par les auteurs, perd 13,8 AP quand on le réduit à 2 couches. Les auteurs attribuent cet écart à la sélection de requêtes mixte ; comme l'encodeur fournit d'emblée de bonnes boîtes d'ancrage, le modèle dépend moins des corrections successives du décodeur. Cette expérience utilise 12 époques et 100 requêtes de débruitage, sans négatifs.\n\n## Conclusion\n\nDINO ajoute trois choses à DN-DETR :\n\n1. **Débruitage contrastif** : à côté d'une même boîte annotée, on place une boîte d'ancrage peu décalée et une autre très décalée ; la première doit être ramenée à la boîte annotée, la seconde doit répondre « pas d'objet ». Avec les réglages officiels, l'IoU d'un négatif avec la boîte annotée ne dépasse pas environ 0,25 ; ces négatifs enseignent au modèle à partir de quel décalage du point de départ il faut lâcher prise.\n2. **Sélection de requêtes mixte** : les boîtes d'ancrage sont choisies dans l'encodeur, le contenu reste un vecteur apprenable.\n3. **Look forward twice** : la perte de la couche suivante remonte d'une couche de plus.\n\nEn ResNet-50 et 12 époques, les versions 4-scale et 5-scale atteignent respectivement 49,0 et 49,4 AP ; avec SwinL et un préentraînement sur Objects365, DINO obtient 63,2 sur test-dev, 63,3 avec TTA, et prend la première place du classement COCO de l'époque. Dans le tableau d'ablation, chacune des trois nouvelles conceptions vaut environ un demi-point d'AP, et l'essentiel du progrès vient du remaniement de l'implémentation et de la sélection de requêtes. La preuve directe que les négatifs étouffent les doublons se limite à une image d'exemple ; les courbes d'ATD montrent, elles, que les petits objets sont appariés à des boîtes d'ancrage plus proches.\n\nDETR se passe de NMS parce qu'on apprend au modèle, pendant l'entraînement, à reconnaître les boîtes qu'il doit lâcher ; les auteurs eux-mêmes reconnaissent que cette capacité est limitée. Au déploiement, on peut faire comme le code officiel et garder l'interrupteur NMS, pour l'activer au besoin.\n\nLa vitesse de DINO est une autre affaire. Un an plus tard, RT-DETR mesure DINO-Deformable-DETR-R50 sur GPU T4, en TensorRT FP16, avec des entrées de 800×1333, et n'obtient que 5 FPS. L'entraînement du décodeur de RT-DETR reprend presque tel quel les réglages de DINO, requêtes de débruitage comprises ; c'est l'encodeur qu'il retaille, parce que les caractéristiques multi-échelles font de l'encodeur le goulot d'étranglement du calcul. La suite de l'histoire se lit dans la note [RT-DETR](/blog/papers/object-detection/rt-detr).\n","imageSizes":{"/content/papers/assets/6c328e7125d4762c3a4346a1c537cb4e917d47a640869bbf212de53f74ba64fc.png":{"width":942,"height":319},"/content/papers/assets/2016ccac10bf8f058a0d252c75ab4adf790e4c28f042f38eeddd61a2c18c94e5.png":{"width":766,"height":353},"/content/papers/assets/4aed72dc0127639f2eb01d2a2d681c46fbb1112ac82ea7dc1b2126a3559de642.png":{"width":938,"height":313}}}