给各位省点时间，看到我这条issue就不要继续折腾这个repo了 #81
Comments
|
我不认同你的部分观点，虽然点偏移、匈牙利匹配是个摆设，但不能否定它的价值，你不能在今年2024年的角度去看待2021的论文。在2021年之前，都在all in 密度图去解决统计问题，虽然有像LSC-CNN用检测方法去解决统计问题，但效果是有限的，P2PNet是第一个尝试用点回归+点分类的方式去解决统计问题，输出的不在是看不到位置信息的密度图，而且在这之后，像CLTR、OT-M才在点回归上更深入的去研究。 从代码本身去讲，不管是ECCV2018的LCFCN、CVPR 2022的MAN、ECCV 2022的CLTR、CVPR2024的DiffuseDenoiseCount等算法都是在前人的基础上加了新的idea，使统计效果越来越好，这本身也是一种创新。 大部分人群统计算法为了公平的验证算法本身的效果，backbone都会采用VGG16或19，并不是想用什么backbone就上什么，P2PNet算法相对于其他算法，收敛速度是最快的，也可以很方便的移植到其他国产芯片上去做工程，既能得到人数也能看到人群的定位信息。 |
|
您好，我同意您的看法。但是我对这个repo的主要不满在于它过分夸大了自己的创新点。因为如果要做真正的点分类，我认为应该选择用类似DETR里面的transformer+ffn的head来进行一对一匹配才能被称为是真的学习到了点的位置和分类信息。而这篇文章是用本身就在空间上对齐的卷积层下面直接进行了点分类。这本质上就是一个下采样过的二分类语义分割任务而已，只是把目标点所在的像素设置成了1，并且我也实际测试过用clean code也能抖出来相同甚至更高的精度。所以我不是否定这个工作本身的价值，只是认为他过度夸大了自己的创新，甚至可能匈牙利匹配的一套东西都是实验结束后编造的故事。
…________________________________
From: xcaizewu ***@***.***>
Sent: Thursday, July 11, 2024 7:08:42 PM
To: TencentYoutuResearch/CrowdCounting-P2PNet ***@***.***>
Cc: 田杰 ***@***.***>; Author ***@***.***>
Subject: Re: [TencentYoutuResearch/CrowdCounting-P2PNet] 给各位省点时间，看到我这条issue就不要继续折腾这个repo了 (Issue #81)
我不认同你的部分观点，虽然点偏移、匈牙利匹配是个摆设，但不能否定它的价值，你不能在今年2024年的角度去看待2021的论文。在2021年之前，都在all in 密度图去解决统计问题，虽然有像LSC-CNN用检测方法去解决统计问题，但效果是有限的，P2PNet是第一个尝试用点回归+点分类的方式去解决统计问题，输出的不在是看不到位置信息的密度图，而且在这之后，像CLTR、OT-M才在点回归上更深入的去研究。
从代码本身去讲，不管是ECCV2018的LCFCN、CVPR 2022的MAN、ECCV 2022的CLTR、CVPR2024的DiffuseDenoiseCount等算法都是在前人的基础上加了新的idea，使统计效果越来越好，这本身也是一种创新。
大部分人群统计算法为了公平的验证算法本身的效果，backbone都会采用VGG16或19，并不是想用什么backbone就上什么，P2PNet算法相对于其他算法，收敛速度是最快的，也可以很方便的移植到其他国产芯片上去做工程，既能得到人数也能看到人群的定位信息。
―
Reply to this email directly, view it on GitHub<#81 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A2D6CYQYHMLLL34QUONKFYDZLZRTVAVCNFSM6AAAAABIUYTLWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRSGY2DSMZVG4>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
P2PNet qq交流群：790745540，互相帮助，解决bug问题 |
您好,24年那篇扩散模型进行人群计数的文章，您复现成功了吗？ 我发现那篇文章和作者给的代码有较大的出入 |
因为一个项目的需求从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也很困难，况且效果也不尽如人意...
The text was updated successfully, but these errors were encountered: