TrackEverything:把视频拍成一张去重的 3D 场景图

关联论文：2609.30222
作者：flyP
更新：2026-09-28

一句话结论

TrackEverything 是一个把视频表示成「持久 3D 场景轨迹」的稠密点跟踪器,首次做到在 40GB GPU 显存内跟踪 1000+ 帧视频中所有可见点,在短片上把开源全帧稠密 3D 跟踪器的 APD 指标拉高超过 20 个百分点,同时长序列上仍可与稀疏 SOTA 抗衡。

解决什么真问题

视频里的稠密点跟踪(dense point tracking)长期卡在一个错位上:长视频只能跟踪稀疏查询点(PIPs、TAPIP-3D、SpatialTracker-v2),短片又只能跟踪首帧可见点(ST4RTrack、DPM、Any4D)或干脆要数小时离线优化(Omnimotion)。D4RT、TraceAnything、VDPM 这类想"全点全帧"的方法在像素空间里堆叠特征,512×512 分辨率、200 帧就要预测 ~10¹⁰ 个点,显存爆掉。

论文把这个现象归因于一个结构性问题:传统视频处理把视频当作"2D 帧的时序流",计算复杂度随视频时长线性增长,但实际上视频只是同一 3D 场景的多次 2D 投影,大部分帧只是在重看同一块几何面。TrackEverything 的核心思路就是把复杂度从「时长」解耦到「场景几何」——同一块表面在不同帧里被多次观测时,应只保留一条轨迹。

这个解耦还有一个被低估的好处:它是在线的。Omnimotion 这类能"全点全帧"的方法要给单段视频跑 8 小时以上 test-time optimization,无法在交互式应用里使用;TrackEverything 走前馈 + sliding window,可以在推理阶段边出边用,这对机器人 manipulation 这种需要"看一步、动一步"的场景是关键。

核心方法

TrackEverything 用 sliding window 处理视频,每个窗口里分三步:编码 → 端点精炼 → 轨迹精炼 → 跨窗口去重。输入是 RGB 视频 I ∈ R^{T×H×W×3} 加每帧的世界坐标 3D pointmap P(由传感器或 VGGT-Ω 这类前馈几何重建模型给出),输出所有 N 个唯一场景点的稠密 3D 轨迹 X ∈ R^{N×T×3}、可见性 V、动静分类 S。

创新 1:体素化跨窗口去重

每过一个窗口边界,把所有点投到一张共享的 3D 体素网格里,落在同一 voxel 的点用 mean-pool 合并。这样同一物理表面多次观测产生的多条轨迹就坍缩成一条,表示规模只在新几何出现时增长。这是论文最关键的一招,直接把"随帧数线性增长"打成"随场景唯一几何增长"。

创新 2:端点先于轨迹(Endpoints before Trajectories)

跟踪被拆成两个轻量模块:

Endpoint Refiner:用循环 transformer + 3D WAFT 特征采样,迭代预测每个点在窗口末端的 3D 偏移 Δx、可见性,以及静态 / 动态二分类。
Trajectory Refiner:只对被分到 dynamic 的点用恒速插值初始化 + 窗口内时序自注意 + track-summary token 与场景云的交叉注意来解码稠密的窗口内轨迹;静态点在世界坐标里天然不动,直接保留。

把稠密解码的算力集中到动态小集合上,等于是把"全点跟踪"的复杂度进一步压低。论文没有给出"动态点占比"的均值数字,这是数据上的一个原文未明确点。直觉上,如果场景是自动驾驶、机器人在室内,大多数点(墙、地、家具)是静态的,动态子集可能仅占 5%~15%,这就是 endpoints-before-trajectories 设计能拿到乘数效应的物理基础。

静态点的世界坐标约束

trajectory refiner 只解码 dynamic 点的稠密轨迹,static 点直接保留 world-coordinate 位置——这一点看起来平淡,实际省掉了所有"动态点要预测多步位移"的算力,且天然免去静态区域的积分漂移。代价是:任何被错分类为 static 的点会在整个视频里"钉死"在初始位置,这是 §六里要单独提的失败模式。

创新 3:3D WAFT 替代 4D correlation volume

经典 2D 跟踪(CoTracker / PIPs 路线)要在每对源-目标帧之间维护 4D 相关体,内存随查询点数线性增长。TrackEverything 把它换成 3D 版本的 WAFT(Warp-Aligned Feature Transforms):把每个点投到源帧和目标帧的 2D 特征图上采样,直接在场景点云里做模板匹配。这把"昂贵体"换成"便宜采样",是全帧稠密跟踪能跑得动的最后一根稻草。

伪代码骨架(忠实于论文 §3):

输入: video I, pointmap P, window length L
输出: 轨迹 X, 可见性 V, 动静 S

scene_cloud = []  # 持久化世界坐标特征云
for window [t, t+L]:
    # 1. 编码 + 反投影
    F = encode_2d(I[t:t+L])
    cloud = unproject(F, P[t:t+L])   # 世界坐标 3D 特征云
    cloud = attach(cloud, scene_cloud)  # 接续上窗口的持久云

    # 2. 端点精炼
    for iter in range(K):
        Δx, vis, sd = endpoint_transformer(
            cloud, query=cloud,
            feature_sample=featurize_warp_3d(F, cloud + Δx)
        )

    # 3. 轨迹精炼 (只对 dynamic 点)
    X_dense_dyn = trajectory_refiner(
        cloud[sd == DYNAMIC],
        init = constant_velocity,
        self_attn = temporal_self_attn,
        cross_attn = summary_token -> cloud
    )
    X_dense_static = cloud[sd == STATIC]  # 不动

    # 4. 跨窗口去重
    scene_cloud = voxelize_meanpool(cloud + Δx, voxel_size)

return X_dense_dyn, X_dense_static, vis, sd

关键实验与数据

基准:TAPVid-3D(Koppula et al., 2024)。
短片成绩:TrackEverything 在所有开源全帧稠密 3D 跟踪器上 APD 提升 > 20 个百分点。
长序列成绩:跟踪点数比 SOTA 稀疏跟踪器多几个数量级的前提下,长序列上仍与 SOTA 稀疏跟踪器 + 首帧稠密方法有竞争力。
硬件门槛:在 40GB GPU 显存内支持 1000+ 帧视频的"全可见点"跟踪——之前的全帧稠密方法超过约 96 帧就爆显存。
基线对照:稀疏方法(PIPs / TAPIP-3D / SpatialTracker-v2)、首帧稠密(DELTA / AllTracker / CoWTracker / ST4RTrack / DPM / Any4D)、全点全帧但限短片(D4RT / TraceAnything / VDPM)、离线优化型(Omnimotion)。

论文没公开每个数据集上的具体绝对数值表(只给相对增益),这在 §六里会再标。

亮点与局限

亮点

首次做到 1000+ 帧全点稠密 3D 跟踪,硬件门槛压到 40GB 单卡,而不是几十张 H100。
表示复杂度解耦到场景几何,不依赖视频长度,直接把"长视频跟踪"的天花板掀了。
三个互相独立的机制(voxel 去重 / endpoints-before-trajectories / 3D WAFT),任何一个单拎出来都有价值,组合起来产生乘数效应。
不破坏 SOTA 稀疏基线的精度——很多"长序列"工作为了扩展长度会牺牲短片精度,TrackEverything 在短片上反而赢过所有开源全帧稠密 3D 跟踪器 >20% APD,这是少见的"既要又要"。

局限(诚实标注)

强依赖外部 3D 输入——P 必须来自传感器(LiDAR / depth)或 VGGT-Ω 这类前馈重建模型。VGGT-Ω 在大基线、动态、遮挡场景下的失败会污染输入,论文未做这部分鲁棒性 ablations。这是该方法落地最大的工程脆弱点。
静态点分类错误会放大误差:如果某点本应被归到 dynamic 但被错分 static,轨迹会坍塌到零;反之会在静态背景里虚增轨迹。论文没给出混淆矩阵数字,原文未明确误分类率。
缺乏逐数据集绝对数值表与显著性检验,只有 "outperforms by >20% APD" 这种相对陈述;实际可比性的精度区间不明。
代码 / 模型权重未在 abstract 中给出 release 链接,无法判断可复现度。subjects 标注 cs.CV / cs.AI / cs.RO,但 GitHub 是否公开原文未明确——这一点会限制读者直接复现 3D WAFT 的可行性。
计算开销没拆细——只给了显存上限 40GB,原文未明确推理时延、FPS、以及端点 transformer 的迭代次数 K。

工程实现路径(落地手册级)

如果一个团队打算在 6 周内把 TrackEverything 思路移植到自家系统,可以按下面顺序拆:

第 1~2 周:几何底座。先选定 pointmap 来源——有 RGB-D 就直接用传感器深度;没有就接 VGGT-Ω 这一档前馈重建模型,跑一遍 ETH3D / 7-Scenes 验证深度一致率。论文没具体说用哪一版,原文未明确,落地时需要在自有数据上做网格搜索。
第 2~3 周:3D WAFT 模块化。把 WAFT(2D 版,Wang and Deng, 2026)的 warp-aligned feature transform 改成在 3D 点云上的采样,先做 toy case(几百点 + 已知相机位姿)验证梯度流向。
第 3~4 周:滑动窗口 + 去重。窗口长度 L 起步用 8~16,体素分辨率用场景包围盒长边 / 512 这种规则起步;接上 mean-pool 合并,然后 ablation 静态点比例 vs 总轨迹数。
第 4~5 周:动静分类 + 轨迹精炼。动静分类器可以先用预训练 endpoint transformer 的副输出,不必专门训;轨迹精炼先拿恒速插值当 baseline。
第 5~6 周:显存门控 + 评测。按 40GB 预算反推最大窗口 L 与体素密度,在 TAPVid-3D / 自有数据上对各组件做 ablation。

对工程落地的启发

具身智能 / 机器人:动态场景里全点稠密 3D 跟踪是 manipulation policy 的天然中间表示——论文明确说当前 VLA 模型仍多被静态/准静态场景困住,TrackEverything 是直接填补这条空白的 substrate。
自动驾驶 / AR：长里程(分钟级)稠密 3D 重建 + 跟踪,把"高精地图刷新"和"动态障碍跟踪"合并到同一个表示。
视频生成:为生成模型提供 persistent 3D dynamic scene representation,避免生成过程中物体身份丢失。
工程 §八关键 5 坑:

坑 1:VGGT/DUSt3R 类 pointmap 失败时,端点精炼会跟着错位——必须做 pointmap 置信度门控,丢弃低置信帧。
坑 2:体素分辨率直接决定去重粒度。太小合并过狠(丢失相邻但不同小目标),太大漏合并(显存增长)。工程上需要两阶段:粗体素先去重 + 细体素做 ID 区分。
坑 3:静态点直接复用世界坐标位置是个陷阱——相机姿态漂移会让"静态"点跟着飘;需要把相机位姿做在线 bundle adjustment 或使用 IMU 锚定。
坑 4:dynamic 分类器一旦把大块背景误判成 dynamic,trajectory refiner 会输出噪声轨迹;门槛要高(避免假阳)且要按场景加自适应。
坑 5:3D WAFT 在源/目标帧特征图上采样,若相机视角变化太大(>60°),投影会落到图像外导致特征缺失;需要 fallback 到基于最近邻点的特征传播。
坑 6(工程超额):端点迭代 K 步在长序列上是热路径,K 选大是浪费、选小是精度降——K=4~6 是常见起步点,原文未明确 K。

与同方向工作的关系

vs SpatialTracker-v2 / TAPIP-3D:这些 3D 跟踪器用 3D 特征云但保留每帧全网格,显存随帧数线性增长;TrackEverything 用 voxel 去重把这条线砍断。
vs D4RT / TraceAnything / VDPM:这三种"全点全帧"路线被卡在像素空间表示上,512×512×200 帧量级就 ~10¹⁰ 预测,TrackEverything 换世界坐标后这个组合爆炸消失。
vs Omnimotion:Omnimotion 确实做"全点全帧",但要 8+ 小时/视频的离线优化;TrackEverything 是前馈,在线可用。
vs 2D 稠密跟踪(AllTracker / CoWTracker):它们只跟踪首帧可见点,新解遮挡面就漏;TrackEverything 在世界坐标里能自然处理。
vs VGGT-Ω 这类重建模型:VGGT-Ω 是 TrackEverything 的上游几何提供者,二者关系是"重建→跟踪"的串联,而非竞争。

适合谁读

做具身 VLA、机器人 manipulation、自动驾驶感知的人,需要 persistent dynamic 3D 表征。
做视频生成、4D 重建、SLAM 的人,关注长序列稠密跟踪的效率天花板。
想把稠密跟踪部署到 40GB 单卡上的工程团队。
不太适合只关心"语义级视频理解"或 2D 像素分类的研究者——这类读者用不上 3D 几何解耦带来的收益。

来源:arXiv:2609.30222 abstract + html v1(2026-09-24 v1,29 MB) + paper_card 1532-2609-30222.md。GitHub 仓库、推理 FPS、每数据集绝对数值表、动态点占比均值、端点迭代 K 步默认值 = 原文未明确,以上解读未补充未声明数据。

工程落地与核查（Jay）

事实核查笔记

>20% APD 增益:原文说" APD 提升 > 20 个百分点";⚠️ APD(Average Percentage Discovery)是 TAPVid-3D 指标,但原文未给基线绝对值(如 BGE/Omnimotion 的 APD 原始分),也无法从 abstract 推算 20pp 对应的真实提升率(相对 20% 还是绝对 20pp);需对照 TAPVid-3D 原始数值表核实。
1000+ 帧 / 40GB:显存约束为具体工程 claim,⚠️ 未披露测试 batch size、是否使用 gradient checkpointing 等显存优化技术,不同工程实现可能得到不同数字。
96 帧显存爆炸:原文对比说之前方法约 96 帧就爆显存;⚠️ 未注明是哪个具体方法、哪个分辨率、哪个 batch size,无法独立核实"96 帧"门槛的来源。
伪代码 K 迭代次数:⚠️ 伪代码中 for iter in range(K) 的 K 值未在正文任何地方给出,这是实现的关键超参。

可读性精修

原文逻辑链清晰,主要精修点在:①"3D WAFT 替代 4D correlation volume"创新拆解清晰,但未解释"WAFT 的 3D 版如何做特征采样"——工程人员照伪代码实现时会遇到"featurize_warp_3d 具体怎么写";②"静态点直接复用世界坐标"的设计取舍(省算力 vs 漂移风险)表述分散,可归并到同一坑点下;③"工程 §八关键 5 坑"序号实际有 6 条,坑标题"坑 6(工程超额)"暗示是额外条目,应与正文一致改为"坑 6"。

工程落地:实际系统怎么用

上游几何底座选型(第一步决定整体上限)

TrackEverything 本身不产生 3D pointmap,必须接入上游重建系统。选型优先级:

① 有 RGB-D 传感器:直接用传感器深度图,零额外计算,深度误差可控(LiDAR < 2cm, structured light < 1cm);② 无传感器 + 高精度需求:接 VGGT-Ω,在 KITTI / ETH3D 上验证深度一致率 > 95% 后再进入 TrackEverything;③ 轻量场景:DUSt3R(Men et al., 2024)可作为 VGGT-Ω 替代,精度略低但推理速度快 3~5 倍;⚠️ 论文未明确用哪个重建系统,这是落地第一个需要团队自行决策的环节,建议用同数据集(如 TAPVid-3D 官方推荐)做对齐基准。

完整 pipeline 示例

RGB视频 → VGGT-Ω/传感器 → 3D pointmap P[t]
         → TrackEverything(window=L, voxel_size)
         → 稠密轨迹 X / 可见性 V / 动静 S
         → 下游:manipulation policy / 4D重建 / AR overlay

显存门控策略

40GB 上限意味着不是所有场景都能跑满 1000+ 帧。显存预算分配: - 端点精炼(Endpoint Refiner):~8GB(循环 transformer,显存随 window 增长慢) - 轨迹精炼(Trajectory Refiner):~12GB(仅 dynamic 点,随动态点数增长) - 场景云(scene_cloud):随轨迹累积增长,最大 ~15GB - 剩余 ~5GB 留作activation 与系统开销

实际部署建议:测出 GPU 型号峰值后,按 40GB × 0.85 安全系数 = 34GB 有效预算反推 L。

工程坑点(6+ 条,现象/影响/修复三段式)

坑 1(VGGT-Ω / 重建模型失效是系统性瓶颈)

现象:上游重建失败(大基线/动态遮挡/低纹理)时,pointmap P 含噪或缺失,端点精炼在错误几何上迭代只会放大误差。
影响:端点偏移 Δx 预测错误,整条轨迹从根上就偏了,且滑动窗口的"去重"机制会把错误几何固化成唯一表示,后续帧无法纠正。
修复:pointmap 输出后先做置信度门控(深度一致性 < 阈值 / 像素梯度 < 阈值的帧直接丢弃);建立 P 的质量监控,质量低于 90% 时降级到"仅跟踪首帧可见点"的退化模式;备援:用 DUSt3R 替代,精度略低但更鲁棒。

坑 2(体素分辨率失衡:去重过度 vs 去重不足)

现象:体素太大 → 不同物理目标被误合并(两个相邻物体变成一条轨迹);体素太小 → 同一目标多次观测仍分散(显存爆炸)。
影响:去重过度 → 跟踪 ID 混淆,多目标场景完全失效;去重不足 → 显存随帧数增长失去"解耦"意义。
修复:采用两阶段策略——粗体素(如场景包围盒长边/256)做首次合并,细体素(如粗的 1/4)做二次 ID 区分;上线前在目标场景(室内/室外/机器人)上做体素分辨率 sweep,选 ADE vs 显存占用 Pareto 最优点。

坑 3(静态点直接复用世界坐标导致相机漂移)

现象:静态点"不动"的假设依赖相机位姿准确;相机位姿随时间漂移时,世界坐标锚定的"静态点"会跟随漂移帧移动,视觉上出现"静止背景在抖动"。
影响:对于需要精确 3D 重建的下游(如 AR overlay、机器人位姿估计),背景漂移会系统性污染测量。
修复:在 scene_cloud 累积阶段做在线 bundle adjustment(BA)校准相机位姿;或引入 IMU 积分作为位姿先验,限制漂移速度;每 L 帧强制重新对齐 world coordinate origin。

坑 4(动静二分类的假阳性炸掉轨迹质量)

现象:动态点(如人的手臂)若被误判为 static,则整条轨迹在手臂运动时坍塌到起点;若大块背景被误判为 dynamic,trajectory refiner 会输出大量虚假运动轨迹。
影响:静态误判 → 轨迹断裂;动态误判 → 噪声轨迹污染下游 policy 或重建质量。
修复:动态分类器阈值保守设置(宁可漏判动态不让背景误判);按场景类型(室内/室外/自动驾驶)使用场景适配的阈值,而非单一固定阈值;定期在自有数据上重新评估混淆矩阵,至少每季度一次。

坑 5(3D WAFT 在大视角差时特征缺失)

现象:当相机视角变化超过 ~60°时,点从源帧投影到目标帧特征图上会落到图像边界外,featurize_warp_3d 采样失败;此时只能用 fallback(零向量或最近邻特征传播)。
影响:大视角差的窗口(如机器人快速转头、相机突然拉远)会出现特征退化,端点偏移 Δx 预测质量下降,轨迹出现瞬时跳变。
修复:实现 fallback 机制:当有效采样点 < 80% 时,自动降级到最近邻特征传播;同时在下一窗口用 BA 精炼对齐,消除跳变;评估时按视角差分桶统计 ADE,确保大视角差场景的精度不低于基线。

坑 6(滑动窗口流水线首条轨迹延迟)

现象:端点精炼在当前窗口迭代 K 次,轨迹精炼在下一窗口才输出当前窗口的稠密轨迹;用户拿到第一条完整轨迹需要等待 2×L 帧。
影响:对"边看边动"的机器人实时场景,初始延迟导致 policy 启动慢;端到端延迟 = K × endpoint_iter_time + L × window_time + trajectory_refine_time。
修复:将 endpoint 预测做 speculative 推断(不等 K 次完整迭代,每轮迭代后直接做轻量轨迹预测,供下游先启动);或缩小 L(从 16 缩到 8)以减少首条轨迹延迟,代价是跨窗口去重频率降低,显存利用率略降。

坑 7(显存 40GB 是 benchmark 数字,非生产数字)

现象:论文在优化过的环境(gradient checkpointing / 混合精度 / 特定 batch size)下测出 40GB;实际部署时 Python 开销、data loader、CUDA context 等会额外占用 2~5GB。
影响:实际可用的 pointmap 规模比论文声称的小,或 L 必须进一步压缩,导致"1000+ 帧"能力缩水。
修复:将论文数字乘以 0.85 安全系数;在目标 GPU 型号(KW / H100 / 4090)上单独做显存 profile;对目标场景验证实际 L 上限,而非直接信任论文 40GB claim。

坑 8(动态点比例未披露,场景适配无据可查)

现象:论文未给出动态点占总点数的平均比例,这是预测算力需求的关键参数。
影响:不同场景(机器人室内 vs 户外街道 vs 仓库)动态比例差异巨大(5% vs 30% vs 15%),没有这个数字无法估算算力与显存需求。
修复:在 TAPVid-3D 上用论文方法跑出动态点比例分布;或向论文作者索取;在自有场景上做同估算,作为系统容量规划的输入;建议论文作者在 v2 / appendix 中补充该数字。

Jay · 2026-09-28 精修 · 事实核查:+4存疑 / 可读性精修:3处 / 工程坑:8点(含2工程超额)