{"notes":[{"id":"object-detection/deim","category":"object-detection","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"DEIM","subtitle":"Des positifs en mosaïque","author":"Z. Yuan","paperDate":"2024-12-05","publishedOn":"2026-06-26","world":"external/deim","paperTitle":"DEIM: DETR with Improved Matching for Fast Convergence","paperUrl":"https://arxiv.org/abs/2412.04234","bibliography":{"title":"DEIM: DETR with Improved Matching for Fast Convergence","authors":["Shihua Huang","Zhichao Lu","Xiaodong Cun","Yongjun Yu","Xiao Zhou","Xi Shen"],"url":"https://arxiv.org/abs/2412.04234","pdfUrl":"https://arxiv.org/pdf/2412.04234v3","codeUrl":"https://github.com/Intellindust-AI-Lab/DEIM","preprint":{"id":"2412.04234","submittedOn":"2024-12-05","url":"https://arxiv.org/abs/2412.04234"},"publication":{"venue":"CVPR","year":2025,"kind":"conference","url":"https://openaccess.thecvf.com/content/CVPR2025/html/Huang_DEIM_DETR_with_Improved_Matching_for_Fast_Convergence_CVPR_2025_paper.html"},"citation":"@misc{objectdetectiondeim2024,\n  title = {{DEIM: DETR with Improved Matching for Fast Convergence}},\n  author = {Shihua Huang and Zhichao Lu and Xiaodong Cun and Yongjun Yu and Xiao Zhou and Xi Shen},\n  year = {2024},\n  eprint = {2412.04234},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2412.04234}\n}\n","citationPath":"/content/papers/citations/object-detection/deim.6126444ef2d4.bib"},"thumbnail":{"src":"/content/papers/assets/728ebf51d648559c31fbbb0d0dafd4107b254df8b6016972cd881c555eb051ae.png","width":1280,"height":1720},"locale":"fr","path":"/content/papers/fr/object-detection/deim.c96d2b371f42.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"autant-de-positifs-que-dobjets","text":"Autant de positifs que d'objets","depth":3},{"id":"apparié-mais-de-travers","text":"Apparié, mais de travers","depth":3},{"id":"les-remèdes-précédents","text":"Les remèdes précédents","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"dense-o2o-plus-dobjets-par-image","text":"Dense O2O : plus d'objets par image","depth":3},{"id":"mal-plus-de-positifs-plus-dappariements-de-travers","text":"MAL : plus de positifs, plus d'appariements de travers","depth":3},{"id":"le-calendrier-dentraînement-séchauffer-assembler-puis-lever-le-pied","text":"Le calendrier d'entraînement : s'échauffer, assembler, puis lever le pied","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"configuration-expérimentale","text":"Configuration expérimentale","depth":3},{"id":"face-à-d-fine-et-yolo","text":"Face à D-FINE et YOLO","depth":3},{"id":"ablations-la-part-de-dense-o2o-et-celle-de-mal","text":"Ablations : la part de Dense O2O et celle de MAL","depth":3},{"id":"quand-les-objets-sentassent","text":"Quand les objets s'entassent","depth":3},{"id":"retours-de-reproduction","text":"Retours de reproduction","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/h-detr","relation":"referenced","topic":""},{"id":"object-detection/dino-detr","relation":"referenced","topic":""},{"id":"object-detection/rt-detr","relation":"referenced","topic":""}]},{"id":"object-detection/h-detr","category":"object-detection","legacyPath":"object-detection/2207-h-detr","legacySlug":"2207-h-detr","legacyPaths":[],"title":"H-DETR","subtitle":"La révolte des requêtes silencieuses","author":"Z. Yuan","paperDate":"2022-07-26","publishedOn":"2025-07-06","paperTitle":"DETRs with Hybrid Matching","paperUrl":"https://arxiv.org/abs/2207.13080","bibliography":{"title":"DETRs with Hybrid Matching","authors":["Ding Jia","Yuhui Yuan","Haodi He","Xiaopei Wu","Haojun Yu","Weihong Lin","Lei Sun","Chao Zhang","Han Hu"],"url":"https://arxiv.org/abs/2207.13080","pdfUrl":"https://openaccess.thecvf.com/content/CVPR2023/papers/Jia_DETRs_With_Hybrid_Matching_CVPR_2023_paper.pdf","codeUrl":"https://github.com/HDETR/H-Deformable-DETR","preprint":{"id":"2207.13080","submittedOn":"2022-07-26","url":"https://arxiv.org/abs/2207.13080"},"publication":{"venue":"CVPR","year":2023,"kind":"conference","url":"https://openaccess.thecvf.com/content/CVPR2023/html/Jia_DETRs_With_Hybrid_Matching_CVPR_2023_paper.html"},"citation":"@misc{objectdetectionhdetr2022,\n  title = {{DETRs with Hybrid Matching}},\n  author = {Ding Jia and Yuhui Yuan and Haodi He and Xiaopei Wu and Haojun Yu and Weihong Lin and Lei Sun and Chao Zhang and Han Hu},\n  year = {2022},\n  eprint = {2207.13080},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2207.13080}\n}\n","citationPath":"/content/papers/citations/object-detection/h-detr.822184101757.bib"},"thumbnail":{"src":"/content/papers/assets/63f1bc60b92f58d360457c0e3bbef0a3d4b3bd2a07377983b2dc5f5591ce28c2.jpg","width":1784,"height":350},"locale":"fr","path":"/content/papers/fr/object-detection/h-detr.b1c95b0378ee.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":"branche-principale--supervision-un-à-un","text":"Branche principale : supervision un à un","depth":3},{"id":"branche-auxiliaire--supervision-un-à-plusieurs","text":"Branche auxiliaire : supervision un à plusieurs","depth":3},{"id":"perte-totale-et-détails-de-mise-en-œuvre","text":"Perte totale et détails de mise en œuvre","depth":3},{"id":"autres-formes-de-supervision-hybride","text":"Autres formes de supervision hybride","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"benchmark-coco","text":"Benchmark COCO","depth":3},{"id":"benchmark-lvis","text":"Benchmark LVIS","depth":3},{"id":"comparaison-avec-les-systèmes-de-référence","text":"Comparaison avec les systèmes de référence","depth":3},{"id":"ablations","text":"Ablations","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/deformable-detr","relation":"background","topic":"Prédiction d’ensembles et détection par attention"}]},{"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":"object-detection/rt-detr","category":"object-detection","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"RT-DETR","subtitle":"Le chrono, NMS comprise","author":"Z. Yuan","paperDate":"2023-04-17","publishedOn":"2025-01-29","world":"external/rt-detr","paperTitle":"DETRs Beat YOLOs on Real-time Object Detection","paperUrl":"https://arxiv.org/abs/2304.08069","bibliography":{"title":"DETRs Beat YOLOs on Real-time Object Detection","authors":["Yian Zhao","Wenyu Lv","Shangliang Xu","Jinman Wei","Guanzhong Wang","Qingqing Dang","Yi Liu","Jie Chen"],"url":"https://arxiv.org/abs/2304.08069","pdfUrl":"https://arxiv.org/pdf/2304.08069v3","codeUrl":"https://github.com/lyuwenyu/RT-DETR","preprint":{"id":"2304.08069","submittedOn":"2023-04-17","url":"https://arxiv.org/abs/2304.08069"},"publication":{"venue":"CVPR","year":2024,"kind":"conference","url":"https://openaccess.thecvf.com/content/CVPR2024/html/Zhao_DETRs_Beat_YOLOs_on_Real-time_Object_Detection_CVPR_2024_paper.html"},"citation":"@misc{objectdetectionrtdetr2023,\n  title = {{DETRs Beat YOLOs on Real-time Object Detection}},\n  author = {Yian Zhao and Wenyu Lv and Shangliang Xu and Jinman Wei and Guanzhong Wang and Qingqing Dang and Yi Liu and Jie Chen},\n  year = {2023},\n  eprint = {2304.08069},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2304.08069}\n}\n","citationPath":"/content/papers/citations/object-detection/rt-detr.cbe42f7a5b6c.bib"},"thumbnail":{"src":"/content/papers/assets/7e2de3c38daff439f51d86ec04a7bd391c3f708b817ae539f3c4df7c5546f4d6.png","width":1360,"height":332},"locale":"fr","path":"/content/papers/fr/object-detection/rt-detr.9f9ee96eed30.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"combien-de-temps-prend-la-nms","text":"Combien de temps prend la NMS ?","depth":3},{"id":"un-chronomètre-de-bout-en-bout","text":"Un chronomètre de bout en bout","depth":3},{"id":"où-detr-perd-il-son-temps","text":"Où DETR perd-il son temps ?","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"vue-densemble","text":"Vue d'ensemble","depth":3},{"id":"les-comptes-de-lencodeur","text":"Les comptes de l'encodeur","depth":3},{"id":"aifi-lauto-attention-sur-s5-seulement","text":"AIFI : l'auto-attention sur S5 seulement","depth":3},{"id":"ccff-la-fusion-inter-échelles-confiée-aux-convolutions","text":"CCFF : la fusion inter-échelles confiée aux convolutions","depth":3},{"id":"choisir-300-requêtes","text":"Choisir 300 requêtes","depth":3},{"id":"décodeur-retirer-les-dernières-couches","text":"Décodeur : retirer les dernières couches","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"face-à-yolo-et-dino","text":"Face à YOLO et DINO","depth":3},{"id":"comment-régler-les-seuils","text":"Comment régler les seuils ?","depth":3},{"id":"changer-de-machine","text":"Changer de machine","depth":3},{"id":"il-reste-parfois-des-doublons","text":"Il reste parfois des doublons","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/detr","relation":"referenced","topic":""},{"id":"object-detection/deformable-detr","relation":"referenced","topic":""},{"id":"feature-fusion/panet","relation":"referenced","topic":""}]}],"text":"Une photo compte 3 objets annotés, et RT-DETR prépare 300 requêtes. Après l'appariement un à un, seules 3 requêtes apprennent où placer une boîte ; pour les 297 autres, la cible d'entraînement est toujours « pas d'objet ».\n\nYOLO n'a pas ce souci. Avec une attribution d'étiquettes un à plusieurs, chaque objet revendique à la fois plusieurs prédictions voisines, et la supervision est bien plus dense ; en contrepartie, un même objet fait surgir plusieurs boîtes à l'inférence, et il faut la NMS pour faire le ménage.\n\nCôté DETR, pour récupérer des positifs, la plupart des approches de ces dernières années ajoutent quelque chose à côté du modèle. [H-DETR](/blog/papers/object-detection/h-detr) ouvre un groupe supplémentaire de requêtes un à plusieurs, Group DETR ajoute plusieurs groupes de requêtes appariés chacun de son côté, et [DINO](/blog/papers/object-detection/dino-detr) ajoute une série d'exercices de débruitage. Ces supervisions supplémentaires disparaissent toutes à l'inférence, mais coûtent un calcul de plus à l'entraînement.\n\nEn décembre 2024, des auteurs d'Intellindust AI Lab, de la City University of Hong Kong et d'autres institutions ont proposé DEIM, qui agit plutôt sur les données. Ni la règle d'appariement ni le modèle ne changent ; il suffit qu'une image d'entraînement contienne plus d'objets pour que l'appariement un à un produise naturellement plus de positifs. DEIM emprunte pour cela deux augmentations de données que la famille YOLO utilise depuis longtemps, Mosaic et Mixup. L'article a ensuite été publié à CVPR 2025.\n\n## Définir le problème\n\n### Autant de positifs que d'objets\n\nÉcrivons d'abord les deux types d'attribution avec une même formule. Une image contient $N$ objets annotés ; le $i$-ième objet est apparié à $M_i$ prédictions, et l'entraînement additionne la perte $f$ de chaque paire :\n\n$$\n\\text{loss} = \\sum_{i=1}^{N} \\sum_{j=1}^{M_i} f(\\hat{y}_{ij}, y_i)\n$$\n\nUn détecteur un à plusieurs a $M_i > 1$. DETR fait un appariement un à un avec l'algorithme hongrois, ce qui revient à imposer $M_i = 1$ pour chaque objet ; le nombre de positifs d'une image vaut alors $N$, autant que d'objets annotés sur la photo. Avoir 300 requêtes n'y change rien.\n\nEn entraînant RT-DETRv2 (ResNet-50), les auteurs ont compté, sur une époque de COCO, combien de positifs chaque image obtient, d'un côté avec l'algorithme hongrois, de l'autre avec le SimOTA de YOLOX (Figure 3 de l'article). RT-DETRv2 est la version améliorée de [RT-DETR](/blog/papers/object-detection/rt-detr) publiée par Baidu en juillet 2024 ; SimOTA est une attribution un à plusieurs qui estime d'abord, à partir des IoU des boîtes prédites autour de chaque objet, combien de prédictions lui attribuer, nombre noté $k$, puis retient comme positifs les $k$ prédictions au coût d'appariement le plus bas.\n\nLa distribution un à un forme un pic serré en dessous de 10 positifs par image. Celle de SimOTA est très étalée, certaines photos dépassant à elles seules 80 positifs. En divisant l'une par l'autre, on obtient le plus souvent un rapport d'environ 7, et d'environ 10 dans les cas extrêmes.\n\nLa Figure 3 ne compte que les positifs produits par l'appariement lui-même. RT-DETRv2 s'entraîne aussi avec une série de requêtes de débruitage à la [DN-DETR](/blog/papers/object-detection/dn-detr), que DEIM conserve ; c'est une autre supervision supplémentaire.\n\n### Apparié, mais de travers\n\nSelon les auteurs, la lenteur de convergence de DETR a une deuxième cause, l'appariement de faible qualité (low-quality match).\n\nLes détecteurs comme YOLO placent des milliers de positions de prédiction serrées sur la carte de caractéristiques (selon l'article, les ancres denses dépassent généralement 8 000), si bien que quelques positions sont toujours assez proches de chaque objet. DETR n'a que 100 ou 300 requêtes, qui au départ ne sont pas alignées sur la position des objets. DINO et RT-DETR ont ensuite initialisé les requêtes avec les positions de plus haut score dans la sortie de l'encodeur ; les requêtes se rapprochent bien des objets, mais ont tendance à s'agglutiner autour de quelques objets bien visibles.\n\nIl n'y a pas de requête près des objets discrets, et l'appariement un à un impose pourtant que chaque objet en reçoive une. La requête qui finit par lui être attribuée peut avoir une boîte de très faible IoU avec l'objet, tout en ayant un score de confiance élevé.\n\n### Les remèdes précédents\n\nAvant DEIM, les méthodes pour ajouter des positifs augmentaient toutes le nombre de positifs par objet. Group DETR ouvre K groupes de requêtes à l'entraînement, chacun faisant son propre appariement un à un, ce qui donne K positifs par objet ; l'appariement hybride de H-DETR procède de façon similaire. Co-DETR branche quant à lui derrière l'encodeur des têtes auxiliaires un à plusieurs, du type Faster R-CNN ou FCOS.\n\nLes auteurs leur font deux reproches. D'abord, il faut faire tourner plusieurs décodeurs ou têtes auxiliaires, ce qui alourdit l'entraînement ; ensuite, avec davantage de supervision un à plusieurs, le modèle risque de réapprendre à produire plusieurs boîtes à score élevé pour un même objet, et de retomber dans le vieux problème des détecteurs classiques.\n\n\n> [!TIP]\n> \n> Sur l'appariement hybride de H-DETR et le masque qui sépare les deux groupes de requêtes, vous pouvez consulter notre note :\n> \n> - **[[22.07] H-DETR : la révolte des requêtes silencieuses](/blog/papers/object-detection/h-detr)**\n\n\nPeut-on alors augmenter le nombre de positifs sans ajouter de requêtes ni de têtes auxiliaires, et sans toucher à l'appariement un à un ? Et une fois les positifs plus nombreux, que faire des appariements de travers ?\n\n## Résoudre le problème\n\nLes deux composants de DEIM répondent chacun à l'une de ces questions. Dense O2O augmente le nombre de positifs, et la Matchability-Aware Loss (MAL) traite les appariements de faible qualité qui se multiplient ensuite. Les deux ne modifient que l'entraînement ; à l'inférence, le modèle, le nombre de requêtes et la chaîne de sortie restent les mêmes.\n\n### Dense O2O : plus d'objets par image\n\nRevenons à la formule précédente. L'attribution un à plusieurs augmente $M_i$ ; Dense O2O garde $M_i$ à 1 et augmente plutôt $N$.\n\nLe §3.2 de l'article l'illustre par un exemple. On réduit une photo qui ne contient qu'un chien, on la duplique en une grille 2×2 de quatre cases ramenée à la taille d'origine ; le chien devient quatre chiens, et l'appariement un à un produit 4 positifs, autant que les 4 positifs que l'attribution un à plusieurs donnait au chien d'origine.\n\nÀ l'entraînement, on ne duplique pas réellement la même photo quatre fois. Les auteurs utilisent plutôt deux augmentations de données courantes dans la famille YOLO, réglées comme suit dans le code officiel :\n\n- **Mosaic** : déclenché avec une probabilité de 0,5 pour chaque image d'entraînement. On prend l'image courante et 3 autres tirées au hasard dans le jeu de données, chacune réduite à 320 pixels sur son petit côté, puis collées dans une grille 2×2 ; l'ensemble subit une transformation affine aléatoire (rotation de ±10°, translation de 10 %, mise à l'échelle de 0,5 à 1,5), puis est redimensionné en 640×640.\n- **Mixup** : déclenché avec une probabilité de 0,5 pour chaque lot. Chaque image du lot est superposée à la précédente dans une proportion de 0,45 à 0,55, et toutes les boîtes annotées des deux images sont conservées.\n\nLe nombre moyen d'objets par image d'entraînement passe ainsi d'environ 10 à environ 25 (Table 12 de l'annexe). Les auteurs ont aussi essayé de pousser cette moyenne vers 50 environ ; l'AP après 24 époques est alors descendue de 52,5 à 52,2, ce qu'ils attribuent au déséquilibre entre positifs et négatifs et au décalage de distribution causé par l'excès d'objets.\n\nUn lecteur a demandé sur GitHub si le facteur 4 de la figure de l'article était codé dans l'appariement. Le premier auteur a répondu que ce n'était qu'un exemple, et que le rapport réel n'est pas fixé à 4. Le nombre de négatifs est le nombre de requêtes moins le nombre de positifs ; avec 300 requêtes et 5 objets, il y a 295 négatifs, et quand Dense O2O porte le nombre d'objets à 20, il en reste 280. [DEIM #126](https://github.com/Intellindust-AI-Lab/DEIM/issues/126)\n\n\n> [!TIP]\n> \n> Le Mosaic cité par l'article vient de YOLOv4 ; pour voir à quoi ressemblent quatre images assemblées en une, vous pouvez consulter notre note :\n> \n> - **[[20.04] YOLOv4 : conseils pour concevoir un modèle](/blog/papers/object-detection/yolov4)**\n\n\nEt le coût ? Ni l'appariement ni le modèle ne changent, donc le calcul sur GPU ne change pas non plus. Sur une seule RTX 4090, une époque de RT-DETRv2-R50 prend 1,181 heure GPU, et 1,183 avec DEIM (Table 7). Le travail supplémentaire tombe sur le chargement des données, puisque l'assemblage et la superposition se font sur CPU ; le dépôt officiel a ensuite ajouté un cache pour Mosaic, et selon le README, le chargement des données en est devenu près de 30 % plus rapide.\n\n### MAL : plus de positifs, plus d'appariements de travers\n\nLes auteurs notent qu'avec plus d'objets, l'écart entre objets bien visibles et objets discrets se creuse ; le nombre total d'appariements augmente, mais les appariements de faible qualité aussi. Mosaic divise en outre par deux environ le côté de chaque photo, ce qui multiplie aussi les petits objets.\n\nCes appariements relèvent de la perte de classification. RT-DETR et D-FINE utilisaient la VariFocal Loss (VFL). Soit $p$ le score de confiance prédit et $q$ l'IoU entre la boîte prédite et l'objet apparié :\n\n$$\n\\text{VFL}(p, q) =\n\\begin{cases}\n-q\\,\\big(q \\log p + (1-q) \\log(1-p)\\big) & q > 0 \\\\\n-\\alpha\\, p^{\\gamma} \\log(1-p) & q = 0\n\\end{cases}\n$$\n\nLa ligne du haut concerne les positifs. Elle fixe le score cible de classification à l'IoU, pour que le score de confiance apprenne à refléter la précision de la boîte ; le terme entier est ensuite multiplié par $q$, si bien que plus la boîte d'un positif est précise, plus son poids est grand. La ligne du bas concerne les négatifs ; comme la Focal Loss, elle utilise $p^\\gamma$ pour réduire le poids de la masse des négatifs faciles, et $\\alpha$ équilibre positifs et négatifs. RT-DETRv2 utilise $\\gamma = 2$ et $\\alpha = 0.75$.\n\nLe problème vient de ce facteur $q$. Pour un appariement dont l'IoU n'est que de 0,05, la perte entière est d'abord multipliée par 0,05 ; même avec un score de confiance très élevé, la perte reste faible. Dans DETR, où les requêtes sont peu nombreuses et l'appariement imposé, les auteurs estiment que ces appariements sont plus fréquents que dans les détecteurs classiques, alors que la VFL les ignore presque entièrement. Par ailleurs, la VFL sépare positifs et négatifs selon que l'IoU est supérieure à 0 ou non ; une requête appariée dont la boîte ne touche pas du tout l'objet est donc traitée comme un négatif.\n\nMAL modifie la formule ainsi :\n\n$$\n\\text{MAL}(p, q, y) =\n\\begin{cases}\n-q^{\\gamma} \\log p - (1-q^{\\gamma}) \\log(1-p) & y = 1 \\\\\n-p^{\\gamma} \\log(1-p) & y = 0\n\\end{cases}\n$$\n\n- Positifs et négatifs sont désormais séparés par $y$, c'est-à-dire selon que la requête a été appariée à un objet ou non.\n- Le score cible des positifs passe de $q$ à $q^\\gamma$, et le facteur $q$ placé devant disparaît.\n- Les négatifs perdent $\\alpha$.\n- Les deux lignes utilisent le même $\\gamma$, fixé à 1,5 dans l'article.\n\nFaisons le calcul pour deux appariements, l'un de faible qualité à IoU 0,05, l'autre bon à IoU 0,95, en balayant le score de confiance de 0,1 à 0,9 et en ne regardant que la ligne des positifs :\n\n```python\nimport math\n\ndef vfl_pos(p, q):\n    # Positifs de l'Eq. 3 : score cible q, puis le terme entier multiplié par q\n    return -q * (q * math.log(p) + (1 - q) * math.log(1 - p))\n\ndef mal_pos(p, q, gamma=1.5):\n    # Positifs de l'Eq. 4 : score cible q^γ, poids fixé à 1\n    t = q ** gamma\n    return -(t * math.log(p) + (1 - t) * math.log(1 - p))\n\nfor q in (0.05, 0.95):\n    print(f\"IoU = {q}, score cible de MAL q^1.5 = {q ** 1.5:.3f}\")\n    for p in (0.1, 0.3, 0.5, 0.7, 0.9):\n        print(f\"  confiance {p} : VFL {vfl_pos(p, q):.3f}  MAL {mal_pos(p, q):.3f}\")\n```\n\n```text\nIoU = 0.05, score cible de MAL q^1.5 = 0.011\n  confiance 0.1 : VFL 0.011  MAL 0.130\n  confiance 0.3 : VFL 0.020  MAL 0.366\n  confiance 0.5 : VFL 0.035  MAL 0.693\n  confiance 0.7 : VFL 0.058  MAL 1.194\n  confiance 0.9 : VFL 0.110  MAL 2.278\nIoU = 0.95, score cible de MAL q^1.5 = 0.926\n  confiance 0.1 : VFL 2.083  MAL 2.140\n  confiance 0.3 : VFL 1.104  MAL 1.141\n  confiance 0.5 : VFL 0.658  MAL 0.693\n  confiance 0.7 : VFL 0.379  MAL 0.419\n  confiance 0.9 : VFL 0.204  MAL 0.268\n```\n\nCommençons par le groupe à IoU 0,05. Le score cible de MAL est de 0,011, ce qui veut dire que le modèle ne devrait avoir presque aucune confiance dans cette boîte. Quand la confiance monte de 0,1 à 0,9, MAL passe de 0,130 à 2,278 ; VFL seulement de 0,011 à 0,110. Dans le groupe à IoU 0,95, les deux sont proches.\n\nTraçons les courbes pour les deux mêmes IoU, avec un score de confiance balayé de 0,01 à 0,99, et regardons la ligne bleue du panneau du haut ainsi que l'écart entre les deux lignes du panneau du bas :\n\n![Graphique en courbes en deux panneaux ; en abscisse le score de confiance p, de 0 à 1, en ordonnée la perte des positifs, de 0 à 5. Le panneau du haut correspond à l'appariement de faible qualité à IoU 0,05 ; la VFL, en bleu, reste presque collée à 0 et ne monte légèrement, vers 0,2, que lorsque p approche 1 ; la MAL, en orange, monte avec la confiance et dépasse 4,5 à l'extrémité droite ; à p = 0,8 sont indiquées les valeurs MAL 1,59 et VFL 0,08. Le panneau du bas correspond au bon appariement à IoU 0,95 ; les deux courbes se superposent presque et descendent d'environ 4,2 à gauche jusqu'à environ 0,3 à droite.](/content/papers/assets/21732a76da8a0f9cb3357b46d97b4259752658feca9c55334a8415e8a6f45e26.png)\n\n*Figure : réalisée pour cette note, d'après les termes positifs des Eq. 3 et Eq. 4 de l'article, avec γ = 1,5 ; l'article original est sous licence CC BY-NC-SA 4.0, et sa figure n'est pas reproduite ici.*\n\nDans le panneau du haut, la VFL reste presque collée à 0, quelle que soit la confiance ; la MAL suit la confiance à la hausse et vaut 1,59 à p = 0,8, contre 0,08 seulement pour la VFL. Dans le panneau du bas, les deux courbes se superposent presque ; plus la confiance est basse, plus la perte est grande, et les deux pertes exigent à peu près la même chose d'un bon appariement.\n\nPassons au gradient. Dérivées par rapport au logit, les deux pertes prennent la forme « poids × (confiance − score cible) » ; prenons un point dans chacun des deux cas précédents :\n\n```python\n# Suite du bloc précédent. Dérivées par rapport au logit, les deux pertes valent « poids × (confiance − score cible) »\ndef grad_vfl(p, q):\n    return q * (p - q)\n\ndef grad_mal(p, q, gamma=1.5):\n    return p - q ** gamma\n\nfor q, p in ((0.05, 0.8), (0.95, 0.5)):\n    print(f\"IoU {q}, confiance {p} : VFL {grad_vfl(p, q):+.3f}, MAL {grad_mal(p, q):+.3f}\")\n```\n\n```text\nIoU 0.05, confiance 0.8 : VFL +0.038, MAL +0.789\nIoU 0.95, confiance 0.5 : VFL -0.427, MAL -0.426\n```\n\nPour la boîte à IoU 0,05 et confiance 0,8, le gradient de MAL vaut environ 21 fois celui de VFL, dans le sens d'une baisse de la confiance. Pour la boîte à IoU 0,95 et confiance 0,5, les deux valent environ −0,43 et poussent de la même façon la confiance vers le haut. MAL ne renforce la pression que sur les appariements de faible qualité, et les bons appariements sont traités comme avant.\n\nLes requêtes dont la boîte est de travers apprennent à être peu sûres d'elles, tandis que celles dont la boîte est juste gardent une confiance élevée. À l'évaluation, l'AP trie les boîtes par score de confiance ; les boîtes précises passent devant, et les résultats aux seuils d'IoU élevés s'améliorent. C'est l'interprétation de cette note ; les auteurs attribuent le gain apporté par MAL à une meilleure qualité des boîtes. Les chiffres de la Table 6, plus loin, vont dans le même sens, puisqu'avec MAL l'AP75 progresse alors que l'AP50 ne bouge presque pas.\n\nPour $\\gamma$, les auteurs ont testé quatre valeurs sur RT-DETRv2-R50 entraîné 24 époques (Table 5) ; les valeurs 1,3 ; 1,5 ; 1,8 et 2,0 donnent respectivement 52,2 ; 52,4 ; 52,1 et 51,9 AP, et ils ont retenu 1,5.\n\n### Le calendrier d'entraînement : s'échauffer, assembler, puis lever le pied\n\nDense O2O n'est pas actif du début à la fin. Les auteurs ont conçu un calendrier d'augmentation des données, combiné au taux d'apprentissage FlatCosine déjà utilisé par RTMDet, qui reste d'abord constant puis descend de moitié selon un cosinus. Prenons pour exemple la configuration officielle de RT-DETRv2-R50 sur 60 époques (Figure 5 et Table 10 de l'annexe de l'article) :\n\n| Époque | Augmentation des données | Taux d'apprentissage |\n| --- | --- | --- |\n| 0–4 | retournement et redimensionnement seulement (DataAug Warmup) | échauffement sur les 2 000 premières itérations, puis palier à 2e-4 |\n| 4–34 | Dense O2O : Mosaic, Mixup, plus les augmentations d'origine de RT-DETR | palier à 2e-4 |\n| 34–58 | retour aux augmentations d'origine de RT-DETR (perturbation des couleurs, zoom out, recadrage par IoU, retournement) | cosinus de 2e-4 à 1e-4 |\n| 58–60 | de nouveau retournement et redimensionnement seulement | 1e-4 |\n\n*Tableau : établi pour cette note d'après le fichier de configuration officiel `deim_r50vd_60e_coco.yml` et la Figure 5 de l'annexe.*\n\nLes 4 premières époques se passent volontairement des augmentations avancées. Selon l'annexe, l'attention de DETR n'a pas le biais inductif des convolutions et doit tout apprendre de zéro ; des images simples au début lui facilitent l'apprentissage. Dense O2O est ensuite actif pendant 30 époques, soit exactement la moitié de la durée totale. D'après les explications des auteurs sur GitHub, pour une durée totale de $E$ époques, les 4 premières servent à l'échauffement, Dense O2O est actif pendant les $E/2$ suivantes, et le taux d'apprentissage reste constant jusqu'à l'époque $4 + E/2$ avant de commencer à baisser. [DEIM #9](https://github.com/Intellindust-AI-Lab/DEIM/issues/9)\n\nPourquoi l'arrêter à mi-parcours ? L'article dit seulement que les résultats sont meilleurs quand Dense O2O s'arrête après la moitié des époques, sans tableau comparatif. Les images assemblées contiennent des objets à la fois plus nombreux et plus petits, différents des photos vues en validation ; revenir à des photos normales en seconde moitié permet peut-être au modèle de se réadapter à la distribution réelle. Dans la Table 12, le recul observé avec trop d'objets est lui aussi attribué par les auteurs au décalage de distribution. Ce paragraphe est une conjecture de cette note.\n\nLes configurations basées sur D-FINE ont une phase de plus. D-FINE lui-même ajoute en fin d'entraînement 8 époques sans augmentations avancées pour rechercher la valeur de décroissance de l'EMA, et DEIM reprend ce procédé. Les 50 époques annoncées dans la Table 1 de l'article correspondent donc à 58 dans la configuration officielle ; de même, les 72 époques indiquées pour D-FINE dans ce tableau sont 80 dans sa propre configuration. [DEIM #56](https://github.com/Intellindust-AI-Lab/DEIM/issues/56)\n\nCe calendrier donne aussi aux courbes de validation une allure un peu étrange. Un utilisateur qui comparait D-FINE et DEIM-D-FINE sur son propre jeu de données à une seule classe a constaté que l'AP de validation de DEIM restait en retrait pendant toute la première partie. Le premier auteur a répondu sur deux points. Dense O2O est une augmentation de données plus forte, et les scores de validation sont naturellement plus bas tant qu'elle est active ; la convergence rapide dont parle l'article désigne le fait d'atteindre un résultat égal ou meilleur en moins d'époques. Par ailleurs, les 2 000 itérations d'échauffement du taux d'apprentissage sont calibrées pour COCO ; sur ce petit jeu de données, l'échauffement ne se terminait que vers la 100e époque. Après avoir réduit l'échauffement à 500 itérations, l'utilisateur a obtenu une meilleure AP de 0,773 pour DEIM, contre 0,768 pour D-FINE. [DEIM #5](https://github.com/Intellindust-AI-Lab/DEIM/issues/5)\n\n## Discussion\n\n### Configuration expérimentale\n\nLes principales expériences se font sur COCO, avec entraînement sur train2017, évaluation sur val2017 et entrées de 640×640. Le backbone est préentraîné sur ImageNet-1k ; à part l'affinage depuis Objects365 de la Table 8, aucune donnée supplémentaire n'est utilisée. Les latences reprennent les chiffres de bout en bout mesurés par D-FINE sur GPU T4 en TensorRT FP16 ; DEIM ne change pas l'architecture, et un même modèle a la même latence avec ou sans DEIM.\n\nDEIM est appliqué à deux modèles de base. L'un est RT-DETRv2, déjà mentionné ; l'autre est [D-FINE](https://arxiv.org/abs/2410.13842v1). D-FINE est un DETR temps réel proposé en octobre 2024 par l'Université des sciences et technologies de Chine ; fondé sur l'architecture de RT-DETR, il remplace, pour la régression des boîtes, la prédiction directe des quatre coordonnées par une distribution de probabilité de la position de chaque bord, affinée couche après couche.\n\n### Face à D-FINE et YOLO\n\n| Modèle | Époques | AP | AP<sub>S</sub> | Latence (T4) |\n| --- | ---: | ---: | ---: | ---: |\n| D-FINE-L | 72 | 54,0 | 36,5 | 8,07 ms |\n| DEIM-D-FINE-L | 50 | 54,7 | 36,9 | 8,07 ms |\n| D-FINE-X | 72 | 55,8 | 37,3 | 12,89 ms |\n| DEIM-D-FINE-X | 50 | 56,5 | 38,8 | 12,89 ms |\n| YOLO11-X | 500 | 54,1 | 37,0 | 10,52 ms |\n| YOLOv9-E | 500 | 55,6 | 40,2 | 20,53 ms |\n\n*Tableau : extrait de la Table 1 de l'article, COCO val2017. D'après la note du tableau, la NMS de YOLO11-X a été réglée avec un seuil de confiance de 0,01.*\n\nÀ latence égale, DEIM fait gagner 0,7 AP à D-FINE-L comme à D-FINE-X, et le nombre d'époques du tableau passe de 72 à 50, soit environ 30 % de moins, comme l'écrit d'ailleurs le corps de l'article. En comptant les 8 époques EMA de chaque côté (58 contre 80), la réduction est d'environ 28 %. La formule « temps d'entraînement réduit de moitié » du résumé correspond à la comparaison de 36 contre 72 époques sur RT-DETRv2, plus loin.\n\nFace à YOLO, DEIM-D-FINE-L, avec 54,7 AP et 8,07 ms, devance YOLO11-X et ses 54,1 AP à 10,52 ms. Les petits objets restent le point faible du côté DETR ; l'AP<sub>S</sub> de DEIM-D-FINE-X est de 38,8 contre 40,2 pour YOLOv9-E, un écart que les auteurs reconnaissent dans le corps de l'article. Quant au nombre d'époques, il ne se compare qu'au sein d'une même famille, car le backbone de DEIM est déjà préentraîné sur ImageNet.\n\nLes auteurs écrivent aussi que YOLOv10 utilise une attribution hybride un à plusieurs et un à un, que les modèles DEIM le surpassent néanmoins sur toute la ligne, et que cela prouve l'efficacité de Dense O2O. Cette inférence va un peu loin. Les deux camps diffèrent par l'architecture, le préentraînement et la durée d'entraînement ; l'écart du tableau ne peut pas être attribué au seul Dense O2O, ni servir à juger la conception à deux têtes de YOLOv10. Pour voir l'effet propre de Dense O2O, il faut regarder les ablations ci-dessous.\n\n\n> [!TIP]\n> \n> YOLOv10 fait s'entraîner une tête un à plusieurs aux côtés de la tête un à un, et n'utilise que cette dernière à l'inférence ; vous pouvez consulter notre note :\n> \n> - **[[24.05] YOLOv10 : adieu, NMS](/blog/papers/object-detection/yolov10)**\n\n\n### Ablations : la part de Dense O2O et celle de MAL\n\n| Modèle de base | Époques | Dense O2O | MAL | AP | AP<sub>50</sub> | AP<sub>75</sub> |\n| --- | ---: | :---: | :---: | ---: | ---: | ---: |\n| RT-DETRv2-R50 | 72 | | | 53,4 | 71,6 | 57,4 |\n| RT-DETRv2-R50 | 36 | ✓ | | 53,6 | 71,9 | 58,2 |\n| RT-DETRv2-R50 | 36 | ✓ | ✓ | 53,9 | 71,7 | 58,6 |\n| D-FINE-L | 72 | | | 54,0 | 71,6 | 58,4 |\n| D-FINE-L | 36 | ✓ | | 54,2 | 72,1 | 58,9 |\n| D-FINE-L | 36 | ✓ | ✓ | 54,6 | 72,2 | 59,5 |\n\n*Tableau : Table 6 de l'article.*\n\nAvec Dense O2O seul, 36 époques suffisent pour rattraper, et légèrement dépasser, le score du modèle de référence à 72 époques ; en ajoutant MAL, les deux modèles de base gagnent encore 0,3 et 0,4 AP respectivement. En heures GPU (Table 7), RT-DETRv2-R50 d'origine atteint 53,4 en 72 époques et environ 85 heures, et DEIM 54,3 en 60 époques et environ 71 heures.\n\nCe tableau compare DEIM à 36 époques à la version d'origine à 72 époques, sans témoin à 36 époques sans Dense O2O. D'après l'annexe et les fichiers de configuration officiels, les expériences DEIM adoptent aussi toute la recette d'entraînement des auteurs, dont le nouveau calendrier du taux d'apprentissage et de l'augmentation des données, le dégel des BN du backbone et le passage du décodeur à SiLU ; toujours d'après la configuration officielle, le taux d'apprentissage de base de RT-DETRv2 passe en outre de 1e-4 à 2e-4.\n\nDans l'annexe, les auteurs ont testé ces petites modifications seules sur D-FINE ; avec 36 époques d'entraînement, D-FINE-L ne change pas et D-FINE-X passe de 55,4 à 55,5. Au passage, D-FINE-X atteint déjà 55,4 avec seulement 36 époques, pas loin des 55,8 obtenus en 72.\n\nLa comparaison à nombre d'époques égal se trouve dans la Table 4. RT-DETRv2-R50 y est entraîné 12 et 24 époques, en ne changeant que les probabilités de Mosaic et de Mixup :\n\n| Mosaic | Mixup | AP (12 ép.) | AP (24 ép.) | AP<sub>S</sub> (24 ép.) |\n| ---: | ---: | ---: | ---: | ---: |\n| 0 | 0 | 49,6 | 51,7 | 32,8 |\n| 0,5 | 0 | 50,4 | 51,9 | 34,9 |\n| 0 | 0,5 | 50,1 | 51,5 | 33,2 |\n| 0,5 | 0,5 | 50,4 | 52,5 | 34,9 |\n\n*Tableau : extrait de la Table 4 de l'article.*\n\nAvec les deux activés, on gagne 0,8 AP à 12 comme à 24 époques, et l'AP sur les petits objets gagne 2,1 à 24 époques. Mixup seul donne même un résultat légèrement inférieur à 24 époques. C'est le gain propre de Dense O2O à conditions égales, une comparaison plus nette que celle de la Table 6, qui mélange les durées d'entraînement.\n\nLa Table 13 de l'annexe compare aussi l'AP sur l'ensemble d'entraînement. DEIM y est légèrement plus bas (64,8 contre 65,1), mais plus haut en validation (54,3 contre 53,4), ce que les auteurs interprètent comme un moindre surapprentissage des données d'entraînement.\n\n### Quand les objets s'entassent\n\nCrowdHuman est un jeu de données de foules denses. Les auteurs suivent la configuration de D-FINE et entraînent les deux modèles 120 époques (Table 3) ; cette fois, DEIM n'économise pas d'époques :\n\n| Méthode | AP | AP<sub>75</sub> | AP<sub>S</sub> |\n| --- | ---: | ---: | ---: |\n| D-FINE-L | 56,0 | 59,4 | 29,0 |\n| DEIM-D-FINE-L | 57,5 | 62,9 | 33,2 |\n\n*Tableau : extrait de la Table 3 de l'article.*\n\nL'AP gagne 1,5, l'AP<sub>75</sub> 3,5 et l'AP<sub>S</sub> 4,2 ; les progrès se concentrent là où la boîte doit être précise et l'objet est petit.\n\nLes exemples qualitatifs de l'annexe touchent aussi aux doublons. D-FINE-L produit pour un même cerf-volant quatre boîtes très superposées, toutes à forte confiance, alors que la version entraînée avec DEIM n'en garde qu'une. Ce n'est qu'un exemple sur une image, sans statistiques.\n\nEnfin, en partant des poids de D-FINE préentraînés sur Objects365 puis en affinant sur COCO, D-FINE-X atteint 59,3 AP après 32 époques d'affinage, et 59,5 avec DEIM après 24 époques (Table 8).\n\n### Retours de reproduction\n\nSur GitHub, un utilisateur a entraîné DEIM-D-FINE-X sur 8 A100 avec la configuration officielle. Il obtient 55,8 AP à l'époque 50 et 56,16 au bout des 58 époques, soit 0,3 de moins que les 56,5 de l'article ; il soupçonne lui-même que la taille de lot et le taux d'apprentissage ne sont pas alignés. Le premier auteur a répondu qu'il faut suivre strictement les 50 + 8 époques de la configuration officielle, et qu'à configuration identique la fluctuation est d'environ ±0,1 AP. En mars 2026, dans le même fil, un autre utilisateur a indiqué n'atteindre le plus souvent que 54,4 avec DEIM-D-FINE-L, sans joindre de journaux. [DEIM #112](https://github.com/Intellindust-AI-Lab/DEIM/issues/112)\n\n## Conclusion\n\nDEIM traite séparément les deux causes de la lente convergence de DETR. Contre le manque de positifs, on met plus d'objets dans chaque image d'entraînement ; l'appariement un à un produit naturellement plus de positifs, sans changer le calcul sur GPU. Les appariements de faible qualité qui s'ajoutent voient leur confiance abaissée par MAL, tandis que les bons appariements restent inchangés. Le calendrier d'entraînement place Dense O2O au milieu, avec un échauffement avant et un retour aux photos normales dans la seconde moitié.\n\nSur COCO, RT-DETRv2-R50 atteint 53,9 AP en 36 époques, contre 53,4 en 72 pour la version d'origine ; D-FINE-L et D-FINE-X gagnent chacun 0,7 AP à latence égale. Ces comparaisons changent aussi toute la recette d'entraînement ; le gain propre de Dense O2O à nombre d'époques égal est celui de la Table 4, soit 0,8 AP.\n\nSi vous entraînez RT-DETR ou D-FINE sur vos propres données, les modifications de DEIM sont toutes côté entraînement, et le modèle comme la chaîne d'inférence restent intacts. Les paramètres du calendrier sont en revanche calés sur la durée de COCO ; les 2 000 itérations d'échauffement et la plage de Dense O2O sont à recalculer selon le volume de vos données. Sur GitHub, des utilisateurs signalent aussi que sur leurs propres données, de quelques milliers à dix mille images, DEIM fait moins bien que YOLO ([#61](https://github.com/Intellindust-AI-Lab/DEIM/issues/61), [#106](https://github.com/Intellindust-AI-Lab/DEIM/issues/106)) ; ces discussions n'ont pas encore abouti.\n\nLes auteurs de DEIM ont ensuite publié DEIMv2 en septembre 2025, dont les versions S et au-delà utilisent les caractéristiques de DINOv3. Côté YOLO, on fait quelque chose de semblable ; pendant l'entraînement, [YOLO26](/blog/papers/object-detection/yolo26) transfère progressivement le poids de la perte un à plusieurs vers la tête un à un, et la supervision supplémentaire se concentre là aussi au début de l'entraînement.\n","imageSizes":{"/content/papers/assets/21732a76da8a0f9cb3357b46d97b4259752658feca9c55334a8415e8a6f45e26.png":{"width":1280,"height":1720}}}