摘要：实时数字人的待机画面最容易翻车：虚影、脖子错位、眨眼像抽搐、整个人像蜡像。本文复盘如何用「单一来源 + 形变原画」把 5 秒待机从一眼假做到真人感：10 条实测铁律、6 步工序（全程 CPU，5–6 分钟一版）、眨眼与微动的落地参数，以及全部可复现的验收闸门数值。
一、问题：待机画面为什么总”一眼假”
实时数字人（口型驱动说话）系统里，老师大部分时间在静音待机。这一段的观感要求其实比说话更高——说话时观众注意力在内容上，待机时观众的注意力全在”这人像不像活的”。
我们踩过的典型翻车，按出现频率排：
| 现象 | 用户原话 |
|---|---|
| 虚影、重影 | “脸上有两条轮廓线” |
| 人脸/脖子错位 | “头和身体接不上” |
| 眨眼像抽搐 | “眨得太快，像机关枪” |
| 蜡像感 | “除了眨眼全是静止的” |
最初的方案是业界常见的”合成流”：拿一张锐利原画做底，用一段 i2v 生成的短视频提供动作，两者在椭圆边界羽化互叠，眼睛区域再加一层时间中值冻结防抖。这套方案同时踩中了三个雷：
- 两源互叠 = 虚影的物理成因。原画的脖子和视频的脖子在羽化带上必然半透明互叠——两条轮廓、一个色阶台阶，位置还随检测框逐帧漂移。
- 视频是软糊的。i2v 出片经过压缩 + 模型固有模糊，锐度只有原画的 76%；羽化区内外的清晰度落差肉眼可辨。
- 矩形冻结块穿帮。眼睛区的时间中值冻结是一块矩形硬边，把镜框、眉毛切成双线。
修复思路反而变简单了：放弃”两个来源合成”，回到”一个来源”。
二、核心原理：一个像素只能来自一张图
这是整套工作流的第一铁律：
成品里的每个像素，要么来自原画本身（经形变重采样），要么来自源视频的某一帧（经确定性合成贴入）——绝不允许两张不同来源的图羽化互叠。
推论有二：
- 所有”动”都是对原画的形变。呼吸、头身微晃，全部用解析形变场（高斯权重的局部缩放/旋转/平移）+
cv2.remap重采样实现。像素还是原画的像素，只是被”推”了 1–16px。锐度实测保留 99.4%（对比：混视频方案 76%）。 - 眨眼用视频里的真实闭眼帧贴回原画。不做几何建模（我们试过 6 次眼睑变形全败），而是从源视频里挑”半闭 M / 全闭 X”两个真实状态，做确定性合成贴进原画的眼区。
三、眨眼：为什么”自然”比”次数”难十倍
眨眼是待机动画的灵魂，也是我们花时间最多的地方。三条实测教训：
教训 1：源视频的眨眼本身就是”过快”的根源。 对 110 帧源视频逐帧扫描，真实闭眼只有 2–3 帧（0.08–0.13s）。把这种帧原样排进 5 秒循环，就是”机关枪眨眼”。
教训 2：不许用”复制帧”补出慢眨眼。 直觉方案是把 2 帧全闭复制成 4 帧拉长闭合时间——实测观感是硬开关，像抽搐不像眨眼。真眨眼是 [半闭→全闭→半闭] 的睑沿斜坡。正确做法：在源视频里找连续 3 帧以上的真实眨眼簇，直接取 M/X 两态排成 5 帧斜坡（≈0.21s），5 秒循环排 3 处。观感立刻从”抽搐”变”自然”。
教训 3：眨眼检测的传统指标全部失效。 三个连环坑：
dlibEAR（眼纵横比）在风格化原画上反向：闭眼帧 EAR 反而从 0.259 升到 0.332（landmark 在闭眼时反而更”张开”）。用它做闸门 = 永远 FAIL。- “对原画的绝对像素差”被基线淹没：视频与原画的色差基线就有 28，闭眼信号只有 20 左右。
- “只保留最大连通域”的掩码清洗会丢掉单侧眼睛——左眼闭合区比右眼小，被当碎块丢弃，结果做出”单眼眨眼”的诡异底板，还一路通过了旧闸门。
最终可靠的检测方案：按左眼/右眼分别量”相对闭合度”（眼区与同帧额头区的局部对照），找双眼同时上升的帧。配套一条硬闸门：眨眼补丁的像素范围必须同时覆盖左右眼的 x 区间。
四、微动：真人感 = 呼吸底噪 + 偶尔的调整
用户反馈”除了眨眼全是静止的，像蜡像”之后，我们加了三层微动（全部是形变原画，见第二节）：
- 呼吸：胸腔微缩放，1 个周期 / 5 秒（≈12 次/分，贴真人静息呼吸率）；
- 头身微晃：绕颈根微旋转 + 平移，1 周期与 2 周期混合避免匀速机械感；最大位移 9.3px（提供 4.7 / 9.3 / 15.8px 三档试片给人眼选）；
- 目光转动一次：虹膜位移 2.6px（≈虹膜直径 12%）+ 0.2° 头部随动，放在两处眨眼之间，方向是”看学生一眼再回到对方”，眨眼帧上自动关闭。
再叠一层静态表情：高斯权重局部形变做出轻微笑（嘴角/颊部 ≤5px）+ 暖眼（下睑），一次烘焙进底板。注意——微笑是静态的，嘴型开合依然全程禁止。数字人待机时嘴一动就露馅，这条红线从说话模块沿用过来。
一个工程细节：所有周期分量取整数周期 / 125 帧，保证首尾无缝——实测循环接缝处帧差 5.1px ≈ 单帧步进量，肉眼无跳变。
五、确定性：一个被低估的铁律
合成闭眼帧时我们用 cv2.seamlessClone（泊松融合）做过一版，目检通过、部署前复验时发现同样的输入两次调用结果不同（相差 9118 像素）——多线程泊松求解存在竞态。对”每次构建产物必须可复现”的管线，这种原语是定时炸弹。
替换为确定性合成三件套：ECC 仿射配准（把视频帧对齐到原画）→ Reinhard 色彩迁移（消除两源色温差）→ 高斯羽化膨胀混合（边界落在皮肤上）。全程纯 numpy/OpenCV 确定性算子，同样的输入永远得到同样的输出，且消除了 seamlessClone 偶发的灰块。
同理，验收指标也要”确定性”：绝对阈值会被微动本身污染（微动让全帧都有 1–9px 的位移，眨眼检测阈值直接失效），必须用局部对照（同一眨眼的前后帧自比）或相对上升量。我们的眨眼闸门读数长这样：对照 5.8/19.5/13.9 → 半闭 36/41/36 → 全闭 42.6/46.4/41.7 → 半闭回落——三段式清晰可判。
六、验收闸门：全过才许上线
| 闸门 | 判据 | 实测 |
|---|---|---|
| 眨眼结构 | 对照 ≪ 半闭 < 全闭，闭环回落 | 5.8→36→42.6→36.9 ✔ |
| 双眼同步 | 补丁范围覆盖左右眼 | x274–436 ✔ |
| 绿幕保留 | 纯绿像素数几乎不变 | 262867→262822 ✔ |
| 锐度 | ≥99% 原画 | 546→542（99.4%）✔ |
| 循环接缝 | ≈ 单帧步进量 | 5.1px ✔ |
| 目检 | 16 帧接触图：无重影/糊块/黑块/绿边 | ✔ |
| 端到端 | WebRTC 拉流落帧复验清晰度 + 目检 | ✔ |
目检有个反直觉的经验：视觉模型判读单帧不可信（我们对同一条对比条得到过自相矛盾的描述，甚至声称两张逐字节相同的图”不同”）。可靠的用法是让它判读放大后的对比条（原画 vs 成品、睁眼 vs 闭眼并排），并且永远用客观像素数值交叉验证它的结论。
七、工序与时间预算
全程 CPU，一版 5–6 分钟：
- 挑眨眼两态（~1min）：逐帧扫描源视频，按左右眼分别量相对闭合度，选 X/M；放大序列图人工复核”睁→闭→睁 + 左右同步”。
- 造底板（~1min）：原画 + 静态微笑/暖眼形变 + 确定性合成贴入 X/M → 三张底板；过补丁范围/绿幕/锐度闸门。
- 渲染表演（~2min）：呼吸 + 微晃 + 目光 + 3 处眨眼 → 125 帧序列 + 预览视频。
- 闸门（~1min）：上表七项全过。
- 安装（<1min）：帧序列拷入待机目录 + 写形象配置；引擎每次会话读取，无需重启。
- 端到端验收（~1min）：WebRTC 拉流实测。
调参只动一处：微动幅度 / 目光位移 / 微笑强度 / 眨眼帧位与时长 / 呼吸周期，每处都是渲染脚本里的一个常量，改完重渲 2 分钟出片给人眼定夺。
八、坑速查表
| 现象 | 根因 | 对策 |
|---|---|---|
| 虚影/脸含脖子错位 | 原画×视频羽化互叠 | 单一来源；形变原画 |
| 眨眼像抽搐 | 复制全闭帧充”慢眨眼” | 真实 M/X 两态排斜坡 |
| 眨眼只闭一只眼 | 掩码只留最大连通域 | 保留所有 ≥30px 连通域 |
| 眨眼测不出来 | EAR 在风格化原画反向 | 局部像素差+局部对照 |
| 合成结果每次不同 | seamlessClone 非确定性 | ECC+色彩迁移+羽化 |
| 形变后边缘露底色 | 形变取样出画 | BORDER_REPLICATE+位移≤16px |
| 说话区跟着糊 | 逐帧人脸框抖动 | 静态源建包，动效帧只写回目标区域 |
九、结语
这套工作流的本质是克制：不追求”生成式的大动作”，只给原画加最小必要的生命信号——呼吸、微晃、一次目光、三次真眨眼、一点微笑。每个像素都有出处，每次构建都可复现，每道闸门都有数值。
下一步计划把同一套流程复用到女士版与卡通儿童版——男士版验证过的”密胡须 + 眼镜”是最难场景（胡须纹理放大一切伪影、镜框切穿一切冻结块），卡通版的色块边界反而更宽容。
（完）
