ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

多人实时姿态估计:OpenPose与PAF原理解析与工程实践

多人实时姿态估计:OpenPose与PAF原理解析与工程实践 1. 先把OpenPose是什么说清楚1.1 一篇解决“多人实时姿态估计”的论文凭什么能拿CVPR最佳论文OpenPose是我在接触人体姿态估计时绕不开的一个名字。它的全称是《Realtime Multi-Person 2D Pose Estimation using Part Affinity Fields》发表在CVPR 2017并且拿到了当年的最佳论文奖。这篇论文解决的核心问题可以用一句话概括在一张包含多个人的图片里把每个人的手、脚、头、躯干这些关键点都找出来并且把这些点正确连回各自的主人身上整个过程还要快到接近实时。你可能觉得“找关键点”听起来不算难但实际上这个问题的复杂度比想象中高很多。在没有OpenPose之前主流方案是先调用目标检测算法框出每一个人再把每个框单独裁剪出来送入单人姿态估计模型。这套自上而下的流程有两个硬伤第一当画面里人很多时检测框数量暴涨姿态估计也要跑很多次运行时间会跟着人数线性上升第二当两个人挨得很近、互相遮挡时检测框经常把两个人的肢体混在一起后续的姿态估计就很容易错乱。OpenPose偏偏选了另一条路——自底向上。它先不管谁是“谁”把画面里所有可能出现的人体关键点全部检测出来然后用一种叫PAFPart Affinity Fields部位亲和场的数学工具判断哪些关键点属于同一个人最后把骨架组装起来。这样做的好处是哪怕画面里出现二十个人整套流程也只需要跑一遍网络计算量不会随人数暴增这才让“实时”两个字变成了现实。如果你是想快速搭建人体动作识别、健身动作计数、体育分析这类应用的开发者或者正在啃姿态估计方向论文的研究生理解OpenPose的这套设计思路基本就等于拿到了一把打开多人姿态估计大门的钥匙。很多后来出现的优秀模型比如OpenPifPaf、HigherHRNet都延续了自底向上的思想而它们的很多关键决策都能在OpenPose这篇论文里找到源头。1.2 为什么选择“自底向上”而不是“先检人再摆pose”刚才提到了自上而下和自底向上两种路线。很多刚接触姿态估计的人会有一个疑问自上而下听起来更符合直觉先找到人再分析动作为什么OpenPose的作者非要换个思路答案在于复杂度。自上而下的流程里人检测的框质量直接决定了姿态估计的天花板。一旦漏检一个人后面所有环节都白搭一旦两个框重叠后续的姿态估计又容易张冠李戴。而且图像中每增加一个人姿态估计网络就要被多调用一次这种“人数越多越慢”的特性在实际监控场景、活动现场、多人运动场景里都很难接受。OpenPose的作者做了一个很大胆的判断如果能把“检测关键点”和“关键点属于谁”这两个问题彻底解耦那么姿态估计的耗时就可以做到和人数无关。这个解耦思路说起来简单做起来却非常难。因为单看一个“肘关节”的激活响应你根本不知道它是画面中左边那个人的肘还是右边那个人的肘。OpenPose给出的答案是不仅检测关键点的位置还额外预测一组描述“肢体方向”的向量场。只要有这些方向信息就能把零散的关键点按“谁指向谁”的规则重新串联起来。我在实际项目中体验过两种思路的差异。自上而下的方案在小场景、单人或双人场景中往往精度更高但它太依赖目标检测器的效果了。自底向上的方案在人群密集场景里更能扛住压力速度快、逻辑清晰而且OpenPose这套“先点后线再连线成骨架”的思路在代码层面也更容易工程化。你不需要维护一个高精度的人体检测器只需要优化一个统一的卷积网络。1.3 一句话理解OpenPose的两个核心输出OpenPose网络最终输出两个东西一个是Part Confidence Maps中文常称为关键点置信图另一个是Part Affinity Fields也就是PAF。这两个输出是理解论文后半部分所有推导的基础。关键点置信图可以想象成一张热力图。网络会在每个人体关键点可能出现的位置上产生一个高斯状的响应峰峰值越接近1说明网络越确定这里存在一个关键点。它的作用就是回答第一个问题“画面里有哪些位置是关节”PAF则回答第二个问题“这些关节之间应该如何连接”它是一组向量场。对于人体骨架中的每一条肢体段比如右肘到右手腕这一段PAF会给这条线段覆盖区域内的每个像素赋予一个单位方向向量指向肢体段的另一端。这样当网络需要判断某一个肘关节和某一个腕关节是否属于同一个人时就可以沿着两点连线方向遍历所有像素看这条路径上的向量场方向和连线方向是否保持一致。方向一致匹配权重就高方向紊乱基本就可以判定这两个关键点不是一伙的。这两个输出一个管“有没有”一个管“连不连”配合起来就完成了从像素到骨架的整个过程。理解了这层关系后面的网络设计和图匹配推导就顺理成章了。我在第一次读论文时一开始也是被各种公式劝退但当我意识到整篇论文其实就是在讲“找点”和“连线”这两件事之后所有细节就都串起来了。2. PAF到底是什么网络怎么把它学出来2.1 从拼图游戏讲PAF方向场比距离判断高明在哪很多人第一次读PAF部分时会被数学符号吓到但它背后的直觉其实特别朴素。你可以想象自己正在拼一张被撕碎的人体照片碎片上有的画着肘有的画着手腕。这时候你手里有两类信息可以帮你拼图一类是碎片上关节的坐标位置另一类是碎片边缘那些微小的方向箭头。坐标位置告诉你“这些关节大概在哪里”但单靠坐标你还是很难判断哪个肘配哪个腕而那些方向箭头则直接告诉你“从我这里往这个方向走就会碰到和我是同一个人的下一个关节”。PAF就是这些方向箭头的矢量版。它给每一个肢体段定义了一个二维向量场如果某个像素正好落在某人右小臂的区域内那么这个像素上的向量就指向该人右小臂的另一端也就是从肘指向手腕。这样一来关键点之间的配对问题就从一个“距离度量问题”变成了一个“方向一致性检验问题”。为什么这一点很关键因为距离判断在拥挤场景下完全不可靠。假设画面里有两个人都伸出了右手A选手的肘和B选手的手腕在图像上可能靠得非常近按欧氏距离来匹配很容易把A的肘接到B的手腕上。但是如果我们观察PAF场A的肘附近的向量方向是朝A的手腕去的B的手腕附近的向量方向是朝B的肘来的两者方向根本对不上网络就能轻松避开这个陷阱。我在复现OpenPose的时候曾经把PAF分支的输出直接可视化出来做成箭头叠加在人物图上效果非常直观。你能清楚看到每个人的小臂区域有一簇方向一致的小箭头像是给骨头画上了流动的指引线。看到那个画面你就会明白为什么作者会说PAF是这篇论文最大的功臣。2.2 关键点置信图Confidence Map是怎么生成的先看置信图。训练时我们需要给每一个真实关键点位置生成一张概率图。对于第k个人的第j类关键点如果它的真实坐标为x_{j,k}那么置信图上的像素p的分数可以用一个二维高斯核来定义S_{j,k}(p) exp(-||p - x_{j,k}||^2 / 2σ^2)这个公式的意思是距离真实关键点越近的像素得分越接近1越远得分越趋近于0。σ控制高斯峰的“胖瘦”论文里取的是一个相对固定的经验值。当画面里有多个人时同一类关键点可能会在多个位置出现高斯峰网络要预测的是这些峰值的逐元素最大值而不是简单相加。用max而不是sum的目的很明确两个不同人的相同关键点即使靠得很近我们不希望它们的响应叠加成一个更高但位置偏移的峰而是希望网络仍然能区分出两个不同的极大值点。推理阶段网络输出的置信图上会有很多“山包”每个山包的局部极大值点就是一个候选关键点。为了筛选出真正可信的候选点有两个常用操作先对置信图做非极大值抑制NMS在一个小邻域内只保留响应值最高的像素再结合一个置信度阈值低于阈值的峰直接丢弃。这里有一个实操中的坑如果你在密集场景下发现漏检了某些人的手或脚不要急着调低阈值因为阈值拉低后置信图上会涌出大量噪声峰反而导致后续关键点配对时出现大量错误连接。更稳妥的做法是保持默认阈值通过提升输入分辨率来提高小目标关节的响应强度。2.3 PAF的定义与GT标注生成细节PAF的训练标注是整篇论文里最不容易一眼看懂的部分我们来拆开揉碎讲。设人体骨架中包含一组肢体段每个肢体段连接两个关键点。论文以第j个肢体段为例它连接的是关键点j1和j2。对于画面中的第k个人如果像素p恰好落在他/她的这段肢体覆盖范围内那么该像素上PAF gt的方向向量就是v_{j,k}(p) (x_{j2,k} - x_{j1,k}) / ||x_{j2,k} - x_{j1,k}||_2这里x_{j2,k}和x_{j1,k}是第k个人的两个关键点坐标相减得到从j1指向j2的向量再除以模长归一化为单位向量。也就是说PAF的GT只关心方向不关心肢体长度因此天然不会受到不同人体型差异的干扰。接下来要回答一个问题哪些像素算“落在这段肢体覆盖范围内”论文的做法是如果一个像素到线段x_{j1,k}-x_{j2,k}的垂直距离小于一个阈值σ_l就把它归入这段肢体。特别要注意的是如果像素到线段的垂足落在延长线上而不是线段内部距离计算要按到最近端点的距离来处理。这个细节在我自己实现GT生成时踩过坑如果不小心把延长线上的像素也划进肢体区域训练出来的PAF在关节端点附近会出现明显的方向紊乱因为那些像素被强行赋予了指向某个端点的向量但实际上它们早已越过端点根本不应该属于这段肢体。另外当多个人的同一段肢体在空间中重叠时PAF的处理方式是取向量平均值。这里和置信图用max不同原因在于向量场是可叠加的叠加平均会得到一个方向相对折中的场后续积分匹配时误差可控。如果也学置信图取max那么局部区域的方向信息会被某一个人的肢体完全主导另一个人的真实肢体方向就会被掩盖。生成好PAF的GT后网络就是把它当成一个回归问题来学损失函数用的是加权的L2距离只在GT向量非零的区域计算回归损失不在背景区域浪费学习能力。整个思路非常清晰网络要学的不是“肢体位置在哪”而是“肢体内部每个像素上的朝向是什么”。2.4 关键点配对从PAF积分到匈牙利算法网络推理完之后我们会得到一堆候选关键点和对应的PAF场。现在要解决最关键的问题怎么把正确的一对关键点连起来同时避免重复连接。论文采用的做法是对每一类肢体段单独处理。假设当前处理的是“肘到腕”这一类肢体画面中有M个肘关键点和N个腕关键点我们对所有可能的(M × N)个组合都计算一个连接置信度。计算公式是沿着肘到腕的连线方向均匀采样在PAF场上读取每个采样点处的向量然后与连线方向做点积、求和取平均。简单来说这个积分度量了“PAF场沿连线方向的指向程度”。如果PAF场强烈支持这条连线说明这条路径上确实存在一段肢体两个关键点很可能属于同一个人反之如果PAF场在连线上方向杂乱、点积时正时负最后统计值就会很低这条配对很可能不成立。计算完所有组合的权重后问题就变成了一个标准的二分图最大权匹配问题。每一侧的点只能用一次也就是一个肘只能匹配一个腕。论文用匈牙利算法求解这个最优匹配在数学上保证了全局连接一致性不会出现一个关键点同时连了多个另一端关键点的情况。不过这里有一个抽象层面的坑单个肢体段独立匹配虽然能保证该肢体段的点不重复但一套完整人体骨架是由多条肢体段组成的怎么保证左肘-左腕这条连接最终接到的是同一个人的左肩-左肘上OpenPose的做法是把人体定义成一棵以躯干为根节点的树从根节点开始逐层向下匹配每接入一个新肢体段时只需看该肢体段与已接入骨架的连接点是否同源。这个策略把全局优化拆成了多个局部二分匹配计算量可控效果也不错。我自己复现的时候为了省事直接写成了“每个肢体段单独匈牙利再按树结构合并”结果在单人场景下一切正常到两人交叉遮挡场景就偶尔会出现胳膊互插的错乱。后来老老实实按论文的树形顺序逐级匹配问题才缓解。3. 网络结构拆解双分支多阶段CNN3.1 从VGG特征到两个预测分支既然网络需要同时预测Confidence Map和PAF自然需要一个能“一心二用”的网络结构。OpenPose的处理方式是先用VGG-19的前面若干层一直到conv4_2对输入图片做特征提取得到一组共享的图像特征F。然后从F分出两个分支一个分支负责预测关键点置信图S另一个分支负责预测PAF场L。这里要特别注意两个分支是并行存在的而不是串联的。为什么要并行而不是先预测置信图、再用置信图去辅助预测PAF因为在OpenPose的设计里置信图和PAF不是“先后关系”而是“互补关系”。置信图回答“哪里是关节”PAF回答“关节之间如何连接”两个任务难度相当互相补充。让两个分支同时学习可以让共享特征层同时吸收两边的梯度信号加速收敛。第一次看到网络结构图时我一度以为两个分支完全独立直到细看论文才发现每个阶段的输出都会在下个阶段被重新拼接在一起作为输入。这意味着置信图和PAF之间其实会发生信息交换这为后面判断“关键点检测是否应该利用肢体连接信息”留下了伏笔。3.2 为什么需要多阶段和中间监督OpenPose的另一个标志性设计是“多阶段级联”论文中使用的阶段数记为T通常在实验中达到6个阶段。怎么理解这个级联机制可以把它想象成一个画家画素描的过程第一遍先画个大致的轮廓第二遍对着轮廓检查哪里不合理补上细节第三遍再检查再修正。OpenPose第一个阶段直接从VGG特征预测置信图和PAF输出一般比较粗糙但从第二阶段开始每个阶段网络都会接收三份输入——原始的VGG特征、上一阶段预测出的置信图、上一阶段预测出的PAF——然后输出一份更精细的预测结果。反复迭代几次之后骨架图的精确度会越来越高。多阶段设计背后有一个重要的训练技巧每个阶段都需要计算损失函数也就是中间监督。之所以要这么做一方面是因为网络层数加深后如果只在最后一层做监督靠反向传播把梯度送到最前面几层会非常困难训练很难收敛另一方面每一阶段都直接和GT做比较能让网络学到“每次修正一点”的增量式预测能力而不是把所有希望都押在最后一层。我自己的经验是训练这种多阶段网络时即使主干代码没有问题如果训练超参设置不对也会出现前几个阶段loss下降缓慢、最后一个阶段看起来可行、但推理时置信图出现大面积弥散的情况。这种情况下我一般会先排查每个阶段的loss在训练日志里是否都在同步下降。如果发现中间阶段loss长期不动基本可以判断是训练过程没有吃到足够的梯度而不是网络结构本身有缺陷。3.3 感受野为什么是PAF的胜负手PAF想刻画的是“长程”的肢体方向信息。随便拿一个像素点来说要判断它处于哪段肢体上、方向指向何处不能只看这个点周围几像素的图像内容必须看到更远的上下文。比如单看右肘附近的局部纹理你无法判断当前画面里右肘到底是向画面左侧伸还是向右侧伸但如果你能看到右肘与右肩的相对位置方向信息就清楚了。因此网络每一阶段都需要有足够大的感受野。OpenPose在阶段模块中使用了一系列卷积层通过层层堆叠把有效感受野逐步加大。论文里对这一点有过明确论述第一个阶段生成的PAF往往只在局部看起来合理一旦到了肢体跨越的区域就容易出错而随着阶段增加和感受野增长网络才能把整条肢体甚至整个人体结构都纳入考虑范围。这给工程实现提出了一个现实问题加大感受野会带来计算开销。OpenPose的做法是在每个阶段内使用分辨率较小的特征图相对输入图片缩小了8倍来跑卷积这样即使感受野覆盖范围很大所需乘加运算量也还在可控范围内。这也是为什么OpenPose输入图像是368×368时网络瓶颈层的特征图尺寸只有46×46左右。3.4 COCO 18点与BODY_25模型到底差在哪如果你去官方OpenPose开源库下载模型会看到它提供了好几种关键点模板最常用的是COCO 18点模型和BODY_25模型。这两者不是同一篇论文直接给出的但理解它们的差异对实际部署很有帮助。COCO 18点模型对应的是COCO数据集的17个人体关键点加一个背景类它输出的通道数是57其中19个通道是关键点置信图17个真实关键点1个背景1个整体置信图剩下的38个通道是19段肢体对应的PAF每段肢体占2个通道分别对应向量场的x分量和y分量。BODY_25模型则是CMU在开源代码中提供的25点版本在COCO 18点的基础上增加了脚部关键点大脚趾、小脚趾、脚跟还加上了颈部到鼻子的一些中间点更加适合需要精细脚步动作分析的应用场景。它的输出通道数是78内部逻辑和COCO版本完全一致。我在实际项目里通常优先选择BODY_25因为它对脚部动作的捕捉更全做健身计数、跳舞评分这类任务时非常有用。但如果你是直接对比论文实验或者想用COCO官方的评估指标来衡量模型精度那还是需要用COCO 18点模型。这里的经验是先想清楚你的应用是否需要脚部关键点再决定选哪个模型不要盲目追新。4. 训练与部署实操要点4.1 训练数据的组织与GT生成要自己从头训练一个OpenPose第一步不是搭建网络而是把训练数据准备好。官方论文用的是MPII和COCO数据集它们提供了每个人体关键点的坐标和可见性标注。在写数据加载器时我强烈建议把真实坐标从标注分辨率换算到网络输出分辨率时保留一个浮点数坐标值不要提前四舍五入成整数。因为GT置信图在生成高斯峰时对坐标精度非常敏感如果你把坐标取整到整数像素高斯峰的中心会偏移零点几个像素导致网络学到的关键点位置出现系统性偏移。这个问题在多人靠近、关键点密集时尤其明显。GT置信图的生成相对简单就是按我前面说的公式对每个关键点渲染一个高斯峰然后将同类型关键点的多个峰值做逐元素max。GT PAF的生成则要麻烦一些你需要先定义好人体的肢体连接表比如“左肩”连“左肘”、“左肘”连“左腕”等然后对每个人遍历每段肢体计算落在该肢体邻域内的所有像素给它们赋上单位方向向量。整个过程如果全用Python循环来写一张图就要跑很久工程上建议用numpy的向量化操作先为每段肢体生成一个mask和方向分量图再统一合成。4.2 数据增强里的一个大坑翻转后PAF也要跟着翻训练过程中免不了要加数据增强随机旋转、随机缩放、随机翻转都是标配。但这里有一个特别容易出错的点如果对图像做了水平翻转那你不仅要把关键点坐标做镜像变换还必须同步处理PAF的方向向量。原来指向画面右侧的向量翻到镜像空间里就变成指向左侧了如果不同步翻转PAF的x分量取反就等于给网络喂了自相矛盾的训练样本。我在早期训练时因为没注意这一点导致PAF分支在验证集上的误差一直下不来后来仔细检查了augmentation代码才发现翻转后的PAF方向一直保持原样。这里给你的建议是在实现里把“图像翻转”和“PAF翻转”的变换封装成同一个函数明确传出变换参数保证图像和标注永远走同一套几何变换能有效避免这类低级错误。随机旋转也有类似的坑。当画面旋转30度时关键点坐标要发生旋转肢体方向向量也要一起旋转。另外旋转后会产生边界空白区域常见的填充方式是用原图边缘像素或纯色填充但填充时不光要处理好关键点越界和标记为不可见还要同步更新PAF的mask不然空白区域里就会残留上一帧的方向向量干扰训练。4.3 从论文到工程用OpenCV DNN做快速推理论文讲完很多人最关心的是怎么快速做一个能跑通的Demo。最简单的方式不是用PyTorch重写网络而是直接用CMU官方训练好的模型配合OpenCV的DNN模块加载。官方仓库会提供Caffe格式的prototxt和caffemodelOpenCV的dnn.readNetFromCaffe可以直接加载不需要安装Caffe环境这对只做应用的同学非常友好。整个推理流程大概是先把输入图像调整到网络要求的尺寸常见配置是368×368对应网络的输入blob。然后执行一次net.forward()取出置信图和PAF两个输出。之后对置信图的每个通道做NMS拿到候选关键点列表再遍历每个肢体段对可能配对的关键点组合沿连线采样PAF、计算匹配分数最后按树结构组装骨架。这里要提醒一个容易忽略的问题输出层的空间分辨率一般比输入图像小通常是输入的1/8。所以从网络输出坐标映射回原图坐标时必须乘以一个比例系数并且最好在缩放回原图后再做一次坐标校偏。我见过很多新手在Demo里画出来的骨架总是虚位偏移多半就是漏了这一步尺度恢复。4.4 部署时的阈值怎么调精度与速度的跷跷板推理时CPU和GPU上都能跑但性能差异非常大。实测下来在GPU上处理368×368输入单人场景的耗时在几十毫秒量级基本能跑到20帧以上但如果在CPU上跑同样的输入可能要到几百毫秒甚至1秒以上。如果必须上CPU建议把输入尺寸降到256×256并关闭多尺度推理scale_search设置为[1]而不是[0.5, 1, 1.5]延迟能压到接近可用范围代价是近距离小目标检测精度会下降。阈值调节也是我踩过最多坑的地方之一。OpenPose有两个关键阈值一个用于过滤置信图上的低置信度关键点另一个用于过滤PAF匹配分数过低的关键点对。这两个阈值如果同时调得太低画面里会出现大量半截肢体或交叉连接的乱线如果调得太高又会漏掉一些角度刁钻或遮挡严重的关节。我的经验是先固定PAF匹配阈值在0.05附近单独调置信度阈值一旦置信度阈值确定再反过来微调PAF匹配阈值不要同时大幅改动两个阈值。5. 常见问题与调参排查实录5.1 骨架线乱连的根本原因最典型的故障表现是画面上骨架线满天飞有的线从左边人平移到右边人的手腕上。这种情况十有八九是PAF匹配阈值太低。PAF匹配分数是一段连线上所有采样点与PAF场方向点积的均值如果这个值低于某个临界点就说明连线方向与PAF场方向一致性很弱两个关键点很可能不属于同一个人。把这个阈值从0.01提高到0.05或者0.1往往能立刻去掉一大批错误连线。另一种导致乱连的情况是候选关键点太多太杂。置信图上的噪声峰没有被有效抑制时哪怕后续PAF匹配逻辑再正确也会因为待匹配节点过多而产生大量低质量组合。这个时候要看NMS的邻域半径是否设置合理如果邻域半径过小一个真实的关节模糊响应会分裂成多个候选峰如果邻域半径过大又会把相邻两人的同类型关节合并成一个峰直接造成漏检。5.2 单人姿态错位、左右混淆怎么办单人场景下最烦的是左右手/左右脚接反。这个问题通常不是网络笨而是训练数据里左右对称的关键点在视觉上很难区分网络在遮挡或低分辨率情况下容易混淆。实用一点的解决办法是在做下游任务时利用人体运动学的几何约束做后处理比如手臂长度和腿长度在帧与帧之间应该保持近似恒定如果某一帧出现了离谱的不等长手臂多半就是左右关键点匹配被调包了。还有一个容易踩的坑当你把OpenPose跑在非正面视角的监控画面上时关键点的语义可能随视角变化发生漂移。比如侧面视角下“左肩”对应的像素位置可能比“右肩”更靠近图像右边这在视觉上会让初学者误以为网络把左右标反了。所以不要凭画面直觉去判断左右是否正确要基于实际人体朝向做逻辑推断。5.3 实时性和精度平衡的实测经验如果你在做一个需要实时运行的App我的建议是不要一上来就追求最高精度先把链路跑通再逐步升级模型配置。以一个我实测过的项目为例在普通GPU上输入尺寸368×368BODY_25模型单人、多人混合场景下单帧推理时间在30到40毫秒之间加开多尺度推理后精度大概提升2到3个点但耗时直接翻倍变成70到80毫秒。如果你的瓶颈在CPU上而你又必须保证帧率可以尝试只保留置信图分支的轻量级推理PAF分支也照常输出但把匹配候选范围缩小到与上一帧相近的区域利用时间连续性做跟踪从而省去大量全图匹配计算。这个策略在几乎静止或慢速运动的场景里效果很好快速运动场景则容易丢失快速位移的关键点。还是要根据实际视频内容做取舍。6. 把论文思想迁移到其他领域6.1 不只是人体PAF其实是一种通用的关联建模方式OpenPose论文读到最后我觉得最有价值的不是人体姿态估计本身而是它提供了一个非常通用的思路当一张图里有多个同类目标而你既想知道每个目标的关键部件在哪里又想知道这些部件怎么分组时PAF这种“方向场匹配”的组合就是一把好用的钥匙。这套思路已经被拓展到很多方向。比如在手部姿态估计中同样可以用关键点置信图找指尖、指节用PAF建立指骨之间的连接在动物姿态估计里它也能被用在多只动物的关键点关联上。本质上只要你能定义出“部件”和“部件之间的连接关系”并且能为连接关系生成一个向量场标注OpenPose的训练和推理框架就都还能用。6.2 我的一个实际体会先把可视化做好再调任何参数最后分享一个我在反复读论文和调代码后形成的习惯不管任务多复杂先把置信图和PAF的可视化做出来放在原图上逐帧查看再动手调任何参数。置信图能告诉你网络有没有找到关键点PAF能告诉你网络到底学会了怎样的方向场。很多时候你调了半天阈值没效果一看可视化才发现根本不是阈值问题而是网络压根没在正确的位置产生响应。OpenPose这篇论文最大的魅力在于它把一个原本看起来需要全局优化的问题拆解成了可以局部并行处理的子问题而且每个子问题都有清晰可解释的物理含义。从这个角度去理解论文你会发现读它更像是在看一份工程落地经验总结而不只是数学推导。希望我上面的这些拆解能让你在读论文的时候少走一些弯路。
返回列表