摘要

战斗截图里有很多“弹出面板”：英雄详情、生物详情（名字、数量、生命、攻击、防御、伤害）、魔法书页、战斗日志、鼠标悬停时的法术/能力说明。之前的实验（B025）回答的是“给定正确区域，能否读出字段”；本实验（内部编号 B027）回答前一步：只有整张图的 OCR（光学字符识别，把图片中的文字转成字符串）结果，程序能不能自己找到面板和字段的位置，再交给同一个读取器？

它不是一次实验，而是 9 月 8 日至 9 月 22 日的一串开发迭代：

  1. 第一版用文字“锚点”定位面板，冻结后在 4 段新录像上检查：数值 21/42 读对，0 个错接，但有一个淡出的面板被错误放行。
  2. 第二、三版加了局部像素检查（判断面板是否半透明/在淡出）和魔法书排版检查。
  3. 之后发现很多字“看得清却没读到”：对自动找到的小格子重新裁原图、单独识别，效果远好于整图识别；但统一放大图片反而更差。
  4. 魔法书、法术说明、能力说明、生物属性等逐类补齐。

全部是在已经用过的开发录像上做的，参考答案由助手看原图写下、等待用户确认，不是独立盲测，也不是整帧完整标注。

要回答的问题

  • 不给“这是哪种面板”的标签、不给人工区域，只给整图 OCR 和上游“这是战斗画面”的判断，能找到哪些面板？
  • 找到后，字段能读对多少？有没有把错误的值接受进来（错接）？
  • 当面板正在淡出、半透明或被遮挡时，能否拒绝提交，即使字读对了？

项目的取舍是：宁可暂时不读，也不要接受错值——拒绝一次可以等下一帧，错值会污染后面的状态推断。但也不能靠“全部拒绝”过关。

数据与来源

  • 原图都是 2560×1440 或 1920×1080 的已有游戏截图及其缓存的整图 OCR（PP-OCRv6），本实验不重新解码视频、不重跑整图 OCR。
  • 第一版开发只用 1 段录像的 9 张图；冻结后用另外 4 段录像的 26 张图检查；第二版再换 4 段录像 24 张；第三版再换 4 段录像 24 张。每轮检查集都由另一位助手在算法冻结前挑选并看原图写参考，挑错的也保留。
  • 后续的局部重读、悬停说明等，使用一个 1,868 张的短悬停截图清单（逐步扫描，最后 595 张有 OCR）和一个更早的 513 张关键帧清单，以及跨 3 个来源的 97 张、中段战斗的 158 张。
  • 两段 9 月 12 日录像被保留为将来的验收集，全程未打开。

方法

定位（第一版）：用 OCR 读到的文字当“锚点”。例如生物面板要有“阶级”字样、附近的标题、两个“当前/最大”形式的分数；英雄面板要有唯一的英雄名、职业行和资源分数；魔法书要有多行对齐的法术名；日志要有多行带时间戳的句子。两种几何方法对比：fixed_layout 把数值区域放在固定位置；ocr_anchor 让数值区域随锚点平移。生成的大框只是搜索范围，不是像素级边界。

局部可用性检查（第二、三版）：

  • 生物面板：在面板的固定比例区域里数“暗蓝色像素”的比例，至少 85% 才算面板不透明、稳定。阈值只来自已曝光的开发图。
  • 魔法书：法术标题必须落在固定的三行、若干列附近（容差约 0.012/0.016 个画面宽度），否则认为在翻页。

局部重读（9 月 12 日起）：对自动找到的每个数值小格，从原图裁出来，用两个本地模型各读两遍：PP-OCRv6 medium（只做识别）和 PaddleOCR-VL-1.6（一个文档理解大模型）；配方分“原尺寸”和“边缘填充 8 像素后放大 4 倍”。PP 要求分数 ≥ 0.90；VL 没有可比较的分数。

评分规则：只有同面板类型、同字段、区域重叠（IoU ≥ 0.10，即两框交集占并集至少 10%）才比较数值；数值必须完整解析一致，文字只忽略空白和全/半角差异。没有参考的预测记为“未评估”，不进入任何分母。

设置

每一轮都先提交代码和协议、保存预测，然后才在另一个进程里读取参考答案评分；看过结果后再改参数就必须换新版本和新检查集。所有实验都只更新本地网站和报告，未替换默认视频流水线和公共接口。

结果

第一版冻结结果（两种几何方法在这轮各项计数完全相同）：

数据 图片 数值读对 / 参考数 错接 / 拒识 文字读对 / 参考数 负控拒绝
开发，1 段录像 9 34 / 47 0 / 13 8 / 21 4 / 4
冻结后跨录像，4 段 26 21 / 42 0 / 21 22 / 35 5 / 6

第二、三版在各自新检查集上：第二版 24 张图数值 26/46（同组第一版 19/46）；第三版另 24 张图数值 32/41（同组第二版 31/41），文字 22/25，没有数值错接。

局部重读：小格单独识别比整图强（9 月 12 日，77 张已曝光图、469 个自动裁框、1,876 次读取）：

方法 视频组读对 / 17 历史四源读对 / 41
原整图字段 0 32
PP 原尺寸 17 37
PP 放大 14 31
VL 原尺寸 14 36
四遍全部一致 11 28

所有方法在已有可读参考上都没有接受错值。

魔法书徽标（每个法术格子上的小数字和罗马数字）：先用霍夫圆检测找到圆形徽标、只裁内部，PP 原尺寸的阿拉伯数字从 132/171 提到 171/171；按类型组合两个模型后，首组 257 个可见徽标全对、191 个负例（图案、空槽、遮挡）全部拒绝。换 7 个新来源 11 张图后，冻结的组合只剩 175/211 外圈数字，看过失败后改进的版本为 313/321 字面正确、239 个负例全部拒绝。单页魔法书原先被“必须双页”规则整个挡住，修复入口后 147 个字面中 146 个读对。

悬停说明：法术说明在 13 张参考图的 158 个字段中，精确从原入口的 6 项增至 46 项（只用完整覆盖字段的 OCR 切块）；能力说明 7 图 39 字段中 37 项精确，另 2 项只差一个横线字形。

生物属性小数字：跨 3 个新来源的 7 块面板 28 个属性位置，VL 原尺寸 28/28；后来补读生命、攻防、伤害 28 项，原整图字段 20/28，PP 原尺寸 28/28。

失败与负结果

  • 淡出/半透明面板被放行。第一版就有一个淡出面板，字和名称都读对，但不应该提交；第三版的 12 个提交负例中放行 5 个，全部来自同一张半透明的生物面板。像素比例检查不能等同于“不透明度”，这个质量门缺陷至今保留，没有通过重标参考掩盖。
  • 统一放大更差。多次出现放大后把 8 读成 81、PP 读成 §；放大配方在魔法书上还多放过了空槽和图案。
  • 四遍全部一致反而漏读。让较弱的读法有一票否决权，覆盖明显下降（如生物属性 40 项中只剩 6 项）。
  • VL 会“幻读”。在强制读取的错误位置（雪地背景、日志、英雄面板）上，VL 原尺寸 100 个位置中输出了 24 个可解析值；魔法书图案中央也会读出数字。它适合在“已确认有面板”的前提下补读，不能跳过上下文检查。
  • 标题错接。一张狮鹫面板，旧版把画面顶部的“战术阶段”当成生物名称，因为真正的标题 OCR 分数只有约 0.75–0.84，没进入锚点集合。
  • 参考也会出错。一处魔法书数字最初被标为“被遮挡”，后来看原图发现黑色的 4 其实露在外面；这次更正没有被算作算法提升。
  • 罗马数字 I 常被读成 l、①、感叹号，7 个仍拒识，没有为它降低阈值或替换字符。
  • 缺数量的火凤凰面板虽然恢复了定位，数量 2/6 四种读法给出 26、2、2/8、2/6，仍记为未知。

局限

  • 全部是已曝光的开发数据，参考待用户确认，整帧完整标注数为 0；稀疏正确率不能当全图精度。
  • 只覆盖一种 16:9 中文界面布局；名称匹配只给出目录类型，不代表战场上哪一个兵堆、属于哪一方。
  • 局部重读的耗时只是逐裁图相加，不是端到端速度。
  • 状态图标、剩余回合、完整能力目录、面板与兵堆的绑定都未在本实验解决。

结论与下一步

程序已经能在不给人工框的情况下找到大部分面板，并且在已有参考上没有接受错值；最大的收益不来自更大的模型或放大图片，而来自把正确的格子按原尺寸裁出来再读。真正未解决的是“字读对了但不该提交”的质量判断（淡出、半透明）。下一步是保留旧结果、只对未定位或拒识的数值做原尺寸补读，同时扩大不同录像、被覆盖、无字小格等负例；在新的独立来源上验收之前，不切换默认流水线。