摘要
上一个实验（P033）已经能从单张截图里定位战斗日志并读出每一行，但“玩家”字段很差：最新开发组里只有 47/136 条事件的玩家名读对。原因是游戏里玩家显示名的前面有几个字体缺字时显示成的空心方框（□），OCR 往往把它们漏掉。
本实验在日志面板的原始像素上直接找这些方框：用亮度轮廓识别近似正方形的空心框，用颜色判断玩家名从哪里开始（紧跟在中性色的时间戳之后）。找到的方框作为一个单独的候选显示名输出，原始 OCR 文字和解析结果完全不变。最新开发组玩家字段一致提高到 131/136（96.3%），时钟 + 玩家 + 正文全对 129/136（94.9%）；在已审核的观察中没有新增错误，也没有改坏原来读对的玩家名。
注意：一个“□”只说明屏幕上画了一个方框，无法还原原本是什么 Unicode 字符，也无法说明这是哪位玩家、属于哪一方。
要回答的问题
能否只靠像素，把 OCR 漏掉的玩家名前缀方框补回来，同时不产生错误的补充、不改坏原来读对的结果？
数据与来源
- 复用 P033 的 22 张已审核日志页、472 条可见事件和相同的数据分组：训练 / 诊断、校准、最新开发组（同一次录像会话的 5 场战斗，是已暴露的开发组，不是盲测）。
- 只用训练和校准数据调参；最新组在方法定下之前不看。
- 没有打开项目冻结的测试素材，没有训练模型、没有下载。
- 名字重复出现很多次，重复的事件观察不是独立的身份样本，也不是广泛的用户名测试。
方法
先由助手目视检查 13 张训练集的玩家名前缀裁图，确认：确实是三个空心方框，玩家名有蓝色和金色两种颜色；另有一个名字里的波浪符号被 OCR 读成了别的变音符号（这是另一种错误，单独保留）。
最终方法（部署在 perception 模块的一个小助手函数里）：
- 在时间戳之后约 100–240 像素宽的原生区域里，取亮度大于 85 的轮廓。
- 合格的方框：内部空洞 11–16 像素、接近正方形、矩形度 ≥0.90、彼此连续（间隔 0–5 像素、基线差 ≤2 像素）。
- 玩家名颜色（色度 >35）用来确定方框位于时间戳之后、前面没有其他彩色字母；方框后面剩下的宽度必须放得下 OCR 已读出的后缀。
- 方框个数按实际观察到的形状计数，不预设“一定是三个”，也不查已知玩家名单。形状或个数不清楚、后缀放不下时就弃权。
这个功能需要显式开启；默认关闭时行为与 P033 完全相同。它在已有的 OCR 子进程里、对 OCR 读过的同一份像素运行。
设置
| 项目 | 设置 |
|---|---|
| 输入 | 原生 2560×1440 截图，130 张（含 108 张非日志对照） |
| 基线 | P033 的原始 OCR 玩家字段 |
| 计时范围 | 图像解码、界面识别、进程通信与 OCR、字形读取、JSON 输出 |
结果
| 数据组 | P033 原始玩家一致 | 本实验候选玩家一致 | 三字段全对 | 正文完全一致 | 含数字行全对 |
|---|---|---|---|---|---|
| 训练 / 诊断 | 120/269 | 252/269 | 249/269 | 263/269 | 226/229 |
| 校准 | 33/67 | 67/67 | 66/67 | 66/67 | 61/61 |
| 最新开发组 | 47/136 | 131/136（96.3%） | 129/136（94.9%） | 134/136 | 117/117 |
完整的 130 张实际运行与先前在保存的 OCR 上重放的结果一致：训练补回 132 个前缀、校准 34 个、最新组 84 个；已审核观察中错误补充为 0，原本读对的玩家名被改坏也是 0。130 张图的原始界面输出、原始 OCR 行和原事件字段与 P033 完全相同；108 张非日志图没有触发日志 OCR。
助手目视检查了最新组补回的全部 84 张前缀裁图（都是三个空心方框加后面的名字）和 5 张没补回的裁图（其实也有三个方框，但算法认为轮廓证据不完整而弃权）。这是看着候选结果做的检查，不是盲审，也不是人工审核。
速度（预热后）：
| 范围 | p95 | 最大 |
|---|---|---|
| 最新组 71 张整图 | 0.925 秒 | 1.126 秒 |
| 最新组 5 张日志 | 0.544 秒 | 0.565 秒 |
冷启动：界面 2.883 秒、OCR 子进程与加载 4.687 秒、首次预热 1.264 秒。与 P033 的速度差异可能来自缓存和环境波动，不能当作已证明的提速。
测试：界面 / 日志 / 字形专项 29 项通过（覆盖 1/2/3/4 个方框、残缺轮廓拒绝、前面有字母时拒绝、原文与解析不变）；Perception 全套 7,191 通过、6 跳过、2 个既有导入顺序失败（同前几个实验）。
失败与负结果
被否决的配方（结果都保留）：
- 颜色掩膜找封闭空洞：漏掉了金色方框的轮廓；再加 3×3 闭运算也不可靠，还会扭曲普通拉丁字母的空洞。
- 第一次亮度轮廓：训练补回 126/136、校准 34/34，0 个错误补充；但有 6 个训练前缀的三个框轮廓其实都对，只是第一笔金色太暗，色度达不到 35。
- 把颜色门槛从 35 降到 20：把时间戳的抗锯齿边缘也当成了玩家名起点，训练玩家一致从 246 掉到 205，否决。
- 最终做法：恢复 35，但允许“强颜色”出现在第一个已检测到的方框之内（右边多留 2 像素），同时仍拒绝方框之前的彩色字母。训练一致变为 252、校准 67。这一配方在看最新组之前固定。
仍然存在的错误：
- 最新组还有 5 个前缀没有候选（分布在两场战斗的 5 行）；没有为了它们去调参。
- 最新组正文的两处错误仍在：“狮鹫”读成“狮鹭”、“死亡单位”丢了“位”。
- 训练组：4 个不完整的前缀检测、10 次波浪符号读成别的变音符号（复核过，确实是 OCR 错，不是标注错）、半透明面板里 3 条事件没检测到。
局限
- 只支持原生 2560×1440；用户名种类少、重复多；遮挡和更多字体没有覆盖。
- 最新组三字段全对 94.9%，仍低于项目 95% 的目标，整体目标没有达成。
- 候选显示名不能用来判断真实玩家或阵营。
- 没有接入战斗记录 App、状态估计、规则模拟器或 AI。
结论与下一步
纯像素的方框检测在不改动原始 OCR 的前提下，把玩家字段从明显不可用提到了接近目标；它以“弃权”而不是“猜测”处理不确定的情况。下一步优先在同一路径里读英雄、生物、HUD 上的数字；训练集里难读的前缀、非方框的变音符号、更小的界面元素和独立来源覆盖仍待解决。
Comments