微信扫一扫,关注公众号

  • 科技行者

  • 算力行者

见证连接与计算的「力量」

首页 视频里的手,为什么总是"猜不准"

视频里的手,为什么总是"猜不准"

2026-11-11 14:47
分享至:
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-
2026-11-11 14:47 • 科技行者

你有没有试过,在视频通话里对方突然把手伸到画面边缘,或者被桌上的杯子挡住一半,你的大脑其实瞬间就能脑补出那只手接下来会怎么动。但计算机做不到这件事,至少以前做不到。

这正是手部动作捕捉领域一直头疼的问题。一只手在视频里挥动,经常被自己的手指挡住自己(医学上这叫自遮挡),或者被正在操作的物体挡住一部分,再加上快速移动带来的运动模糊,这些因素凑在一起,让计算机想要逐帧准确判断手的三维姿态变得异常困难。更麻烦的是,就算某一帧猜得还不错,下一帧又可能猜偏了,整段视频拼起来一看,手像是在抽搐,忽左忽右,一点都不自然。

这篇来自香港大学和加州伯克利分校团队的论文,提出了一个叫JoHan的新方法,试图从根本上换一种做法来解决这个老问题。

一件大家默认的事,其实一直被绕开了

在这篇论文之前,主流的做法基本是这样的:先用一个模型逐帧估计手的姿态,得到一串"猜测结果",然后再用另一个模型去优化这串结果,让它看起来更连贯。听起来挺合理,但问题就出在"逐帧估计"这一步本身。

如果某一帧因为遮挡猜错了,那么后面所有基于这个结果的优化,都是在一个错误的地基上修修补补。打个比方,这就像你让一个人先把一句被老鼠啃掉几个字的信纸念出来,然后再让另一个人根据这段"念出来的话"去润色成一篇通顺的文章。如果第一个人念错了关键词,后面润色得再漂亮,文章的意思也已经歪了。真正该做的,可能是直接拿着那张破损的信纸,结合上下文去猜测缺失的部分,而不是先念错再改。

更有意思的是,之前的研究大多把注意力放在三维姿态的生成上,却很少认真对待二维信息本身。

二维姿态*:指手部关节点在图像平面上的像素坐标位置,相当于把三维的手"拍扁"投影到照片上的样子。

这听起来像是个细节问题,但其实不是。二维坐标是直接从画面里能看到的东西,三维姿态却要额外猜测深度,也就是手离镜头多远。如果你完全不管二维轨迹自己的连贯性,只顾着生成三维动作,那三维重建就缺少了来自画面最直接的约束,这就好比你想精确还原一个人说话的口型,却完全不参考他嘴唇实际张合的样子,只凭声音去猜,误差自然会变大。

JoHan这篇论文的核心洞察就是:二维和三维本来就是通过几何投影牢牢绑在一起的两件事,为什么要分开处理?

JoHan怎么做:让二维和三维一起"生成"

JoHan最大的改变,是抛弃了"先逐帧估计、再优化"的老路,改用一种叫生成式建模的方式,直接从视频里同时生成二维和三维的手部动作序列。

生成式建模*:不是直接给出唯一答案,而是学习一个"合理动作的分布",再从这个分布里采样出具体结果。这样做的好处是,当画面信息不够、本身存在多种可能性时,模型能表达出这种不确定性,而不是死板地给一个可能是错的答案。

这里要特别说一下flow matching这个技术,它是JoHan用来实现生成过程的核心工具。

flow matching(流匹配)*:一种让模型从纯噪声逐步演化成目标数据的生成技术,有点像扩散模型的近亲,通过多步迭代,把一团随机噪声一点点"整形"成有意义的输出。

具体来说,JoHan设计了两个并行工作的生成器,一个专门生成二维的局部姿态序列,一个专门生成三维的局部姿态序列。这里说的"局部"是相对于"全局"而言的。

局部动作与全局动作*:局部动作指的是手指相对于手掌、手腕的姿态变化,这个主要由人体解剖结构决定,跨场景跨任务都比较稳定;全局动作则是手在摄像机坐标系里的整体位置和朝向,会随着任务、身体移动、摄像机晃动而大幅变化。

论文选择把这两者拆开处理,只学习局部动作的生成规律,这个决策背后的逻辑值得琢磨。

如果不拆开会怎样?想象你在教一个学生弹钢琴,如果你把"手指在琴键上的相对动作"和"整个人在舞台上走来走去的位置"混在一起教,学生会学得异常费劲,因为这两件事的规律性完全不同。手指动作有章可循,遵循肌肉骨骼结构;而人在舞台上怎么走,完全看场景需要,没什么规律可言。JoHan把这两者拆开,先专心学会"手指怎么协调动"这个有规律的部分,再用几何方法单独计算"手在镜头前到底在哪",这样学习效率和泛化能力都大大提升。

两个生成器不是各干各的,而是有一个巧妙的联动机制,叫2D引导融合。

2D引导融合*:在生成过程的每一步,先让二维生成器给出一个关于当前二维姿态的预测,再把这个预测编码成"指导信号",喂给三维生成器,让三维生成器参考这个二维线索来调整自己的输出。

这个设计的精妙之处在于方向性,二维去指导三维,而不是反过来。原因也很直观:二维信息是直接从画面里来的,更可靠;三维信息还要额外解决深度模糊的问题,没那么容易确定。让更可靠的信息去引导不那么确定的信息,这个逻辑跟物理学里"用观测数据去校正理论模型"是一个道理。

打个比方,这就像两个人一起拼一幅缺了很多块的拼图,一个人只能看到拼图的平面轮廓(二维),另一个人试图推测每一块的实际厚度和摆放角度(三维)。如果厚度推测的人完全不参考轮廓那个人的判断,自己瞎猜,拼出来的立体效果大概率是歪的。但如果厚度推测的人每拼一步都回头看看轮廓的进展,不断校准,最后的立体结构就会靠谱得多。如果不设计这种引导机制,论文的消融实验显示,纯三维生成器的PA-MPJPE(一种衡量姿态误差的指标,数值越小越准)是8.9毫米,而加入联合生成后降到7.8毫米。

视觉输入上的一个反常识选择

大部分前人方法,包括知名的HaMeR和WiLoR,都是先用检测器把手的区域裁剪出来,再送进模型处理,这样可以让模型专注在手这个局部区域,按理说应该更精确。

但JoHan反其道而行之,选择直接用全画面特征,再叠加上检测器给出的手部掩码作为辅助信息。

手部掩码*:根据检测框生成的一张二值图,标出画面里哪些像素属于手的区域。

论文的消融实验给出了一个让人意外的结果:如果换成裁剪后的手部图像作为输入,PA-MPJPE从7.8毫米恶化到8.9毫米,二维误差更是从5.21像素暴涨到15.68像素。

为什么会这样?裁剪框的大小和位置在不同帧之间会有轻微抖动,这种抖动会让裁剪出来的图像在缩放后产生手的尺寸和位置的细微变化,进而破坏了视觉上的连续性。对于单张图片的姿态估计,这点抖动或许无伤大雅,但对于需要跨帧保持时间一致性的视频生成任务,这种抖动会被放大成明显的误差。

这就好比你用手机连续拍一个人走路的视频,如果每一帧都单独手动对焦取景,哪怕你瞄准的始终是同一个人,取景框的轻微晃动也会让最终拼接出来的视频看起来一帧一帧地跳动。而如果你固定住整个场景不去单独取景,哪怕画面里信息更多更杂,拼出来的连贯性反而更好。

当然,完全不用检测信息也不是最优解。论文测试了完全不用手部掩码、只用全画面特征的版本,PA-MPJPE是8.0毫米,比加上掩码的7.8毫米略差,二维误差更是从5.21像素涨到了7.8像素。这说明掩码确实提供了有用的辅助定位信息,只是不应该用来裁剪画面本身,而是作为一种"软提示"叠加在完整画面特征上。

如何把局部姿态变成摄像机坐标系里的真实位置

生成出局部的二维和三维姿态之后,还差最后一步:怎么知道这只手在摄像机前到底是什么朝向、在什么位置?

这一步JoHan用了一个经典的计算机视觉工具,叫PnP求解器。

PnP(Perspective-n-Point)*:一种根据已知的三维点和它们在图像上对应的二维投影点,反推出相机相对于这些三维点的旋转和平移的算法,广泛用在三维重建和增强现实领域。

JoHan把生成的局部三维关节点和对应的二维关节坐标喂给PnP求解器,让它反推出全局的旋转和平移参数。这一步之所以可行,正是因为前面精心设计的联合生成机制保证了二维和三维输出之间存在几何对应关系,如果两者是各自独立生成、互不相关的,PnP根本没法工作,因为它需要的正是这种点对点的对应关系。

为了让这一步更准,论文还专门训练了一个轻量级的边界框修正器,用来纠正检测器给出的框和真实关节点范围之间的偏差,再配合卡尔曼滤波来平滑逐帧检测的抖动。

卡尔曼滤波*:一种经典的信号处理算法,通过结合历史观测和当前观测来给出更平滑、更可靠的估计,常用于目标跟踪和传感器融合。

这个边界框修正器的效果在论文的消融实验里体现得很直接:加入修正后,HOT3D数据集上的图像空间二维误差从5.18像素降到3.27像素,摄像机空间的MPJPE从46.05毫米降到33.84毫米,世界空间轨迹误差(W-MPJPE)也从78.37毫米降到55.05毫米。

实验结果说了什么

论文在三个数据集上做了验证:HO3Dv2、HO3Dv3,还有HOT3D。

在HO3Dv3上,JoHan拿到了7.0毫米的PA-MPJPE,是所有对比方法里最低的,二维关节误差是4.19像素,同样最优。更关键的是MPJPE这个指标,它衡量的是恢复到摄像机坐标系后的整体准确度,JoHan做到32.8毫米,相比WiLoR的53.5毫米和HaMeR的54.7毫米,几乎是砍掉了近四成的误差。

在移动摄像机场景的HOT3D数据集上,JoHan的PA-MPJPE是4.75毫米,加速度误差只有2.69米每平方秒,比HaWoR方法的7.14米每平方秒低了62.3%。

加速度误差(AccEr)*:衡量动作轨迹在时间上的平滑程度,数值越低说明动作越连贯自然,不会出现突兀的跳变。

这个数字意味着什么?想象两个人同时描述一段舞蹈动作,一个描述得行云流水,一个描述得忽快忽慢像是故障的录像带,前者就是加速度误差低的那种。JoHan在保持姿态准确的同时,动作明显更顺滑,这对于需要真实动作数据的AR/VR应用或者机器人模仿学习来说,意义重大,因为抖动的动作数据喂给下游任务,很可能被当成噪声甚至错误样本。

效率方面也有惊喜。在一段128帧的HOT3D视频片段上,JoHan完成整个手部恢复流程只需要2.03秒,而速度最快的对比方法WiLoR需要7.52秒,JoHan的用时只是它的27%。模型参数量也更小,351M对比WiLoR的630M,少了44.3%。这得益于JoHan用了更轻量的视觉编码器,以及一次性生成整段动作序列而不是逐帧处理的架构设计。

几个消融实验里的细节值得一提

论文还测试了把二维三维生成器分开训练、用真实二维标注去条件三维生成器的做法,结果PA-MPJPE反而恶化到12.89毫米,比单纯的三维生成器(8.9毫米)还差。

这个结果乍一看有点反直觉,用真实准确的标注去训练,怎么反而更差?原因在于训练和推理之间出现了不匹配:训练时模型看到的是完美的真实二维标注,但推理时手头只有模型自己生成的、带有噪声的二维预测,模型从没见过这种"不完美"的输入,相当于一个学生平时做题全靠抄答案,考试的时候突然要自己做题,自然手足无措。论文随后尝试给训练时的真实标注加入人工噪声模拟这种差异(一种叫教师强制的技巧),结果确实改善到9.49毫米,但依然不如JoHan采用的"全程用模型自己生成的二维引导"的做法(7.8毫米)。这说明,让模型在训练和推理时看到的输入分布保持一致,比单纯追求训练数据的"完美"更重要。

写在后面

读完这篇论文,有一个点让我反复琢磨了很久:为什么"局部"和"全局"的拆分会这么有效?

这其实触及了一个更普遍的建模原则,当一个问题里混杂着"规律性强的部分"和"规律性弱、高度依赖外部条件的部分"时,强行用一个模型同时学两者,效果往往不如拆开各自击破。手指怎么弯曲,这是解剖学决定的,放之四海而皆准;但手在空间里的绝对位置,取决于你在干什么、摄像机怎么动,几乎没有通用规律可言。这个拆分思路其实在很多领域都有影子,比如语音识别里把"音色"和"内容"分开建模,比如图像生成里把"结构"和"纹理"分开处理。JoHan算是把这个思路在手部动作重建这个具体问题上做了一次扎实的验证。

另一个让我意外的细节是,论文明确承认了自己的局限,它的世界空间轨迹精度(W-MPJPE和WA-MPJPE)略逊于最好的方法HaWoR。论文很坦诚地解释了原因:JoHan的重心在于学好局部动作的生成规律,全局的世界坐标是靠简单的几何变换拼接上去的,而不是端到端学出来的。这种"有所为有所不为"的设计取舍,其实比一味追求全面领先更值得尊重,它说明研究者清楚知道自己要解决的核心矛盾是什么,没有为了刷榜而牺牲思路的清晰度。

如果未来有人想把JoHan的全局轨迹精度也提上去,会不会需要重新引入某种端到端的学习机制?但那样做是否又会破坏局部动作学习的泛化能力?这本身就是一个值得继续追问的问题。

Q&A

Q1:JoHan是什么?

A:JoHan是港大和伯克利团队提出的一个生成式框架,能直接从视频里同时生成手部的二维和三维动作序列,不依赖逐帧姿态估计,重建效果更准确、动作更流畅。

Q2:JoHan为什么要同时生成二维和三维动作,而不是只做三维?

A:因为二维姿态直接来自画面观测更可靠,三维姿态要额外解决深度模糊问题。让二维去指导三维生成,能给三维重建提供更强的几何约束,实验显示这样做能让误差从8.9毫米降到7.8毫米。

Q3:JoHan相比之前的方法(如HaMeR、WiLoR、HaWoR)有什么优势?

A:在HO3Dv3上JoHan的摄像机空间误差只有32.8毫米,远低于WiLoR的53.5毫米;在HOT3D上动作更平滑,加速度误差降低62.3%;速度也更快,处理一段视频只需2.03秒,仅为WiLoR的27%。

分享至
0赞

好文章,需要你的鼓励

推荐文章
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-