摘要

战斗画面顶部左右各有一个英雄头像框，显示双方英雄。项目的头像读取器先拿截图里的头像去比对一个样例库（已审核过的局内 HUD 头像裁图），比不上再去比对游戏资料库里的英雄原画，并用颜色布局做一致性检查。之前的测试中，剩下认不出来的头像全都是样例库里没有的英雄。

本实验去训练录像里找更多英雄，导出候选样例（不直接进入正式资源），并只在训练数据上做“留一局”评估。结果分两阶段：

  1. 两份冻结划分里的 13 个训练录像（15 局）没有新英雄，双方 23 个英雄都已在库中。
  2. 用户允许使用更早的自录录屏后，在 12 个准入的旧录屏里找到 28 局，测试缺失的 8 个英雄找到 5 个，另有 12 个库外英雄和 8 个已知英雄的新屏幕侧。共导出 39 张候选，覆盖 27 个英雄，与现有库合计 40 个英雄（原来 23 个）。

训练侧留一局评估 1,991 张裁图：0 个认错，未知从 152 降到 69。

要回答的问题

训练录像（以及用户允许的更早录屏）里，能否找到样例库缺失的英雄，并做出可用的候选样例？加入它们后，读取器会不会把某个英雄认成别人？

数据与来源

  • 第一阶段：只用两份冻结划分中标为“训练”的 13 个录像。不打开留出测试和开发验证录像，也不读名字带“测试”的截图包。
  • 第二阶段（用户新指示后）：用户允许使用更早的自录录屏，范围限定为一份既有清单中的 21 个用户竞技场录像，加 3 个已登记为训练的历史录像。仍排除九月的留出录像、十月的留出测试和开发验证录像、带“测试”的截图包；清单外的其他九月录屏没有打开。
    • 只有 2560×1440 的录像能裁出原生大小的头像框，准入 12 个（9 个来自清单、3 个历史训练录像）。
    • 12 个 1920×1078/1080 的旧录像，头像框位置和尺寸不同，记录后跳过。
  • 标注：由助手目视复核，不是独立人工真值。

方法

第一阶段：

  1. 按已有的每秒 5 帧场景扫描切分对局：战场场景之间出现选英雄、匹配、网络验证或超过 30 秒空档，就算新的一局；记录开战前的最终确认面板。
  2. 每局取确认面板、最多 6 个英雄信息面板、最多 40 个 HUD 场景的中点帧，保存左右头像框的原生裁图（194×226）。解码用 FFmpeg 精确跳转并记录真实时间戳——录像是可变帧率，用 OpenCV 按毫秒跳转会偏几十秒（例如请求第 318 秒的确认面板，却拿到了第 2 回合的战场），所以那一版采样作废。
  3. 目视复核：我方英雄看确认面板上的名字，屏幕侧看面板顶部玩家横幅；敌方英雄把该局全部裁图与资料库原画并排逐张比对。看不到头像的裁图（开局渐入、全屏面板）排除；变暗、部分被提示框挡住的帧保留为难例。
  4. 样例库每个（英雄, 屏幕侧）只取了第一局。凡是库里还没有的（英雄, 侧, 局），就导出一张候选。

第二阶段：

  1. 版式检查：用样例库同侧裁图里颜色稳定的边框像素做掩码，计算裁图与库中位图的平均绝对差（下称“边框距离”）。训练集有效裁图中位数 4–6、p99 ≤9.3；无头像 / 全屏面板为 22–44。阈值定为 15，超过的帧不提议、不选作样例。
  2. 定位对局：有场景时间线的录像按其战斗阶段定位；没有时间线的每 8 秒取一帧，两侧都通过版式检查就算战场，间隔 >90 秒分局、跨度 ≥60 秒算一局。每局等距取 10 张裁图。生产读取器给出的提议只用于排序比对，不当标签。
  3. 目视复核：每局全部裁图与提议英雄的原画并排；不在提议里的英雄，对照六个阵营的全部原画识别。我方侧看顶部计时器旁的用户头像或等待界面的玩家横幅。
  4. 导出：凡（英雄, 侧）不在正式库和第一阶段候选中，每局取一张与其余裁图平均相似度（NCC，归一化互相关）最高的裁图。

评估（只在训练侧做“留一局”）： 读取器设置与生产一致（最低分 0.52、领先差 0.03、样例最低分 0.62、开启一致性检查）。评估某一局时，隐藏这一局自己的样例。比较“现有库”和“现有库 + 候选”。测试集和新鲜数据划分不运行，由协调者集成后统一跑一次。

设置

每张裁图记为正确 / 拒判（未知）/ 错误，按我方 / 敌方分开。同一局的多帧是同一英雄的重复观察，不是独立样本；独立单位只有训练 15 局 + 旧录屏 28 局。

结果

第一阶段： 15 局里 14 局我方英雄名读自确认面板，1 局从战斗中途开始，用英雄信息面板。30/30 个英雄与之前的对局真值记录一致（同样是助手复核）。采样 579 帧、1,158 张裁图，排除 3 张无头像的。只导出 3 张候选（已知英雄的新局 / 新侧）。

版式检查： 准入旧录屏每侧 280 帧的边框距离：左侧中位 6.1、p95 9.2；右侧 3.5、6.1，与训练录像（左 5.7、右 4.2）一致，说明 8 月 22 日起的旧版本 HUD 框与现行一致。超过阈值的只有一局里的 4 帧变暗画面，保留为观察但不选作样例。

第二阶段 28 局： 找到的测试缺失英雄为黑角（3 局）、埃斯里克（3 局）、维斯珀（2 局）、朽拉（2 局，左右各 1）、蕾亚（1 局）。11 局的确认面板截到了英雄名，全部与目视标签一致，其余局只有目视比对。

候选样例： 旧录屏新增 36 张（目标英雄 11 张、库外新英雄 14 张、已知英雄新屏幕侧 11 张），加第一阶段 3 张，共 39 张。

留一局评估：

数据 角色 现有库 正确 / 未知 / 错误 仅加第一阶段 3 张 现有库 + 39 张候选
训练截图包（276） 我方 138 123 / 15 / 0 123 / 15 / 0 128 / 10 / 0
训练截图包 敌方 138 138 / 0 / 0 138 / 0 / 0 138 / 0 / 0
训练录像采样（1,155） 我方 577 520 / 57 / 0 520 / 57 / 0 538 / 39 / 0
训练录像采样 敌方 578 578 / 0 / 0 578 / 0 / 0 578 / 0 / 0
旧录屏（560） 我方 280 250 / 30 / 0 — 280 / 0 / 0
旧录屏 敌方 280 230 / 50 / 0 — 260 / 20 / 0

变化来源：黑角、埃斯里克各 30 张旧录屏裁图从未知变正确（靠同侧其他局的样例）；训练录像里一位英雄的左侧 23 张靠旧录屏的右侧样例变正确；维斯珀、朽拉原本靠原画识别，现在改走样例路径。剩余的未知都是只出现一局的英雄（留一局时它唯一的样例被隐藏）：训练里的哈隆 49 张、旧录屏的冰后赫尔嘉特 10 张、铁宗主 10 张。其他单局新英雄在隐藏样例时仍由原画路径认对。

加入 39 张候选后没有任何裁图被误认成别的英雄。平均每张耗时 0.34 秒降到 0.18 秒（更多裁图在样例路径就结束），这不是延迟验收。

附带检查：训练录像里的选英雄卡片（15 帧、45 张卡片）读到 30 个不同英雄名，其中 16 个不在库中，但测试缺失的 8 个英雄一个都没出现；卡片不是 HUD 框，不作样例。

失败与负结果

  • 第一阶段没有找到任何新英雄。
  • 8 个目标英雄中 3 个仍然缺失：修女凯莉、艾莉妮尔、自觉者索兰在准入来源中都没有出现。可能的来源是跳过的 12 个低分辨率旧录像（本实验没看里面有哪些英雄）、未纳入范围的九月录屏（部分是验收保留池），或以后的新录像。
  • 用 OpenCV 跳转的采样版本因可变帧率偏移而作废，保留不用。
  • 4 帧变暗画面版式检查不通过；1920 分辨率录像的缩放版式没有研究。

局限

  • 标注是助手目视复核，不是独立人工真值；只有 11 局有确认面板名字作佐证。
  • 评估只在训练侧留一局，没有跑测试集和新鲜数据；同局帧不独立。
  • 只出现一局的英雄在留一局评估里等价于“库外英雄”，这是训练侧唯一能观察到的误配风险。

结论与下一步

更早的录屏确实能补上一部分缺失英雄，而且在训练侧没有引入误认。但是否扩大录像范围、是否把 39 张候选并入正式头像资源，需要用户或协调者决定；并入时清单里的来源说明需要更新，旧录屏候选的来源写的是“录像 @ 秒”而不是图片路径，严格的消费者可能需要另议。