摘要

玩家截一张游戏图，想让程序读出上面的数字：英雄面板上的攻击、防御、士气、运气和军队数量；生物信息面板上的名字、生命、伤害、先攻、速度；HUD（画面边缘常驻的英雄状态栏）上的攻防和法力。本实验（内部编号 B052）在已有的“手动单图读取”路径上加了这些数字字段的读取，只作为 Perception 模块里需要显式开启的功能，不改 App、状态估计或模拟器。

修订后的读取器在最新 71 张开发图上：363 个审核字段读对 351 个、读错 1 个、拒读 11 个；按图看，27 张有评分的图里只有 19 张所有字段全对（70.4%）。热身后整图端到端 p95 为 1.132 秒。这不满足“每个字段 ≥95%”和“十场独立对局”的产品目标，而且最新 5 场战斗来自同一个已曝光的录制时段。

要回答的问题

  1. 复用已有的区域定义、OCR 读取器和数字解析器，能把这些数字读到什么程度？
  2. 读错时是哪里出了问题——裁剪、图标、遮挡还是 OCR 本身？
  3. 从原图到 JSON 结果，热身后整图耗时多少？

数据与来源

  • 281 张已审核图片（来自更早的 B047 审核集）：前 210 张作训练/校准（165 训练、45 校准），修好配方之后才跑最新的 71 张。
  • 最新 71 张来自同一时段的 5 场战斗，视为一个已曝光来源组。冻结的“来源 17–22”和历史 HUD 16 张始终没打开。
  • 只对“明确标注过”的字段评分；部分标注不当作“其余都不对”。

方法

  • 触发条件：英雄字段只在独立检测到英雄面板和头像后读取；生物字段只在唯一检测到居中的生物面板时读取；HUD 字段只在旗帜/行动条等独立证据确认头像后读取。名字不确定不会抹掉清楚的数字。
  • 读取：一个常驻的 Paddle OCR 子进程（与 Torch 隔离）对每个裁剪读两遍：原尺寸和 3 倍放大。两遍分数都 ≥0.90 且一致才算一个候选——这是同一个模型读两遍，不是两份独立证据，也不是校准过的置信度。
  • 原则：负数、当前/最大 对和伤害范围都保留显示原文；不截断数字、不删数字之间的空格、不按游戏资料改名字、不从相邻帧抄值；归属（我方/敌方）保持未知。

修订：找到错误后改了什么

助手逐张查看了训练/校准的 4 块错误图板：

  1. 士气/运气的裁剪里混进了金色图标，导致负号丢失。修订 2 改用只包含文字的窄带（原图 y 375–405）。
  2. 标题带从 978 像素收窄到居中 560 像素，修好了一个被截断的生物名。
  3. 两个生命值被读成 42/4 和 82/8，实际是被提示框挡住的碎片，OCR 分数还很高。于是加了一个很窄的“背景连续性否决”：生命值格下方一小条像素的 RGB 中位数在三段之间差超过 8，就不接受。训练集清楚格的差为 0–5，两个错例为 10/11。

没有降低数字置信阈值，也没有按真值挑路线。修好之后才在最新 71 张上跑一次，没有针对最新图再改再跑。

设置

评分把“拒读”和“缺失”都算失败。生物数量、英雄资源等都是显示原文，不代表隐藏的真实状态。计时包括原图 → UI 识别 → 进程间通信 → OCR → JSON，冷启动单独计。

结果

集合 图片 审核字段 对 错 拒读 缺失 全对图片
训练（初版） 165 934 873 4 55 2 33/77
训练（修订） 165 934 913 0 19 2 59/77
校准（初版） 45 280 258 2 20 0 11/24
校准（修订） 45 280 274 0 6 0 18/24
最新（修订） 71 363 351 1 11 0 19/27

最新集按字段族：

字段族 对 / 声明 剩余问题
英雄数值与 7 个军队数量 178/187 9 个拒读，没有接受错值
生物标题与数值 173/176 2 个拒读，1 个接受了错误数量
HUD 数值 最新集未标注 只有训练 48/48、校准 32/32

弱项：英雄运气 8/11、士气 7/11、军队第 6 格数量 9/11；生物士气 14/16、数量 15/16。校准集生物名只有 8/12。

修订去掉图标带后，训练/校准里 5 个被接受的负号错误全部消失，最新集运气 16/16。背景否决在 281 张图里否决了 6 个生命候选（含淡出面板等未审核格），这不代表 6 个都是错的，也不代表所有遮挡都能发现。

耗时（最新 71 张，热身后）：整图 p95 1.132 秒，最大 1.231 秒；英雄面板 p95 0.289 秒、生物面板 0.260 秒、日志 0.530 秒。冷启动 UI 2.893 秒 + OCR 进程 5.678 秒，所以一次性冷用不满足 3 秒。

另有 1,004（训练）、252（校准）、441（最新）个读数没有标注、没有评分，多数是被其他面板压在下面的 HUD，不能称为已验证。

失败与负结果

  • 最新集 12 个失败逐张看过：11 个是清楚的值因 OCR 分数低被拒；1 个是 battle-06-14 的数量 95/95 下半部被提示框挡住，两遍都读成 05/05，被接受为错值。这个错误保留，没有针对这张图打补丁重跑。背景否决目前只覆盖生命值，数量格没有遮挡检查。
  • 评分程序初版遇到列表/字典混合标注和 42/不可见 这类部分字符串时停止；修好评分程序而没有重跑推理或改标签。
  • Perception 全套测试 7,198 通过、2 个既有失败、6 个跳过：两个冷导入测试在前面的测试把 Torch/CV2 加载进内存后失败，没有放宽断言。

局限

  • 所有图片来自已曝光来源；最新集不是盲测。重复的字段和帧不是独立实验。
  • 13 个选择侧栏布局、能力说明、攻击/法术预览、全面的局部遮挡判断、任意分辨率都未实现。
  • 归属保持未知；不推断基础属性、装备或技能。
  • 计时不含 App 截屏、显示和自动触发。

结论与下一步

数字字段读取已能在手动单图路径上工作，修订消除了图标混入导致的负号错误，但离产品目标还远：士气、运气、军队数量是弱项，被遮挡的数量会被读错。下一步是用训练来源做局部数字/可读性实验（尤其士气、运气、军队数量和被遮挡数量），并给 HUD 加明确标注，而不是给未审核输出打分。