战场左右上角各有一名英雄的头像、三项属性、资源和两行计时。它们位置固定，却并不容易直接解释：上面和下面的时间分别代表什么、左边是否一定是玩家、某个图标究竟是攻击还是防御，都需要证据。B029 先做更保守的工作——只读取屏幕上确实显示的区域和数字。
输入是 B033 从两段视频中选出的 68 张稳定候选帧；输出是每帧左右两个完整英雄 HUD crop 和左右两个计时 crop，共 272 个区域。计时 136 个 crop 全部得到上下成对读数；英雄 HUD 136 个 crop 中 124 个通过一致性门，12 个拒识。
flowchart LR
K[Stable keyframe] --> L[Left HUD crop]
K --> R[Right HUD crop]
L --> C[Two clock strings]
R --> C
L --> H[Three slots and resource values]
R --> H
C --> O[Observed screen fields]
H --> O图 1：程序输出“屏幕左/右、上/下、槽位 1/2/3”，不提前把位置翻译成玩家、敌人或具体属性名称。
1. 稳定关键帧让固定区域 OCR 变得便宜
68 张原图来自 2 个视频、6 个 30 秒区间：40 张来自 9 月 4 日视频，28 张来自 9 月 5 日视频。每张 2560×1440 原图固定裁出四块：左右完整 HUD 各 333×547，左右计时各 154×202。
图 2：完整 HUD crop 保留头像、三项数值和资源 current/maximum。裁图可用不代表字段含义已经识别。
图 3：计时 crop 同时包含上、下两行显示，OCR 必须成对返回，不能从上一帧硬补缺失字符。
抽查 4 张候选中的 10 个 crop，头像、三项面板数字、生命/资源显示和两行计时都没有被裁掉。这只验证区域范围，不是 OCR 真值评估。
2. 两路图像处理互相校验计时
PP-OCRv6 medium 分别读取原始 crop 和 3× CLAHE 增强 crop。CLAHE 是局部对比度增强，用来让细小数字更清楚。125 个 crop 在两路中都得到相同的两个 MM:SS；另 11 个只有增强路得到完整成对读数，集中在原图漏末位数字的 03:47 与 02:27。
这 11 个被标成 OBSERVED_WITH_INCOMPLETE_PASS，保留另一条不完整尝试，不伪装成两路一致。人工抽查 9 个计时 crop，显示原文与解析结果 9/9 一致。GPU 常驻批次处理 136 个 crop 用时 4.63 秒；这个时间不含完整冷启动。
3. 英雄 HUD 宁可拒识，也不拼接冲突数字
英雄 HUD 读取器只输出 attribute_slot_1/2/3 和 resource_current/resource_maximum。136 个 crop 中：
| 结果 | 数量 | 含义 |
|---|---|---|
| 两路完整一致 | 102 | 接受 |
| 只有一路完整 | 22 | 接受，但保留不完整尝试 |
| 两路完整但冲突 | 9 | 拒识 |
| 两路都不完整 | 3 | 拒识 |
| 总接受 | 124/136，91.18% | 开发集可用率，不是准确率 |
人工查看 10 个 HUD：6 个接受样例的四项读数都与画面一致；1 个冲突和 3 个不完整样例都没有被错误输出。一个典型冲突是增强路把 12 12 6 连成 12 126 6，拒识是正确选择。三个肉眼可读但 OCR 漏中间属性的样例说明召回仍不完整。
4. 当前输出只描述像素，不解释游戏角色
“左侧下方计时正在减少”是观察；“轮到我行动”是解释。B029 只负责前者。上下计时仍命名为 upper_clock 和 lower_clock，左/右仍是屏幕位置。英雄身份、图标语义、资源类型和行动方归属需要目录、上下文或相邻帧证据。
当前结果也不是独立 OCR 准确率：68 张帧来自开发视频，人工只抽查了一小部分。它证明的是稳定选帧可以快速批量生成可读固定区域，而且保守拒识没有阻断后续工作。
5. 这一步已经够用，接下来扩展标注覆盖
不为 12 个拒识继续调参。下一步把计时和英雄 HUD 加到平衡关键帧集合的全帧标注中，同时采集技能、法术、攻击悬浮文字。B031 用相邻读数判断哪一侧计时在下降；日志和实际画面再帮助解释两帧之间发生了什么。
最终本地推理时，每张关键帧会同时保留原始 OCR、解析值、证据状态和拒识原因。这样语义时间线既能显示数字，也不会把尚未确认的游戏含义写成事实。
Comments