摘要
在游戏里右键一个生物，会弹出生物信息面板：顶部是名字（标题），下面有数量、攻击、防御、幸运等数字。程序要从整张截图里找到这个面板，再裁出每个字段做 OCR（文字识别）。之前几轮发现了一些“读错却被接受”的数字和标题。本实验先用训练来源的像素补做审查，找出错误的真实原因，再试一个改进的裁框方案。
结果分两部分：审查本身是有用的数据工作——87 张训练帧逐格核对，新发现 5 个被错误接受的读数；但据此设计的新裁框方案在训练数据上反而更差（正确 115→105、错误 2→8），被拒绝。没有任何生产或默认路径被改动。
要回答的问题
- 训练来源里，生物面板的 11 个局部字段（身份与各项数值）到底读得怎样？错误接受是由什么造成的？
- 如果错误来自裁框几何（框切掉了字、或把背景文字一起框进来），换一个固定裁框能不能修好，同时不伤害原本读对的字段？
数据与来源
- 42 张已选的训练帧（6 个训练来源组），每张审 11 个局部字段。
- 在其中 5 个训练种子帧附近，按固定 ±0.8 秒、每秒 5 帧额外解码 45 张原生 2560×1440 帧（来自 4 个来源组，其中 18 张来自最近授权的一段训练录像；有 2 张与种子帧像素完全相同）。这些重复是有意的，不算额外的独立对局。
- 87 张帧共 957 个声明位置，其中包括“看不清”和“面板不存在”的位置，不是 957 个可读真值。
- 参考由助手看原生像素放大图标注（辅助标注），不是独立的人工盲审。冻结的测试来源和评估分组没有打开或改动。
方法
审查。 对每个位置区分四种情况：完整可读、只看得到一部分、面板上不存在、无法判断。绝不从相邻帧抄数字。算法草稿和助手像素参考分开存放。
新裁框试验。 审查发现有一处数量 203/295 被读成 203/29，原因是原来 111 像素宽的固定裁框切掉了最后一个“5”；还有标题被重叠的回合横幅干扰。于是只在训练数据上冻结一个诊断方案：数量裁框改为 [690,290,900,328]（去掉左侧金色单位图标、允许更长的数字对），标题裁框改为 [1000,247,1560,283]（避开重叠的横幅线条、保留标题下半带）。把它应用到两个训练清单里所有自动检测到的标题/数量字段，用同样的两尺度 OCR 和 0.90 一致性门槛，与保存的旧基线比较。推理脚本不读参考答案。
设置
OCR 引擎、两尺度一致性规则都不变，不新增依赖。这是裁图诊断，不是整图运行耗时。
结果
审查结果：
| 范围 | 完整可读 | 读对 | 读错 | 拒识 | 漏读 | 无法判断完整值 | 不存在 |
|---|---|---|---|---|---|---|---|
| 42 张原训练帧 | 428 | 382 | 3 | 23 | 20 | 34 | 0 |
| 45 张邻近帧 | 266 | 186 | 2 | 24 | 54 | 75 | 154 |
109 个无法判断的完整值全部不给答案；154 个“不存在”位置对应 14 张画面中央没有生物面板的帧，且没有产生错误请求。
新发现的 5 个被错误接受的读数：
| 位置 | 正确值 → 读出值 | 原因 |
|---|---|---|
| 攻击 | 32 → 432 | 背景里一个小“14”与前景“32”重叠 |
| 攻击 | 17 → 9517 | 背景“295”与前景“17”拼在一起 |
| 幸运 | 1 → 71 | 背景“97”与前景“1”拼在一起 |
| 数量 | 203/295 → 203/29 | 111 像素裁框切掉最后的“5” |
| 标题 | 无心死神 → 无心神 | 重叠的回合横幅；助手仍能读出 4 个字，OCR 高分丢了“死” |
全部 45 张邻近帧都完成了整图预测，读取失败 0 次。
失败与负结果
新裁框被拒绝：
| 范围（标题/数量） | 原方案 读对/读错/拒识 | 试验方案 读对/读错/拒识 |
|---|---|---|
| 原训练帧 | 73 / 0 / 4 | 70 / 1 / 6 |
| 邻近帧 | 42 / 2 / 1 | 35 / 7 / 3 |
试验救回了两处淡出的“原始残骸”标题和那个“无心死神”过渡帧，但在多张清晰的“无心死神”帧上新漏了“死”，还拒掉了两个清晰的天使标题。加宽的数量带不再输出 203/29，却也拒掉了其他读对的数量对，并没有恢复出正确的完整数量。合计读对 115→105、读错 2→8。因此该方案被拒绝，没有用在校准或最新来源上，也没有改动任何默认或运行时路径。
简单地“两种裁框一致才接受”也会拒掉清晰标题，因为第二种视角本身不可靠，不能把这种损失包装成更好的识别。
其他记录在案的问题：一次 OpenCV 定位在报告时长内失败，保留 27 张已完成帧，其余 18 张改用 FFmpeg 按原始时间戳解码；前 27 张的时间戳只能从文件名恢复到毫秒级；恢复日志的编码不匹配通过从保存的收据续跑修正。
局限
- 这 11 个字段不覆盖能力、归属、完整 UI 或完整战斗状态。
- 新增帧偏向过渡和遮挡，不是自然分布，也不能代表延迟。
- 部分透明会让面板检测器根本不发出读取请求，这些漏读仍算失败，没有从分母去掉。
- 背景数字拼接是另一个未解决的问题，不能靠“数值上限”来掩盖。
- 完整软件套件没有重跑；之前的完整套件有已知失败，不能说成全绿。逐字段 95% 准确率、严格 UI 框和独立来源验收都没有完成。
结论与下一步
更多的审查把之前没算进去的错误接受找了出来——这是审计纠正，不是本实验导致的退步。一个统一的新固定裁框解决不了问题。下一个候选应当定位真实的完整文字行/字形范围，并区分重叠的背景字形，然后在同样的负例和清晰对照上评估；避免数值上限、目录纠错、只针对最新来源的规则，也不要一刀切拒绝所有过渡帧——可读的过渡帧是有用的。
Comments