Open SalenGit opened 1 month ago
因为一个项目的需求从pwc上找到了这个项目，通读他们的论文和code之后发表一下自己的浅薄看法，如果有误轻喷。
这文章的噱头是非常足的，用匈牙利匹配来做点之间的一对一匹配，用类似DETR的思路直接回归每个点的坐标。但是点之间没有检测任务里的iou作为cost，所以只能采用distance和class作为cost。这听起来似乎是比较合理的。 那么这套代码是怎么实现的呢，他没有像DETR一样随机初始化一个Transformer Deocder，而是直接用了VGG的特征图，并且给每个坐标都预设了一个anchor，也就是说每个像素的坐标实际上已经预知了。同时，他的Matcher里给point的cost用的是坐标距离的MSE，而class的cost是概率的差值，实际上point那部分的数值已经完全盖过class了。同时因为anchor已经预设了每个像素的坐标，那么这个匹配过程实际上是完全固定的，就是匹配坐标最近的一个。实际上如果把训练过程中的匹配结果打印出来也会发现这个过程是固定的，而且总cost没有下降过。因此这个任务实际上已经完全退化为了一个像素级的二分类任务，关于点 偏移 匈牙利匹配这些东西已经完全成了摆设。 这也许也能解释为什么官方代码里故意少些一个s让point loss不参与训练，一个可以学习的坐标偏移肯定比不上预设的真实像素坐标来的准确。况且实测就算把那个loss加入训练，对结果也没有任何影响，依然不能改变那个固定的匹配过程。 而关于性能，在这么小的数据集上valid性能完全是抖出来的，所以直接拿人头的点坐标做一个二分类语义分割的unet，只要抖的够久，也能实现基本一样的性能。
这个项目初期给了我很大希望，也浪费了大量时间才意识到本质上只是一个像素分类任务。如果你认可我的观点，建议是不要继续折腾这套代码了，正如其它issue提到的，这就是拿DETR魔改来的东西，包袱非常重，debug也很困难，况且效果也不尽如人意...
因为一个项目的需求从pwc上找到了这个项目，通读他们的论文和code之后发表一下自己的浅薄看法，如果有误轻喷。
这文章的噱头是非常足的，用匈牙利匹配来做点之间的一对一匹配，用类似DETR的思路直接回归每个点的坐标。但是点之间没有检测任务里的iou作为cost，所以只能采用distance和class作为cost。这听起来似乎是比较合理的。 那么这套代码是怎么实现的呢，他没有像DETR一样随机初始化一个Transformer Deocder，而是直接用了VGG的特征图，并且给每个坐标都预设了一个anchor，也就是说每个像素的坐标实际上已经预知了。同时，他的Matcher里给point的cost用的是坐标距离的MSE，而class的cost是概率的差值，实际上point那部分的数值已经完全盖过class了。同时因为anchor已经预设了每个像素的坐标，那么这个匹配过程实际上是完全固定的，就是匹配坐标最近的一个。实际上如果把训练过程中的匹配结果打印出来也会发现这个过程是固定的，而且总cost没有下降过。因此这个任务实际上已经完全退化为了一个像素级的二分类任务，关于点 偏移 匈牙利匹配这些东西已经完全成了摆设。 这也许也能解释为什么官方代码里故意少些一个s让point loss不参与训练，一个可以学习的坐标偏移肯定比不上预设的真实像素坐标来的准确。况且实测就算把那个loss加入训练，对结果也没有任何影响，依然不能改变那个固定的匹配过程。 而关于性能，在这么小的数据集上valid性能完全是抖出来的，所以直接拿人头的点坐标做一个二分类语义分割的unet，只要抖的够久，也能实现基本一样的性能。
这个项目初期给了我很大希望，也浪费了大量时间才意识到本质上只是一个像素分类任务。如果你认可我的观点，建议是不要继续折腾这套代码了，正如其它issue提到的，这就是拿DETR魔改来的东西，包袱非常重，debug也很困难，况且效果也不尽如人意...