摘要
OCR（光学字符识别）是把图片里的文字读成字符串的程序。在《英雄无敌：上古纪元》的画面里，要读的既有选秀界面上“剑士”“弩兵”这样的生物名称小标题，也有战场上大量的小数字：单位脚下的数量牌、英雄属性、时钟、魔法书角标等。
本实验（编号 B024）分三步：
- 9 月 6 日，小标题故障诊断：旧流程读错的 6 个标题，换三种 OCR 引擎能否读对？PP-OCRv6 在原图上 6/6，Windows OCR 与 EasyOCR 各错 1 个。同时发现：三种引擎都会把一个“图像不是有效目标、但文字恰好是生物名”的裁图读成生物名并命中词典，说明光靠 OCR 不能决定接受与否。
- 9 月 10 日，整屏选型与批量扫描：24 张原图、1,018 个参考字段上比较 10 种配置，选中
paddle-fused-guarded（972/1,018 完整读回），随后用它扫描了 513 张已有关键帧。 - 9 月 12 日，小字诊断：在“人工给出文字框”的条件下，更强的 PaddleOCR-VL-1.6 在 203 个困难区域读对 195 个；但自动整屏流程的主要缺口在“找到文字在哪”，改用更小切块并加 VL 数字复读后，自动流程到 984/1,018。
所有参考答案都由助手看图转写、待用户确认，数据参与了算法选择，因此这些数字是开发集成绩，不是独立测试准确率。
要回答的问题
- 旧标题流程读错的那些字，换一种 OCR 能否读对？OCR 读对是否就足以接受？
- 对整屏截图，哪种 OCR 配置在数字和文字上读回最完整？
- 读不对的小字，问题在“识别器认不出”还是“没找到文字框”？
数据与来源
| 阶段 | 数据 | 说明 |
|---|---|---|
| 小标题诊断 | 11 个标题裁图：6 个清楚可读但旧流程读错、1 个被悬浮说明遮挡、4 个负样本 | 6 个可读裁图只有 4 种不同文字（“日矛圣骑兵”出现 3 次，其中 2 次来自同一录屏）；是已知失败的探索集，不是事先冻结的测试集 |
| 整屏选型 | 24 张 2560×1440 原图，15 段录像；1,040 个区域，其中 1,018 个可评分（939 纯数字、79 文字），8 个遮挡忽略，14 个装饰负例 | 后 9 张来自同一视频；参考由助手逐图转写，在看预测之前完成 |
| 小字诊断 | 上述 24 张 + 2 张状态悬浮图，共 1,046 区域 | 另冻结一个 217 区域的“挑战集”（203 个有字），包含旧流程全部 46 个失败 |
| 批量扫描 | 513 张已有关键帧，31 个视频标识 | 31 是标识数，不是独立录像数；其中 318 张来自同一来源组 |
“旧流程”指历史上的固定标题框流程：裁出标题条，三倍放大加边框，交给 Windows 系统 OCR，读不出再用对比度增强版重试。
方法
三种引擎
- Windows OCR：系统内置，本地运行；对原图、4 倍放大、4 倍对比度增强、4 倍二值化四个版本各读一次。没有可用的置信度。
- PP-OCRv6 medium：PaddleOCR 的检测 + 识别模型，GPU 运行，原图和 3 倍对比度增强各读一次，输出模型分数。
- EasyOCR：另一个模型族（CRAFT 检测 + CRNN 识别，beam search 解码），CPU 运行，用来检查 PaddleOCR 的成功是不是同类模型的偏差。
比较时分别统计“只看原图”“只看增强版”“生产选择”（优先选能精确命中生物名称的版本）和“任一版本命中”，避免把词典帮忙挑答案的效果算到 OCR 头上。文字比较前做 Unicode 规范化、大小写折叠、去标点和繁转简。
整屏配置
整屏的难点是一张图里有几百处小字。比较了 10 种配置：Windows 和 EasyOCR 的整图/整图+切块，PaddleOCR 的原双遍整图、高分辨率整图、2 倍切块、密集切块，以及两种“整图优先、切块补缺”的组合。切块（tile）是把整屏分成重叠的小块分别放大识别，能找回小字，但也会切断长句、引入血条和装饰的噪声。
最后胜出的 paddle-fused-guarded：PP-OCRv6 原图 + 1.5 倍对比度增强，再加 9 个重叠块的 2 倍彩色和 3 倍增强；整图读数优先，并在它们周围留出“保护区域”（左右一倍字高、上下半倍字高），切块候选分数至少 0.8 才补进来。
小字诊断
把“找字”和“认字”分开：
- recognition-only：直接把人工框裁图交给识别器（不给答案），看识别器本身能不能认；这个成绩不能当成自动整屏准确率。
- PaddleOCR-VL-1.6：一种视觉语言模型（能看图并按提示词输出文字），本地运行，提示词
OCR:，greedy 解码。 - 自动对照：切块从 960×640 缩小到 480×320；再把自动流程选中的 901 个数字框外扩 2 像素交给 VL 复读，VL 完整返回数字格式才采用。事后又加一条规则：新旧读数的分隔符序列（
/ : . % -）必须相同，否则不覆盖。
设置
- 硬件：Ryzen 9 9900X / RTX 5080 16GB；全部本地推理，截图不上传。
- 时间只记录，不参与选型。
- 推理只读原图和固定配置，不读参考框、答案或场景标签。
- 失败、截断、未处理（PENDING）不当成空字符串算成功。
结果
小标题：OCR 读得对，但不能单独决定接受
| 引擎 | 原图 | 仅增强 | 生产选择 | 任一版本 |
|---|---|---|---|---|
| PP-OCRv6 medium | 6/6 | 6/6 | 6/6 | 6/6 |
| Windows OCR + 固定预处理 | 4/6 | 5/6 | 5/6 | 5/6 |
| EasyOCR | 5/6 | 5/6 | 5/6 | 5/6 |
Windows 把“虔信者”读成“信者”，EasyOCR 把“剑士”读成“剑”。PP-OCRv6 还正确读出了错误路由裁图里的“绝望/狂暴/顺风”法术文字——读对了，但这些裁图本就不该当生物标题。更关键的是，三种引擎都把用户确认无效的一个裁图读成“深渊监管者”并命中词典（PP-OCRv6 分数 0.9998）。因此建议的生产顺序是：场景与布局检查 → 裁图可用性/遮挡检查 → 标题 OCR → 词典 → 标题与图像的空间关联 → 图像候选 → 时序复核。
常驻运行（模型已加载）时整批 11 个标题的端到端吞吐：PP-OCRv6 GPU 15.24 个/秒，Windows 11.36 个/秒，EasyOCR CPU 2.53 个/秒。这是各自程序配置的收据，不是同条件的框架排名。
整屏选型
| 配置 | 数字完整读对 /939 | 文字完整读对 /79 | 数字漏检 | 数字读错 |
|---|---|---|---|---|
| Windows 整图 | 212 | 35 | 611 | 116 |
| EasyOCR 整图 + 切块 | 736 | 39 | 125 | 78 |
| Paddle 原整图双遍 | 876 | 74 | 57 | 6 |
| Paddle 密集切块 | 874 | 50 | 25 | 40 |
| Paddle 整图优先补缺 | 881 | 74 | 28 | 30 |
| Paddle 带保护区域补缺 | 898 | 74 | 32 | 9 |
（表中省略了几种中间配置，完整 10 种见原报告。）胜出配置合计 972/1,018 完整读回：数量牌 215/225、行动条数量 231/240、时钟 79/82、英雄 HUD 152/152、魔法书数字角标 95/111、日志 41/46、悬浮说明 23/23。这是“参考框内字段能否读回”，不是全图检测 precision；14 个装饰负例上没有数字错报，但这不足以估计全图误检率。
批量扫描
固定该配置扫描 513 张已有关键帧：513/513 完成、0 失败，得到 22,761 条选中读数（连同备选 53,063 条）。“完成”只表示流程跑完，不表示字都读对；整帧语义标注完成数仍为 0。
小字：认字能力够，找字是主要缺口
人工框条件下（203 个有字挑战区域）：
| 识别器 | 原裁图精确 | 4 倍放大 + 补边 |
|---|---|---|
| PP-OCRv6 medium（跳过检测） | 188/203 | 173/203 |
| PaddleOCR-VL-1.6 | 195/203 | 190/203 |
4 倍放大反而更差。原裁图分支在 14 个装饰负例上分别多输出了 7 个和 3 个数字——识别器不会判断“这里有没有字”，对任意小块都会强行读。
自动整屏流程（不用人工框）：
| 自动流程 | 精确字段 | 补回旧 46 个错误 | 损坏旧 972 个正确 |
|---|---|---|---|
| 旧整屏融合 | 972/1,018 | 0 | 0 |
| 更小切块 | 983/1,018 | 12 | 1 |
| 小块 + VL 复读 901 个数字框 | 983/1,018 | 13 | 2 |
| 再加分隔符一致规则 | 984/1,018 | 13 | 1 |
纯数字 898 → 910/939，文字 74/79 不变；仍有 29 个数字、5 个文字字段没有读回。
失败与负结果
- 三种引擎都会接受一个文字是生物名、但图像无效的裁图。
- 密集切块破坏长句（文字 74 → 50），并带来血条、装饰的噪声。
- 4 倍放大在两种识别器上都更差。
- VL 复读会“修正”出错：把正确的
215改成2.15；也会把被截断的时钟03:4补成03:47。分隔符规则是看到这些后才加的开发规则，它也可能挡住某些正确修复。 - 小切块把数量 4 读成带多余“二”的结果，是新组合的一个回归。
- 一次外部审阅指出早期“6/6”混合了 OCR 与词典挑选、计时口径不一致，随后补了四种口径并重测计时。
- VL 首次适配因接口变化和漏下载模板文件失败，失败日志保留，修复后才评分。
局限
- 所有参考都是助手转写、待用户确认，且参与了算法选择；没有独立留出集。
- 小标题集只有 6 个可读样本、4 种文字，只能做故障诊断。
- 整屏只评估了参考框内的字段，没有全图负标注，不能报告 precision。
- 新组合（984/1,018）尚未在新录像上验证，默认扫描配置没有替换。
- 只测了 PP-OCRv6 和 PaddleOCR-VL-1.6 两个较新的模型族，不能宣称穷尽了最先进方法。
结论与下一步
在本游戏的开发集上，PP-OCRv6 系列明显优于 Windows OCR 和 EasyOCR；更强的 VL 模型在“已知文字位置”时读得更好，但自动流程的主要瓶颈是定位：漏检、截断和相邻候选合并。OCR 读对也不等于可以接受，必须先有场景、可见性和裁图有效性的检查。
下一步：处理小切块的漏检与截断，冻结一组来自新录像、按视频分开的验证集（报告中建议 100–300 个标题机会，含可读、困难和无效输入），再决定是否替换默认配置。
Comments