PS:好久没写csdn了,鸽了40多天了,惭愧惭愧,以后尽量提升更新频率。
今天分享的论文是三星研究院中的BackTrack:Robust template update via Backward Tracking of candidate template
2023年8月份的还是比较新的一篇。
论文网址:https://arxiv.org/abs/2308.10604.pdf
GitHub网址:未开源,但不知道后续会不会开源,论文末含伪代码。(三星研究院出来挨打,开源精神呢!!!)
主要架构流程:
目录
在线模板更新的历史
当下CNN/多头注意力在backbone方面能够提取出较强的特征用于跟踪。但是由于目标外观的变化、光照的变化、目标物体的遮挡以及类似干扰物的存在,模型仍然容易出现错误的跟踪。
于是,在线模板更新就应运而生了,比如stark、mixformer模型。这些跟踪器通过学习一个单独的验证器来选择额外的在线模板,该验证器称为置信度头(score predict)。头部预测用于决定目标的当前预测是否适合作为新模板的分数。如果当前预测中的候选模板得分足够高,则跟踪器将过时的在线模板替换为最近出现的模板。然而,对于模板更新,新模板的质量不足或更新的时间不合适可能会导致模型漂移问题,这会严重降低跟踪性能。
如上图的 Confidience head 即为置信度头,将最终预测的特征输入,得到 Conf. prediction score(分数)。
在线模板更新的流程
- 设定最大更新间隔(Max Update Interval)并初始化待更新模板为空
- 在目标跟踪的过程中,系统会不断检查当前更新的时间间隔是否小于设定的最大更新间隔。如果是,系统将执行以下步骤:
1). 使用分数预测(Score Predict)计算当前搜索目标的得分。
2). 判断计算得到的分数是否足够高以满足更新条件。
3). 如果得分足够高,则对待更新模板(或称候选模板)进行修正,以更准确地反映当前目标的特征。 - 当达到最大更新间隔时:从0到Max区间选择最好的候选模板,这通常是具有最高得分的模板。将选定的候选模板用于更新在线模板
依次循环往复。
在线模板更新的缺点
正如前面所说:对于模板更新,新模板的质量不足或更新的时间不合适可能会导致模型漂移问题,这会严重降低跟踪性能。
目前的在线模板更新策略存在如下问题:
最大更新间隔(Max Update Interval)人工设置困难
图中+BT表示的是使用本文的在线模板更新策略(BackTrack简称BT);黑线表示的是不采用在线模板分支的结果。图上是Lasot的结果。
首先看STARK模型,发现当最大更新间隔设置为5,10,15的时候,相比无在线模板分支情况来说,效果更差。这是很不好的,这说明了在线模板质量的低效,导致出现了负影响。当最大更新间隔设置较大时,发现模型效果又比较好了。
再看MixFormer模型,当最大更新间隔设置小于100的时候,会产生负影响。
综上,这就引出了第一个问题,最大更新间隔手动设置困难: 我们可以看到,针对不同的模型,最大更新间隔设置相同(比如STARK和MixFormer都设置为30),在线模板带来的影响是不同的(对于STARK模型而言,这个参数下的结果比黑线结果好,而MixFormer反之)。所以针对不同的模型,需要人工手动调参,设置最大更新间隔。同样的,对于不同的数据集,也需要人工手动调参。
思考1:最大更新间隔是不是越大越好?
当然,有人可能会说,我全设置200,或者往大的设置不就可以了吗? 但注意,这可能是你通过上面的图表(Lasot)结果而产生的第一反应。最大更新间隔设置很大,对于物体外观变化不明显的情况下,影响很小,而Lasot数据集就属于这种情况。 而如果物体外观在短期内(50帧的时候)发生了巨大形变,而到200帧或以后在更新,那就可能会产生负影响。因此,对于不同的数据集,也需要手工设置不同的最大更新间隔。
置信度头/分数的问题
上述流程的2.1中涉及了 分数 这个关键词。但如果这个分数 本身就存在一些问题呢?
可以看论文中的这个例子:
黑色框:原始模板。 蓝色框:待更新的模板。 黑色箭头:是否进行模板更新。 蓝色箭头:蓝色框的逆序跟踪轨迹。
论文中对应的图片描述如下(简单翻译):如何决定是否更新模板?(a)左:模板是否应根据当前预测进行更新(蓝框)?大多数当前的模板更新方法可能会回答“是”,因为原始模板(黑色)和当前预测具有非常相似的外观。右图:当我们在反转的时间内跟踪当前预测的对象时方式(蓝色箭头),第一帧的预测与原始目标不匹配,因此应该拒绝模板更新。(b) 由于后向跟踪的边界框与原始目标的边界框高度重叠,因此当前预测可以替换过时的模板。
我来简单说明下图片描述: 假设先不看右边的两个图,只看左边的两个图。 其实就是对应在线模板更新的判断操作,此时的判断依据是分数。看图a,b的左边,此时得分都是大于阈值,按照正常的判断流程就要进行剪切操作然后替换在线模板。
作者就对此持一个怀疑态度:这种更新的策略是否是正确的?是否是把正确的跟踪物体的图片剪切出来并更新?
于是就按照时间的逆序,去探究这个更新的物体是不是正确的,而不是干扰物?于是就进行图片的右边操作,根据蓝框的轨迹逆序跟踪,发现图a的蓝框其实是干扰物,那么就不应该进行更新!否则,会严重降低跟踪性能。图b的蓝框与黑框重合表示不是干扰物,就是跟踪的物体,那么就应该进行模板更新。
思考2:置信度头给出的得分的最终含义?(仅以STARK为例)
我们来思考下,这个分数到底和什么有关?(仅以STARK为例。MixFormer等其他模型可能在分数头这里有些许不同)
STARK模型中,传入置信度头的是特征图,然后通过MLP就得到这个分数(过程其实是非常简单的)。可以最终发现,这个分数其实就是和最终的特征图有关。
代码在https://github.com/researchmm/Stark/blob/main/lib/models/stark/stark_st.py#L65
综上,且涉及BackTrack论文中有这句话:原始模板和当前预测具有非常相似的外观,分数头就会给出较高的得分,用于后续的模板更新。但如果是外观非常相似的干扰物呢?即论文中举的图a的情况,就会导致模板更新错误!!
因此,按照外观情况得到的这个分数,可能存在着欺骗性。
BackTrack的改进点————前/后轨迹
上面硬币的图,反向轨迹其实就直接指明了BT的思想:既注重前向判断(置信度头),又看重后向轨迹(最后和初始模板的匹配情况)。
接下来我就从前向轨迹和后向轨迹来说明:
前向轨迹
这是比较好理解的,因为大多是模型考虑的都是前向的这一个过程。随着时间的增加,更新模板图片,然后再接着预测,跟踪,更新。
看论文中的图:
首先看图片最下面参数的说明: 初始模板图片Z0,在线模板Z’,当前的搜索区域Xt,候选在线模板Z*,需要注意的是候选在线模板Z*是time=N时刻Xt截取的图片。(简言之就是考虑Xn中跟踪的物体图片可否被后续用来做为在线模板。)
然后分析图片:
它是time=1时刻往前走,走到N时刻(需要注意,这里的N可以看作是最大更新间隔),需要保存的是每个预测框bbox的信息,即上半部分蓝绿色的区域。随着时间从前往后,bbox的位置信息就可以看成是一个轨迹。
如何获得bbox的信息呢?传入初始模板图片Z0,在线模板Z’,当前的搜索区域Xt,到fθ(就是跟踪模型)中进行预测,即可得到bbox位置信息。
看公式:上面公式是得到t时刻的bbox信息。下面的公式可以看作是bbox信息的拼接,可称之为轨迹B_forward。
然后看上面图片的下半部分,有个判断分支,判断是否进行在线模板更新?如果否的话,在线模板Z’不变,如果是的话,在线模板Z’被候选在线模板Z*替换(这和得分头的替换的步骤,含义是一样的)。
后向轨迹
图片上半部分的浅蓝绿色是前向的轨迹,因为随着时间的推移,time=1到time=N(需要注意,这里的N可以看作是最大更新间隔),我们可以可到B_forward,然后就是进行判断分支,但是判断分支要考虑后向轨迹,这就对应图片的下半部分
候选轨迹可能一开始不太好理解,需要多看几次。同样的,我们也需要获得bbox的信息呢:传入的参数是当前的搜索区域Xt,候选在线模板Z*,到fθ(就是跟踪模型)中进行预测,即可得到bbox位置信息。公式如下:
我们可以这么看第一个公式的含义,传入的是当前的搜索区域Xt,候选在线模板Z*。就是根据Xt的输入,去跟踪候选在线模板Z*对应的物体,所在的位置信息就是bbox。
同样的可以得到t时刻的bbox信息。下面的公式可以看作是bbox信息的拼接,可称之为后向轨迹B_backward。
总体的流程
- 设置好最大更新间隔N,初始化初始模板Z0,初始化在线模板Z’
- time<N时,得到B_t= fθ(xt,Z0,Z’) ,并把它加入到B_forward后面,形成前向轨迹
- time=N的时候,首先得到候选在线模板Z*=Crop(Xn,bbox_n)。并考虑是否更新在线模板,那么需要考虑后向轨迹。
- time递减,得到B_t= fθ(xt, ,Z*) ,并把它加入到B_backward后面,形成后向轨迹
- 根据作者的判断要求来考虑是否更新在线模板。(下面会讲)
现在我们需要知道,考虑是否更新在线模板前,我们需要获得前向轨迹B_forward,后向轨迹B_backward。那么按照什么约束条件来确定呢?看下文
在线模板更新的条件
考虑是否更新在线模板前,我们需要获得前向轨迹B_forward,后向轨迹B_backward。
最终作者认为需要同时满足下面条件则进行模板更新:
条件1
N个跟踪时刻中,对应时刻的前后轨迹bbox符合IOU>0.5的总数要至少满足σ*N 个。最终,作者这里设置的是0.9*N。
条件2
论文中特指t=1的初始时刻。要二者bbox的iou大于某一阈值σ。最终,作者这里设置的是0.9。
理解:其实这两个条件大致思想是一致的,就是二者某一轨迹的个bbox要有重叠。为什么呢?
因为前向轨迹中,传入的参数是初始模板图片Z0,在线模板Z’,当前的搜索区域Xt,就是根据搜索区域,来跟踪初始模板图片和在线模板图片中相似的物体,得到bbox_forward_t.
后向轨迹中,传入的参数是当前的搜索区域Xt,候选在线模板Z*,就是根据搜索区域,来跟踪候选在线模板图片中相似的物体,得到bbox_backward_t.
如果候选在线模板Z* 不是干扰物的话,那么肯定bbox_forward_t和bbox_backward_t的IOU不会太小。而如果候选在线模板Z*是干扰物的话,那么后向轨迹预测,肯定就会预测到别的物体上,导致IOU太小。
我举个例子说明下(我用紫框来表示bbox_forward_t,蓝色框表示为bbox_backward_t)
候选在线模板Z*不是干扰物:会发现bbox_forward_t和bbox_backward_t的IOU不会太小
候选在线模板Z*是干扰物:会发现bbox_forward_t和bbox_backward_t的IOU太小
模型整体架构
即考虑了前向轨迹------置信度分类头。又考虑了后向轨迹-----IOU比堆。
早期拒绝和早期终止
对于上面的前/后向轨迹,我们可以直观的感受到,肯定会减少整体的FPS一半,因为正常模型只需要考虑前向轨迹的1–N时刻,而BackTrack的思想是又考虑了后向轨迹的N–1时刻。
那么有没有什么改进的地方呢?
作者进一步提出了一种早期拒绝和终止方案,用于减少FPS的降低:早期拒绝和早期终止
早期拒绝
如果候选在线模板Z* 的分辨率小于(手动设置的)超参数模板大小。这句话说明,预测time=N时刻的bbox太小了,截取的候选在线模图片太小了,BackTrack会在没有任何反向跟踪计算的情况下拒绝更新,即不考虑后向轨迹,直接拒绝更新在线模板,考虑下一个N时刻。
早期终止
这个就比较好理解了,看条件约束1:
需要对应时刻的前后轨迹bbox的IOU>0.5的总数要至少满足σ*N 个。最终,作者这里设置的是0.9*N。
那么再后向轨迹time=N时刻往后,每个时刻time都计算对应时刻的IOU,如果不符合的个数超过了N- σ*N,那么就不考虑剩下的时间,直接拒绝更新在线模板,考虑下一个N时刻。
其他情况说明
发生模板更新:
[t1+1,t1+N]进行BT判断并且更新了模板,那么下次要考虑的模板更新的时间区间是[t1+N+1,t1+2N+1],即不考虑t1+N前的时刻。
没发生模板更新:
如果t1+N没有更新模板,那么下次要考虑的模板更新的时间区间是[t1+1,t1+N+N+1],但并不会考虑2N个bbox,而是从中均匀采样(每隔一张图片)N个图片,用于计算。
特别的,比如,假设K次都没更新模板,那么下次要考虑的模板更新的时间区间是[t1,t1+N* K],会从这个时间段中,采样第t1+K,t1+2* K,t1+3* K…t1+N* K,共N张图片来进行同样的BT操作。
换句话说,确保每次考虑在线模板更新所需的前/后向轨迹的计算时间是一样的!!!
消融实验
早期拒绝和早期终止的影响。
二者的使用既能提升FPS,又能不影响AUC。推荐是二者都使用
后向轨迹中不同图像尺寸大小的影响
作者是针对于OSTrack模型进行的消融实验,其中设置的搜索区域图片大小是384。
前向轨迹中的搜索区域图片的大小是384,后向轨迹中搜索区域图片的大小设置 64,128,384对结果的影响。可以看到后向轨迹中设置大小为128就能得到不错的效果,不用设置为384,这也可以进一步提升FPS。可以猜测后向轨迹中对于搜索区域图片的要求不是太高。
不同更新条件下的影响
回顾下两个约束条件:
作者这里考虑了,只用公式3, 只用公式4,二者都用的情况对结果的影响。可以看到公式四(只考虑time=1时刻二者的IOU)带来的效果会更好,但二者都用会带来最好的结果。这里的第三行的FPS可能会更高,因为只用考虑time=1时刻的后向轨迹,而第二、四行的条件下,会考虑所有的时刻。
不同的σ与更新间隔的取值影响
这点没啥好分析的,大力出奇迹!
实验结果
如果进行在线更新模板,结果都会得到提升。如果进行BT的更新选择,结果还会上升。
伪代码
部分伪代码(这里是最关键的部分),全部的可以看论文末。
总结
模型架构回顾:
本论文(BackTrack)重新思考了当下更新在线模板的局限性。然后就提出了前/后向轨迹思想,配合两个约束条件,新增更新在线模板的约束条件。并提出了早期拒绝和早期终止来弥补降低的FPS,进一步探讨了不同设置对模型的影响。
我的观点:应该是个即插即用的模块,可惜的是代码没有开源。对于整体模型的精确度有很大提升,普遍是2个点。 但FPS会有所下降,但作者提出了早期拒绝和早期终止,并且可以设置后向轨迹中较小的搜索图片大小来进一步提升FPS,本人的猜想是,FPS最多可以只降低20%的FPS,这相对于模型精度提升2个点来说是非常划算的。 而且BT的这个实现(可以看伪代码),其实不需要训练多少参数量,甚至为0,且只占用一些些的内存,非常的轻量化。
欢迎指正
因为本文主要是本人用来做的笔记,顺便进行知识巩固。如果本文对你有所帮助,那么本博客的目的就已经超额完成了。
本人英语水平、阅读论文能力、读写代码能力较为有限。有错误,恳请大佬指正,感谢。
欢迎交流
邮箱:refreshmentccoffee@gmail.com