摘要
说明：这个实验目录里没有书面报告，只有一个脚本和一份冻结配置。本文是根据脚本、配置和它保存的结果文件补记的。
战斗画面左右上角各有一个英雄头像（HUD 头像），外面一圈装饰边框、下方有职业徽章。当时的读取器把整块头像区域（加少量留白）与 77 位英雄的原画库做多尺度匹配，最高分 ≥0.75 且领先第二名 ≥0.08 才接受。在两局实战截图里，右侧敌方英雄都没被认出来。
一个自然的猜测是：边框和徽章干扰了匹配。于是本实验只取头像内圈的一个方块（去掉约 8 像素的边框、截在徽章上方），其他一切不变，重新排序。结果是纯负的：两个敌方英雄仍然没认出来，原本认对的 4 个对照里有 3 个掉到门槛以下，而且所有对照的分数和领先幅度都下降了。
要回答的问题
只把头像裁剪改成“内圈方块”，能否让原本认不出的敌方英雄被认出，同时不损害原本认对的头像？
数据与来源
- 两局实战的 Battle Notes 会话各一张战场截图（10 月 5 日的诊断运行），右侧敌方英雄有开发参考身份。
- 一张 10 月 2 日旧截图包里的开局截图（420 秒），左右两侧作为对照。
- 两张新截图的左侧（我方）头像作为对照。
- 合计：2 个“原本没认出”的敌方头像，4 个“原本认对”的对照头像。
方法
配置在排序前冻结：
- 原生头像区域 194×226 像素（左框从 x=25、右框从 x=2341 开始，y 20–246）。
- 内圈方块：在头像区域内取 [8,8]–[186,186]，即 178×178。依据是可见边框宽度约 8 像素、徽章约从 y=196 开始；这个方块并不能去掉所有弧形边框像素。
- 不加额外遮罩、翻转、旋转或其他变体。
- 匹配器的 5 种尺度（72–104）、接受门槛（分数 0.75、领先 0.08）和 77 位英雄的原画库都不变。
脚本还有严格的预算和保护：最多 8 次排序、最多解码 3 张原图、10 秒内必须完成，禁止加载神经网络库；先确认当前代码能精确复现已保存的旧结果，再跑内圈版本；所有输入文件在运行前后必须完全不变。开发参考身份只在完整排序之后才用来评分。
设置
一次运行，8 次排序、3 张原图，用时约 1.0 秒，没有调用 OCR 或神经网络模型，没有修改生产代码。
结果
两个敌方头像（原方法在保存结果里本来就被拒判）：
| 情况 | 原方法首选（分数，领先） | 内圈方块首选（分数，领先） | 参考身份被选中？ |
|---|---|---|---|
| 第 1 局右侧 | 参考英雄（0.508，领先 0.027），未过门槛 | 另一位英雄（0.525，领先 0.033），未过门槛 | 否 |
| 第 2 局右侧 | 另一位英雄（0.568，领先 0.022） | 又一位英雄（0.581，领先 0.024） | 否（两次都不在前两名） |
当前代码对两张图的原方法排序与保存结果完全一致。
4 个原本认对的对照：
| 对照 | 内圈方块首选是否仍是原身份 | 分数 | 领先 | 是否仍被接受 |
|---|---|---|---|---|
| 第 1 局左侧 | 是 | 0.453 | 0.055 | 否 |
| 第 2 局左侧 | 是 | 0.780 | 0.204 | 是 |
| 旧截图右侧 | 是 | 0.548 | 0.070 | 否 |
| 旧截图左侧 | 是 | 0.743 | 0.375 | 否（分数略低于 0.75） |
所有 4 个对照的最高分和领先幅度都比原方法下降；4 个里只有 1 个仍被接受。
失败与负结果
- 两个敌方英雄都没被认出；第 1 局的首选甚至从“正确但分数低”变成了“错误”。
- 原本认对的对照有 3/4 掉到门槛以下。
- 结论：把裁剪缩到内圈方块不是解决办法，至少对这个基于原画的模板匹配器来说是有害的。
局限
- 样本极小（2 个目标、4 个对照），只能作为诊断，不是准确率。
- 只试了一种冻结的内圈几何；没有试遮罩、其他边距或其他匹配方法。
- 原始书面报告缺失，以上解释是按脚本和保存结果补写的。
结论与下一步
“去掉边框就能认出来”的假设不成立。原画与游戏内头像之间的差异不只是边框，取景和缩放也因英雄而异。后续的头像实验转向了别的路线：先用训练局里见过的头像样例匹配，再用独立排序方法给原画匹配“投确认票”（见 P118）。
Comments