search

linxuewu / Sparse4D

Sparse4D v1 & v2
https://arxiv.org/abs/2305.14018
MIT License
389 stars 42 forks source link

关于MOT #36

Closed czy341181 closed 8 months ago

czy341181 commented 11 months ago

感谢您非常棒的工作！这里想问一些问题。

问题1:对于跟踪任务而言，history query和det query是是有可能检测到同一个目标的吧？照论文的说法，会分配两个不同的track id，这个是如何解决的呢？

问题2:我在实验过程中，由于history query和det query有可能会命中相同的目标的，由于self attn会有抑制重复框的功能，会造成history query的score普遍偏低，所有检测结果基本都来源于当前帧的query，请问您在实验过程中有遇到过这种问题吗？

linxuewu commented 11 months ago

感谢您非常棒的工作！这里想问一些问题。

问题1:对于跟踪任务而言，history query和det query是是有可能检测到同一个目标的吧？照论文的说法，会分配两个不同的track id，这个是如何解决的呢？

问题2:我在实验过程中，由于history query和det query有可能会命中相同的目标的，由于self attn会有抑制重复框的功能，会造成history query的score普遍偏低，所有检测结果基本都来源于当前帧的query，请问您在实验过程中有遇到过这种问题吗？

  1. history query 和det query在第二层decoder混合在一起，之后每层都是one2one matching去训练，不会存在两个query匹配同一个目标的问题。在训练阶段优化的比较好的情况下，到了infer阶段，是不会出现 【两个query输出的box都对应同一个目标且score都很高 】的情况的。
  2. 这个现象我没有碰到过。首先，我们采用的history query的数量是600，det query数量是300，history query hit gt的概率就比较大。而且history query来自于上一帧的检测结果，其检测质量远比det query高，更容易匹配上gt，所以score不会低。
jacken3 commented 9 months ago

感谢您非常棒的工作！这里想问一些问题。 问题1:对于跟踪任务而言，history query和det query是是有可能检测到同一个目标的吧？照论文的说法，会分配两个不同的track id，这个是如何解决的呢？ 问题2:我在实验过程中，由于history query和det query有可能会命中相同的目标的，由于self attn会有抑制重复框的功能，会造成history query的score普遍偏低，所有检测结果基本都来源于当前帧的query，请问您在实验过程中有遇到过这种问题吗？

  1. history query 和det query在第二层decoder混合在一起，之后每层都是one2one matching去训练，不会存在两个query匹配同一个目标的问题。在训练阶段优化的比较好的情况下，到了infer阶段，是不会出现 【两个query输出的box都对应同一个目标且score都很高 】的情况的。
  2. 这个现象我没有碰到过。首先，我们采用的history query的数量是600，det query数量是300，history query hit gt的概率就比较大。而且history query来自于上一帧的检测结果，其检测质量远比det query高，更容易匹配上gt，所以score不会低。

您好，工作非常棒，但是关于v3做端到端跟踪我这里有一些问题,不知道您是否可以解答一下？ v3在arxiv上的文章我有拜读，如果我没理解错的话，端到端跟踪用的是类似于MOTR的那一套方案，也就是Track ID是直接绑定好的，历史Query直接继承绑定关系。但在训练阶段，track query和GT依据ID的强制绑定会导致大部分detec Query的监督变少，track query基本上承担了大部分障碍物的检出工作。但是在推理阶段，由于没有GT绑定,Track query ID的继承只能依靠阈值选择，训测是有Gap的。我们这边普遍的实验情况是，引入e2e跟踪后，检测的点数相对来说有比较明显的下降，但是我注意到贵组在nuScense上的实验结果好像并没有出现类似的情况，引入MOT任务后，检测的点数仍然很高，请问这点是如何做到的？

linxuewu commented 9 months ago

不是，和MOTR不同，这个点我在论文里面强调过了，在训练阶段我们不会进行任何tracking 的约束。完全和训练检测器一模一样，不需要进行任何变化，这也是我们方法的优势之一。

发件人: RunWenZhu @.***> 发送时间: 2024年1月21日 15:45:09 收件人: linxuewu/Sparse4D 抄送: xuewu.lin; Comment 主题: Re: [linxuewu/Sparse4D] 关于MOT (Issue #36)

谨慎:

这是一个来自外部的邮件，如果邮件中包含链接或附件等可能的风险因素，在操作之前请确保发件人可信，如不确认发件人可信，请联系邮件管理员。

感谢您非常棒的工作！这里想问一些问题。 问题1:对于跟踪任务而言，history query和det query是是有可能检测到同一个目标的吧？照论文的说法，会分配两个不同的track id，这个是如何解决的呢？ 问题2:我在实验过程中，由于history query和det query有可能会命中相同的目标的，由于self attn会有抑制重复框的功能，会造成history query的score普遍偏低，所有检测结果基本都来源于当前帧的query，请问您在实验过程中有遇到过这种问题吗？

  1. history query 和det query在第二层decoder混合在一起，之后每层都是one2one matching去训练，不会存在两个query匹配同一个目标的问题。在训练阶段优化的比较好的情况下，到了infer阶段，是不会出现 【两个query输出的box都对应同一个目标且score都很高 】的情况的。
  2. 这个现象我没有碰到过。首先，我们采用的history query的数量是600，det query数量是300，history query hit gt的概率就比较大。而且history query来自于上一帧的检测结果，其检测质量远比det query高，更容易匹配上gt，所以score不会低。

您好，工作非常棒，但是关于v3做端到端跟踪我这里有一些问题,不知道您是否可以解答一下？ v3在arxiv上的文章我有拜读，如果我没理解错的话，端到端跟踪用的是类似于MOTR的那一套方案，也就是Track ID是直接绑定好的，历史Query直接继承绑定关系。但在训练阶段，track query和GT依据ID的强制绑定会导致大部分detec Query的监督变少，track query基本上承担了大部分障碍物的检出工作。但是在推理阶段，由于没有GT绑定,Track query ID的继承只能依靠阈值选择，训测是有Gap的。我们这边普遍的实验情况是，引入e2e跟踪后，检测的点数相对来说有比较明显的下降，但是我注意到贵组在nuScense上的实验结果好像并没有出现类似的情况，引入MOT任务后，检测的点数仍然很高，请问这点是如何做到的？

― Reply to this email directly, view it on GitHubhttps://github.com/linxuewu/Sparse4D/issues/36#issuecomment-1902544028, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AL5SGB7DDFXRDZQLK33ZWZLYPTBQLAVCNFSM6AAAAAA7WAPP7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGU2DIMBSHA. You are receiving this because you commented.Message ID: @.***>

jacken3 commented 9 months ago

不是，和MOTR不同，这个点我在论文里面强调过了，在训练阶段我们不会进行任何tracking 的约束。完全和训练检测器一模一样，不需要进行任何变化，这也是我们方法的优势之一。 … ____ 发件人: RunWenZhu @.> 发送时间: 2024年1月21日 15:45:09 收件人: linxuewu/Sparse4D 抄送: xuewu.lin; Comment 主题: Re: [linxuewu/Sparse4D] 关于MOT (Issue #36) 谨慎: 这是一个来自外部的邮件，如果邮件中包含链接或附件等可能的风险因素，在操作之前请确保发件人可信，如不确认发件人可信，请联系邮件管理员。 感谢您非常棒的工作！这里想问一些问题。 问题1:对于跟踪任务而言，history query和det query是是有可能检测到同一个目标的吧？照论文的说法，会分配两个不同的track id，这个是如何解决的呢？ 问题2:我在实验过程中，由于history query和det query有可能会命中相同的目标的，由于self attn会有抑制重复框的功能，会造成history query的score普遍偏低，所有检测结果基本都来源于当前帧的query，请问您在实验过程中有遇到过这种问题吗？ 1. history query 和det query在第二层decoder混合在一起，之后每层都是one2one matching去训练，不会存在两个query匹配同一个目标的问题。在训练阶段优化的比较好的情况下，到了infer阶段，是不会出现 【两个query输出的box都对应同一个目标且score都很高 】的情况的。 2. 这个现象我没有碰到过。首先，我们采用的history query的数量是600，det query数量是300，history query hit gt的概率就比较大。而且history query来自于上一帧的检测结果，其检测质量远比det query高，更容易匹配上gt，所以score不会低。 您好，工作非常棒，但是关于v3做端到端跟踪我这里有一些问题,不知道您是否可以解答一下？ v3在arxiv上的文章我有拜读，如果我没理解错的话，端到端跟踪用的是类似于MOTR的那一套方案，也就是Track ID是直接绑定好的，历史Query直接继承绑定关系。但在训练阶段，track query和GT依据ID的强制绑定会导致大部分detec Query的监督变少，track query基本上承担了大部分障碍物的检出工作。但是在推理阶段，由于没有GT绑定,Track query ID的继承只能依靠阈值选择，训测是有Gap的。我们这边普遍的实验情况是，引入e2e跟踪后，检测的点数相对来说有比较明显的下降，但是我注意到贵组在nuScense上的实验结果好像并没有出现类似的情况，引入MOT任务后，检测的点数仍然很高，请问这点是如何做到的？ ― Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AL5SGB7DDFXRDZQLK33ZWZLYPTBQLAVCNFSM6AAAAAA7WAPP7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGU2DIMBSHA. You are receiving this because you commented.Message ID: @.>

如果·训练阶段不做tracking的约束的话，只在评测阶段做ID的绑定的话，不会导致IDS和Frag特别大吗，因为你本身在训练阶段就没有做强制的ID绑定，你没办法约束一个物体一定是由上一帧历史query完成检出的

linxuewu commented 9 months ago

不会导致IDS和Frag特别大，你看我们论文的实验数据以及nuscene leaderboard也可以发现sparse4dv3在ids和frag两个指标上也处于sota水准。

我试过加上tracking约束，会带来负向收益，我猜是因为tracking的累计误差导致的。如果有兴趣你可以试试。

3D detection with velocity的优化目标和tracking是一致的，所以只训detection就够了。 @jacken3