P41 · 场景识别 · 实验记录与相关篇目
P41 · 场景识别已有开发原型

保留早期缓存 OCR 的 v4 规则结果;示例分类已同步标注网站的后续审核。用户确认、助手检查与算法候选分别显示,本轮未重跑模型。

《英雄无敌:上古纪元》的竞技场会经过菜单、英雄、技能、宝物、法术和生物选择,再进入战场。许多界面已经把身份写在屏幕上:我们先用 OCR 把文字和位置读出来,再判断这些文字支持哪一种页面。

程序返回页面标签,以及支持这个判断的文字和位置。线索不足时保留未知;它要解释这一帧实际看到了什么,而不是沿用上一帧的答案。

flowchart LR
 A[Source screenshot] --> B[OCR text and boxes]
 B --> C[Text and position rules]
 C --> D[Current view and evidence]
 D --> E[Independent review]
 D --> F[Phase context with timestamps]

图 1:当前像素产生当前观测;时间上下文另列。上一次看到战场,不代表这一次也看到了战场。

1. 文字相同,还要看它在哪里

OCR 输出的是文字区域,而不是按钮检测结果。标题、说明、计时数字与按钮标签都可能被读到。我们保留原始字符串和矩形,另用规范化后的字符串匹配规则,不把 OCR 框自动扩大成可点击区域。

先走一个例子:全图 OCR 同时读到“快速开始”和“自定义游戏”,位置都在“新游戏”下方。文字组合说明出现了两个具体选项,位置关系又支持它们属于展开的新游戏菜单。因此规则提出“新游戏菜单已展开”,并保留这几处文字作为依据。展开菜单会推移下面的按钮,所以采用本帧读到的位置,不沿用未展开时的坐标。

反过来,英雄名字、等级和底部流程条会出现在多个选择页。即使这些字全部读对,仍不足以区分当前是哪种选项页面。没有明显标题的战场更难只靠文字判断;下一章会接着处理这种情况。

不知道场景,怎么先做 OCR?

第一遍 OCR 读取整张截图,不需要预先知道场景。 OCR 的文字检测网络先在图像里找文字,再由识别网络读出检测到的行。引擎内部裁出文字行,不等于我们先按“英雄页”或“技能页”裁固定区域:前者从当前像素自动定位,后者需要已经成立的场景和布局假设。

步骤 输入与已知条件 输出
P41 整屏第一遍 完整截图;没有场景标签或游戏标题框 全图文字、坐标及场景规则候选
P41 视觉补充 同一截图;OCR 证据不足或冲突 已有颜色/边缘近邻、SVM 与 OCR 的离线交叉核对;任意新视频的在线完整路由仍待验收
P101 场景内细读 已确认或预测的场景、兼容布局、可见区域 标题—图标关联与目录身份建议
P61 历史标题小图实验 实验已提供的标题条;不负责识别场景或选择区域 小裁图上的文字与耗时;后来的整屏比较见 p61,输入与分母不同

完整截图先经 OCR 自动检测及裁行,再识别场景,最后选择游戏固定标题区域。未知或布局不相容时停止局部提交。

图 2:A 是原始输入,B 是 OCR 自己定位的文字行,C 才是具有游戏语义的固定区域。B 不需要场景标签,C 需要。图示为整合流程合同,下面的截图才是实际开发预测。

这条依赖是“全图文字 → 场景 → 局部细读”,没有用局部裁图的答案来证明它自己的前提。比如先在全图检测到“快速开始”和“自定义游戏”,再判断新游戏菜单展开;不必先假设展开菜单的坐标。技能页中通用的英雄卡和流程条不足以确定主技能或子技能时,就应保留不确定性,不能凭某个预设槽位读到一个合法技能名便接受整个场景。

当前 B021 的全图识别和 B023 的离线关联原型分别存在;上述自动路由与拒识策略是整合合同,尚未完成端到端评估。实际系统应优先复用已有全图文字,只有小字漏读或低质量时才精读局部。上一帧标签可帮助安排计算,但切出游戏、换页或断线后不能直接沿用旧标签认证新裁图。

固定区域只是位置提示;归一化坐标能处理同布局分辨率变化,不能保证应对任意宽高比或改版。

主技能和子技能属于同一顶层阶段。前者的三个选项标题与后者的父技能标题加三个子技能位置不同;规则用文字组合和布局区分它们。英雄名字、等级和底部流程条则会出现在多个选择页,单独命中它们不能决定当前子场景。

规则可以要求多个锚点、排除矛盾文字,并用显式优先级处理匹配。冲突或证据不足时拒绝分类。优先级是程序规则,不是概率。英雄信息、战斗日志和悬浮提示还需要保留基础场景;浮层名称不能取代完整的状态描述。

下面的历史实验使用已保存的高精度 OCR 结果:PP-OCRv6 全帧原图与 1.5 倍增强结果融合,再运行 ocr-scene-understanding.v4。初期 Windows OCR 与 v1 规则是另一轮记录;后来视觉交叉核对和标注修正见下一章。本文保留各轮自己的计数,不把后来的修正算成旧规则的成绩。

2. 打开类别,对照原图、文字和后续分类

下面的原图最初按每种规则输出、每段录屏各取一张时间中位帧;现在按标注网站的分类分组,方便先认清图片。青框仍是历史规则采用的文字,旧预测可在每张图下展开查看。分类旁明确写出用户确认、助手检查或算法候选,不能把三者都当成人工真值。

3. 有多少数据,能报告什么指标?

这轮历史实验覆盖了 19 种规则命中的画面标签。它们包含基础页面、浮层和过渡,并不是 19 个顶层阶段。两段录屏各有 320 张关键帧;当时的规则给 467 张提供标签,173 张保持 UNKNOWN。467/640 = 73.0% 是当时的覆盖率,不能读作准确率,也不是今天仍待处理的数量。这批场景实验与 p61 的整屏 OCR 选型分别计分。

历史 v1 规则在同一关键帧集合上得到 431 个标签、209 个未知;这轮 v4 重算为 467 和 173。版本、OCR 路径与规则都发生过变化,因此差额不能归因于单个算法改进,也没有证明增加的标签都正确。

历史 v4 规则输出帧数
ARTIFACT_SELECTION35
BATTLE_ACTIVE24
BATTLE_FINAL_CONFIRMATION12
BATTLE_LOG44
BATTLE_PREPARATION35
CREATURE_INFO22
CREATURE_SELECTION17
GAME_SETUP13
HERO_INFO10
HERO_SELECTION10
MAIN_MENU10
MAIN_SKILL_SELECTION65
MULTIPLAYER_MENU40
NEW_GAME_MENU12
PAUSE_MENU4
SPELL_SELECTION35
SUBSKILL_SELECTION59
TOOLTIP15
TRANSITION5
UNKNOWN173
当时的审核集合(历史快照) 数量 可以支持的结论
两段开发录屏的关键帧 640 观察规则覆盖与失败形态
人工确认 1 不能估计各类准确率
当时尚待确认 639 旧草稿状态,不代表现在的待办
按录屏、预测、参考草稿和画面条件选出的代表帧 45 首轮定位标签与规则问题;不是随机测试集

项目另有 562 条较早的场景参考记录:456 条来自已审核可用目标的布局,102 条是旧阶段参考,4 条明确是助手草稿。它们可帮助构建训练/开发资料,但目标图标被审核过,不等于同一帧的场景、浮层和就绪程度也经过独立审核。还需检查旧类名、来源与开发数据重叠。

不同方法应在同一份、按完整视频划分的冻结参考集上比较:文字规则、文字加位置、图像模板、组合路由。分别报告顶层/子类/浮层准确率、每类召回率、拒识率、错误接受率。当前没有满足这些条件的完整对照结果;此处不填一个看似精确的数字。

全图速度也不同于标题条速度。历史 Windows 全图批次约 135.5/136.0 ms 每帧,包含启动与布局处理;该 v1 回执因后续旋转框投影失败被标记为 partial。修正投影后的数值不是新一次 OCR 速度。PP-OCRv6 双通道全图批次约 657.8/597.6 ms 每源帧。它们均不是常驻服务 p50/p95;小标题的独立速度对照见 B024。

4. 在标注网站抽查,再用新录像验证

早期审核从 45 张代表帧和 173 张 OCR 未识别帧开始。后续已经做了 B022 的全库交叉核对,不需要按旧数字重新审核一遍。现在打开本机场景分类网站,可按场景或录屏抽查;每张博客示例也能直接跳到对应记录。此链接只在运行了本地标注服务的电脑上可用。

检查时先回答当前看到了什么,再判断是否有浮层、过渡、遮挡或非游戏画面。加载页应标为加载;OCR 没读出字不等于 UNKNOWN。空技能页如果处于翻页,标为过渡或内容未就绪,不再使用已撤销的“英雄技能总览”。

两个演示录屏已经影响过规则设计,确认后仍属于开发评估数据。下一份真正的测试集要从其他完整录屏中冻结,并且在调参前确定参考。连续窗口另用于检查错误前进、重置、延迟和过期上下文;一张帧的分类准确,并不能认证 state tracking。

复现入口:项目 B020 的 prepare_evidence_review.py 重用缓存和原图;其 --refresh-reviews-only 只同步博客分类,--check-reviews 检查是否落后于标注网站。历史计数仍保存在 evidence-inventory.json。浏览器标注仍写入原有带修订版本的审核存储,本文没有将预测提升为训练真值。