关于和DINO共用

[Peterande]

请问文中和DINO的对比，最好的结果是同时使用DINO和O2M吗？虽然加入O2M前几个epoch收敛加快了，但后期似乎不如直接使用DINO效果好？

[Peterande]

还有就是请问一下o2o matching的结果为什么还需要merge到o2m上，o2o一般代表candidate里最好的，不是应该必然出现在o2m里嘛

[ZhaoChuyang]

请问文中和DINO的对比，最好的结果是同时使用DINO和O2M吗？虽然加入O2M前几个epoch收敛加快了，但后期似乎不如直接使用DINO效果好？

你好～请问您说的是与DINO结合的实验吗，我们是在 Deformable-DETR++ 的基础上加入了 O2M (-> MS-DETR) 和 DINO 的 CDN 模块训练的。

还有就是请问一下o2o matching的结果为什么还需要merge到o2m上，o2o一般代表candidate里最好的，不是应该必然出现在o2m里嘛

是的大部分的情况下 o2o 的结果都是包含在 o2m 当中的。但是也存在一些情况，由于 o2o 是使用匈牙利算法匹配得到的全局最优的结果，所以对于某一个特定的 GT，其匹配上的 query 并不一定是得分最高的（该 query 可能被其他的 GT 抢占）。另外由于 o2m 匹配会去除得分低于阈值的匹配结果，这会导致某些 GT 没有匹配上任何的 query。所以 o2o 和 o2m 的匹配结果之间可能会存在不一致的情况，由于最终预测是使用 o2o 的结果，所以这里把 o2o 的结果 merge 到 o2m 的结果中，避免两个分支训练时可能产生的不一致情况。但是这对最终性能的影响很小。

[Peterande]

你好～请问您说的是与DINO结合的实验吗，我们是在 Deformable-DETR++ 的基础上加入了 O2M (-> MS-DETR) 和 DINO 的 CDN 模块训练的。

我在DINO的基础上额外引入O2M，将CA和SA调换（impl.c) ，共用同一组Heads将CA和FFN的输出分别编码成Preds。并保证了只对原始的300个query（不对denoising queries) 进行O2M监督，在前几个epoch确实有显著收益（这可能与额外的监督有关）。但在中后期开始性能不如原始的DINO。是因为超参或者其他什么地方没注意导致的嘛？

[Peterande]

你好～请问您说的是与DINO结合的实验吗，我们是在 Deformable-DETR++ 的基础上加入了 O2M (-> MS-DETR) 和 DINO 的 CDN 模块训练的。

我在DINO的基础上额外引入O2M，将CA和SA调换（impl.c) ，共用同一组Heads将CA和FFN的输出分别编码成Preds。并保证了只对原始的300个query（不对denoising queries) 进行O2M监督，在前几个epoch确实有显著收益（这可能与额外的监督有关）。但在中后期开始性能不如原始的DINO。是因为超参或者其他什么地方没注意导致的嘛？

我好像找到一个可能的原因，我再继续跑几组实验试试，谢谢您

[xianjiez]

您好，DINO+O2M的试验后来有效果吗？我在DINO上加上O2M，性能下降挺多，不知道是不是哪里有问题

[Rbrq03]

请问这个问题有新的进展吗？很好奇DINO + O2M of MS-DETR 的效果

[ms12]

您好，DINO+O2M的试验后来有效果吗？我在DINO上加上O2M，性能下降挺多，不知道是不是哪里有问题

您好，请问找到性能下降的原因了吗？

[Peterande]

我觉得最大的可能是loss的权重需要调整。如果单纯地加入MS, 而不调参，loss会大很多倍，这显然是不合理的。但官方公布的代码似乎和原本的defomable DETR超参数一样，建议你们可以适当降低loss权重。

[JerryNeVerMORE]

我有个很有趣的补充，我是在rtdetr上改的，他的decoder基本和dino一样。第一次尝试加入o2m时候我忘记对o2m的loss乘权重，最后r18 coco 12e跑出来效果会比原版稍好一点，后面我发现并改正这个问题后，性能就下降了。所以权重可能确实需要调整。