挑出值得看的帧

P22 · 视频供样 · 实验记录与相关篇目

P22 · 视频供样已运行的开发原型

96组五帧标注与连续视频原型已完成。五个短窗口中，稳定筛选保留3/7次清楚面板；固定频率补采覆盖7/7，但也带来半透明图。117张已扫描，不是全视频或独立验收成绩。

游戏里的单位即使没有行动，也会呼吸、振翅或冒火。反过来，一次重要变化可能只发生在很小的区域：鼠标指向一个技能，旁边多出几行文字，整张战场图却几乎没变。如果只按固定时间截图，就容易留下运动中间态，也容易漏掉值得读取的提示。

我们要从视频自动选出适合标注和识别的原图：同一内容持续稳定时，最多保留一个代表帧；内容改变后，再寻找新的代表帧。 短暂的文字提示也要保留。这里的输入是视频，输出是候选图片、来源时间及选择原因；识别生物、读取文字和解释伤害是后续任务。

本章从早期5fps五帧实验讲起，随后比较10fps离线补采。不要把这两个采样间隔混在一起：五张图首尾分别相隔0.8秒和0.4秒。最新三帧质量方案仍会选入半透明图，未采用；P20收尾结论有相邻帧和清楚事件的比较。这里保存历史结果，不声称稳定就等于所有UI可读。

flowchart LR
 V[Source video] --> W[Five-frame stability model]
 W --> S[Merge runs and check content changes]
 S --> R[One native representative per candidate run]
 V --> D[Offline supplemental sampling]
 D --> C[Short-event candidates]
 R --> A[Scene and element annotation]
 C --> A

图1：两条供样路径共用原视频。稳定门决定何时适合重复使用一个代表帧，不负责宣判其他时间没有重要信息。

1. 稳定，指内容稳定

在这个回合制战斗游戏里，单位占据六边形格子。下面第一组中，单位姿态改变，但落点和数量牌锚点不变；第二组中，单位真正跨格移动。我们把前者标为STILL，后者标为CHANGED。

图2：clip-63，雪地战场，3502.0秒开始。振翅不是移动。可查看第一帧原图和第五帧原图。

图3：同一来源的clip-37，3528.8秒开始。身体和数量牌一起移位，是变化样本。第一帧原图、第五帧原图。缩略拼图便于比较，原图保留2560×1440像素。

每组取5帧、5 fps，只标这五个采样点，不要求另看完整一秒。首尾相隔0.8秒，也不保证采样点之间没有更短事件。

数据批次	组数	稳定	变化	审核来源
前两批	64	24	40	用户已确认
新增批次	32	28	4	助手逐组目视审核
本轮训练合计	96	52	44	7段视频、480张原图

新增批次重点补待机动作，也含持续特效、已经打开且不再变化的提示/面板和真实变化对照。它不是32组全都没有面板的战场。原有用户标签保持不变；少数旧备注与最终标签不同，训练以最终标签为准。

STILL也不等于“所有内容都能读”。一个遮住生物的提示框可以一直不动：它对生物识别造成遮挡，对提示文字识别却正是目标。稳定性、场景类别和任务区域可读性是三个不同判断。

2. 从全图平均变化，到局部变化

第一种方法最直接：比较相邻图像的像素差，变化小就认为稳定。它运行便宜，但大面积背景和小块提示会争夺同一个分数。我们因此保留局部位置，尝试两种小模型，不在这一步使用OCR或预先提供scene标签。

方法	程序实际看到什么	怎样判断
全图帧差阈值	五张缩小后的完整截图	取相邻帧平均变化的最大值，低于阈值就接收
局部特征逻辑回归	同一输入，43个局部变化统计	学习各统计的权重，再给出稳定分数
局部特征Extra Trees	同样的43个统计	多棵随机化决策树组合不同区域的条件

三种方法都把2560×1440原图缩成320×180灰度图，做3×3平滑。只屏蔽左右上角很小的计时/头像区域，避免计时变化支配稳定判断；上方行动条和下方技能栏仍保留。完整计时读取属于另一个任务，不能因为这里屏蔽了计时，就在最终系统里丢掉它。

局部特征来自六个固定区域，包括战场内部、中央书页、左下日志、底部技能和行动条，再加8×6分块统计。既看相邻帧差，也看首尾差。例如，中央书页变化很大而底部不变，与整屏淡出产生的分布不同。这里的固定区域是宽泛的位置提示，没有使用人工文字框或生物框。

逻辑回归学习一个加权组合；Extra Trees可以表示“这个区域有变化，同时另一个区域保持不变”等组合条件。本轮后者使用200棵树、最大深度5、最小叶节点2；逻辑回归在训练折内标准化，正则参数C=0.2。两者都把变化样本的训练权重设为稳定样本的两倍。

3. 判对多少，错在什么方向？

采用按来源视频轮流留出：每轮用六段视频的样本训练，预测剩下一段。这样同一视频里的相邻窗口不会直接分到训练与留出两边。不过这七段来源都已经用于开发，模型和阈值也根据这些结果选择；尚未按独立对局和重复录像进一步隔离，因此以下不是最终独立测试成绩。

方法	判对/96	接受样本中的稳定比例	找回稳定样本的比例	动态误放行	稳定误拒绝
全图帧差阈值	86	44/46，95.65%	44/52，84.62%	2	8
局部逻辑回归，阈值0.5	88	50/56，89.29%	50/52，96.15%	6	2
局部Extra Trees，阈值0.5	89	47/49，95.92%	47/52，90.38%	2	5

“接受样本中的稳定比例”是稳定精确率；“找回稳定样本的比例”是稳定召回率。两种错误代价不同：错过一个稳定窗口，还可能等到下一帧；把变化窗口误当稳定，可能给下游错误的图标或数字。因此本轮用3×动态误放行＋稳定误拒绝选模型。3∶1是一个明确的工程假设，尚未用实际下游损失校准。

我们同时比较阈值0.5和0.8。Extra Trees在0.8时只误放行1组，但会漏掉12组稳定样本；按上述代价，0.5仍较合适。这个分数也不是“该窗口有95%概率稳定”一类经过校准的概率。

图4：clip-74是一个真实失败。变化集中在回合提示和行动范围，模型仍把它接收为稳定。另一个误放行是英雄卡片刚出现hover高亮。错误不能只用全屏看起来相似来解释掉。

原64组上，两种学习模型都判对62组；加入更难的样本后，分母和分布改变了，不能用62/64与89/96声称扩样让百分比提升。新增数据的价值，是让我们看到了更多原地动画、局部变化和稳定面板上的错误。

4. 五帧判稳，不代表长片段已经处理好

视频端按5 fps滑动取五帧窗口。连续接收的窗口合成一段，拒绝窗口和时间缺口会切断它。每段选清晰度最高的中心采样帧，同分时靠近中点；段再长也不会每隔几秒重复导出。

但只比较相邻帧不够。一个提示框缓慢出现，相邻图都很像，整段内容却已经变了。第一版在约38分29秒的录屏中合成106段；抽查长魔法书段后，我们加入“与当前段起点比较”的外观变化检查。第二版得到318段，每段一张2560×1440原图。

图5：从第二版按候选序号间隔抽查16张。上半部分大量相似菜单，直接显示了过度切段问题；不能只展示下半部分成功选出的战场。

新检查使用160×90灰度图的8×6局部块，与段起点的最大块差超过0.065就切段。它修补了缓慢变化遗漏，却也会受移动云层等背景影响。目前“一段一帧”保证的是算法划出的段，不是已经标注正确的真实语义稳定段。 开头约200秒菜单被切成许多相似片段，这还需要长片段参考和更好的任务区域判断。

完整视频输出	数量与含义
5 fps采样	11,547张
第二版稳定区间候选	318段，每段1张原图
原帧率变化分支	检查69,279张30 fps缩略帧
短暂变化候选	198张，尚未证明都是重要提示

密集分支独立运行，不等待稳定门。它在320×180图上找局部变化，阈值0.015，候选间隔至少0.35秒。当前候选图片只是缩略预览，正式标注时回原视频提原图。更小的文字或更短的事件仍可能漏掉，所以198不是已测出的提示召回率。

稳定分支截图数减少97.25%，但这个比例没有算入198张变化候选，也没有衡量重要内容是否保留。最长候选段222.6秒，尚未完整审核。下轮必须直接标注真实可用区间，测每段是否选到图、是否重复切段和哪些提示完全没选到。五帧分类成绩不能替代这些指标。

5. 速度：模型预测很轻，视频读取更贵

以下在AMD Ryzen 9 9900X 12-Core CPU运行。96组共480张原图，读取、缩放及特征提取6.661秒；七折比较和最终模型训练0.677秒。模型常驻后，批量预测平均每窗口0.040毫秒，不含图像处理。新进程内测到导入及模型加载0.797秒，不含解释器启动，也不是完整冷处理时间。

第二版处理整段38分29秒视频	耗时
已有5 fps缓存检查	0.027秒
顺序读取缓存和提特征	27.969秒
批量模型预测	0.029秒
导出318张原尺寸图片	14.180秒
读取密集缓存、筛选并写候选	21.247秒
整个运行，含其他开销	64.387秒

第二版复用了已经生成的两份缩略视频缓存。第一版从冷媒体缓存开始，总耗时176.374秒，但它导出的是106张稳定代表帧，配置和输出数量也不同。因此不能把176→64解释成算法本身加速；第二版完整冷缓存耗时尚未测量。以上也没有包含OCR、scene分类和日志解析。

复现入口与版本

源码在Desktop的olden-era：perception/experiments/b033_stable-segment-keyframe-mining/README.md给出PowerShell训练、视频运行及测试命令。results/reviewed96-input.json冻结原图路径、来源时间、最终标签和审核修订；reviewed96-model.json保留每个样本的折外分数、环境和首次计时。

训练入口支持--snapshot，重跑冻结输入已复现相同分数和模型选择。OpenCV 4.14.0、scikit-learn 1.9.0；源码提交后由Git记录版本。模型和完整媒体留在本地数据目录，博客不把它们当作公开下载的数据集。

6. 短提示可以直接成为训练原图

图6：一张原尺寸法术说明截图。即使显示时间短，只要文字清晰，也可以标注。这里没有标完整出现/消失时间，不能把这张图当作已验证的短事件召回证据。

稳定选帧用于减少重复，但“停留得短”和“无法读取”不是一回事。短暂而清楚的提示仍可作为候选；本轮尚未证明这些提示都能被保留下来。关键帧只是帮助采集数据，后续识别应当直接检查自己要读的区域。

实验记录：短提示标注与后续供样计划

下一步的场景表达包含三层：战斗 → 魔法书 → 法术说明；或者战斗 → 普通战场 → 对某个单位的目标预览。第三级描述当前交互细节，目标部队与数值归属另外记录。仅有“伤害”二字，不能判断它是法术描述、普通攻击预览还是战斗日志。

已经整理22张原图到同一个交互详情标注页：12张无额外详情，6张法术说明，2张技能说明，1张普通UI提示，1张确认框。它们包括英雄/单位面板、日志及过渡对照，全部有助手标签和来源；尚未训练三级分类器，也尚未在这22张中取得目标伤害预览正例。

短暂内容不限于魔法。普通攻击、生物/英雄技能、法术在指向目标时，都需要记录释放前画面实际显示的预计伤害。我们为此新建B034，把动作来源、目标对象、文字区域和数字联系起来；“预览过”不等于“已经释放”，显示的法术基础伤害也不等于针对这个目标的预计伤害。

供样方法也不预先定死：先测稳定帧能保留多少提示，再比较局部变化候选和OCR检索的新增覆盖。如果稳定采样已足够，可以简化；如果漏掉短提示，就保留旁路。首要目标是得到足够好的scene与元素标注，关键帧只是为此服务。 同一原图可以同时关联生物框、计时、英雄属性和提示文字，不必为每项任务重新截图。

本机可查看新增32组和完整视频候选。后续先补长区间参考及攻击/技能/法术预览的正负例，再训练和比较；现有视频确实缺少某类时，再给出具体补录动作。

补数据有两条路线：先把已经选出的图读完，再用文字索引寻找稀缺的状态说明。下面第 7 节回到更关键的问题：稳定筛选是否漏掉了清晰但停留很短的面板？

展开数据采集记录：读完候选、换来源、用索引找状态

先把已经选出的图片读完

后续短悬停采集在4段开发录像的8个一分钟片段中，保留了1868张候选，包括5 fps、10 fps五帧对照和额外细节保留分支。五帧在10 fps下首尾相隔0.4秒，比5 fps的0.8秒更短。候选变多后，新的瓶颈是：其中只有403张完成了OCR，其余1465张还没有读过。此时继续提高采样密度，会先增加一批尚未处理的图片。

因此这轮保持采样模型和OCR配方不变，从每段尚未扫描的候选中，按时间分散选8张，共64张。先定图片清单，再运行原来的整屏分块OCR；不根据文字内容、参考答案或识别结果挑容易的图。旧扫描另存保留，新目录继续记录完整1868张的处理状态。

首轮64张全部完成，当时为467张已扫、1401张待扫。新增3210条选中文字候选，加入了64张时间线与文字检索。随后每段再取16张未扫候选，新增128张，当前累计595张已扫、1273张待扫，可检索文字候选共29552条。128张增量入口与上轮分开；这些读数尚未逐条审核，可能错误或重复，不是新增训练真值。

两批都已通过面板和提示读取链：首轮64张补了3张原图的稀疏参考；新128张有117张进入流程、11张场景跳过，提出了3张能力说明、4张生物细节和1张状态提示候选，尚待逐项审核。详情见面板实验。这一步没有测出新的稳定性准确率，也没有修改旧实验成绩；它让已有数据继续向后流动：先扫描，再找有用画面，再核对字段。

图片之外，还要增加不同内容

后来我们换到另外三个已有开发录像，各取一分钟。相同的10 fps五帧模型选出31、27、39张代表图，共97张，全部完成OCR，新增4592条可检索读数。这是单独的跨来源批次，不是从上面的1868张库中再扫97张；这些录像以前已经用于项目开发，也不能当作未见测试集。

实际收益是更多不同生物的属性面板和法术说明：7张原图新增121项参考，并进入面板读取对照。但没有找到新的状态效果悬浮说明。开局附近的资料窗适合补属性，不一定适合找施法后的剩余回合；下一步应换到交战中后段，而不是继续增加相同窗口的密度。这一轮没有标完所有短事件，因而不报告稳定采样的召回率。

录像到了中段，不代表战斗到了中段

随后，我们把三个窗口向后移：两段取20至22分钟，另一段取15至17分钟。仍用相同采样算法，留下74、64、20张原图，共158张；全部完成OCR，增加6775条可检索读数。这个中段批次同样独立保存，既不覆盖前97张，也不改变旧1868张库的进度。

看完原图后，采样假设的问题很清楚：第一段仍在战斗，第二段已经进入另一局的技能与神器选择，第三段跨过胜利结算、菜单和战绩页。录像秒数不能代替对局进度。采到了稳定的选秀画面，并不是稳定性算法出错；但对“寻找战斗状态说明”这个目标来说，这些不是高收益窗口。

这批没有看到新的状态悬浮说明，却保留了一张受伤生物面板：数量122/150、生命1/6，还有一个属性显示-1。我们按原图补了16项稀疏参考，待用户核对；其他文字仍是模型候选。下一轮先用已有场景索引确认战斗区间，再在其中细采面板出现与消失附近的动作。先找对内容，再加密采样，比单纯把时间戳往后移更有效。 目前没有穷尽原视频中的所有短提示，不能把“候选里没找到”解释成“录像里不存在”。

先用索引找位置，再回原录像细采

下一轮按这个思路执行：检索三段开发录像中已被分类器提示为“生物面板”的56张预览，再看原图确认。索引不直接充当标签；它只把需要逐帧查看的范围缩小到几个有希望的位置。最终固定六个短窗口，共142秒，其中一个专门保留外观相似的左侧能力说明作为对照。

采样器仍是原来的10 fps五帧模型，没有换参数。这次得到88张代表图，全部完成OCR，新增4660条可检索读数。原图中找到了13张可读状态说明，来自两段录像、八种标题；另外补了六张相似画面负例。它们进入独立的标注批次，不混进旧1868张库的完成数。

收益主要来自找对片段，不是证明采样器变准了。窗口是看过来源预览后选择的，尚未列出里面全部短事件，因此仍不报告整体召回率。后续识别又发现，三张已经保住的可读说明被场景门挡住；状态提示实验保留了这些失败。选到图、认对场景、读出文字，是三步不同的工作。

继续用这个方法，又从四段开发录像中选定八个窗口，共78秒。相同采样器留下66张新图，全部OCR完成，增加3364条可检索候选。这批特别保留鼠标贴近角标、图标被遮挡和空状态条的画面；32张原图已有局部参考，两处看不清的数字明确记为未知。进入这一批审核，或看图标与数字实验的结果。没有改变采样阈值，也没有穷尽窗口内的短事件，因而这仍是供样进展，不是新的采样召回率。

下一次则专门找稀缺符号：按另外四段录像的场景索引查看205张原尺寸状态行，在两段录像找到∞，再固定七个窗口、共54秒。相同筛选器保留41张候选，全部OCR完成，新增2080条可检索文字；14张有逐图状态条参考。这里的205张是找片段的线索，不是205张新标注。更有价值的是，新数据暴露了多个OCR都误读∞的问题，让下一步有了具体目标，而不只是增加重复图片的数量。

7. 避开了半透明图，却也漏掉了短面板

后来，状态图标实验发现：有些半透明面板虽然还在淡入，下面的数字已经能读到，单张图的质量检查也可能放行。它会不会被视频选帧器留下来？这需要回到录像看前后帧，不能用一个截图替整段视频下结论。

我们围绕四次半透明例子和一次清楚面板，各取四秒，共五段、200个10 fps采样点。先逐点看原图，再运行原模型；模型、阈值、五帧窗口和代表帧选择都不变。参考只标中央生物面板是清楚、半透明还是未出现，不要求生物立绘停止动作。这是四段已曝光录像中的定向检查，不是随机或独立验收。

原图中看到的面板	采样点	有完整五帧窗口	接受的中心	最终代表帧
清楚、没有明显透景	52	52	28	4
半透明	25	24	0	0
未出现生物面板	123	104	74	13

这批没有留下半透明代表帧；问题在另一头：七次清楚面板，只保留了三次。 “四张清楚代表帧”和“三次面板”不矛盾：其中一次出现了新的状态说明，算法保留了前后两张。其余四次漏采，都没有任何五帧中心被接受，不是后来合并去重把它们删掉了。

下面这张就是漏采的原图。面板在两个相邻采样点都清楚，但五帧窗口还包含前后的淡入淡出。

图7：9月5日开发录像的名义媒体时间2380.1秒，原图2560×1440。标题、属性和状态角标可见；相邻2380.2秒也清楚。该片段连续查看了三个生物，三次清楚显示分别只有2、2、3个采样点，全部被五帧筛选漏掉。这里没有把所有小字标注完，也不把名义时间当作精确原始帧时间。

另一次漏采持续五个采样点，但最后一个点的生物立绘已经消失，面板文字仍然清楚。对“读数字”来说，等待整个区域都稳定可能太苛刻；对“收集生物外观”来说，这一帧又确实不适合。这说明后续任务需要检查自己的区域，不能共用一个“整张图一定可用”的结论。

逐帧审阅这200张采样和17张实际代表图。页面可筛出“漏掉的清楚面板”，用左右键或进度条来回看；角落区分助手外观参考与算法选中状态。参考仍待用户复核。

这让下一步变得具体：保留主筛选器，另外补采短面板，再检查读出的文字。单图质量门的半透明反例仍保留，不能因为这五段被选帧器挡住，就宣布那个问题已经修好。

8. 每隔0.2秒补一张：找回了图片，也留下了错误

先试一个最简单的办法：对上面的短窗口，每隔0.2秒取一张原图，不等待五帧都通过稳定检查。这就是固定5 fps补采。它只回答“还可以读哪些图”，不回答“这些图是否稳定”；原来的17张代表图照常保留。

我们先固定从窗口起点抽图，再比较不同频率。下面只统计是否碰到七段清楚面板中的至少一个采样点；半透明图也如实计入成本。它们仍是同一批已曝光开发录像，不是新增的独立测试数据。

方法	候选时间点	碰到清楚面板	半透明图
原五帧稳定筛选	17	3/7次	0
每0.5秒取一张	40	5/7次	7
每0.2秒取一张	100	7/7次	14
每0.1秒取一张	200	7/7次	25

这次5 fps够用，不必为相同七次面板把候选再翻倍。为避免只碰巧选对抽样起点，我们也检查了10 fps序列上的其他起点：5 fps的两种起点都能碰到七次面板，2 fps的五种起点则只能碰到五或六次。这不能保证未来更短的提示也会被保住。

补回的内容值得读取吗？

值得。9月5日那一段连续查看了三个不同生物，原稳定筛选一个面板也没留下；补采图中的标题、生命值、攻防和状态角标都可读。我们把100张补采PNG和17张实际代表JPEG全部交给既有本地OCR，得到6110条选用文字候选。两种导出即使名义时间相同，也分别读取，没有假定它们是同一张图。单图处理时间合计约400秒，不含模型启动和后续面板流程。

从七次清楚面板各选第一张补采图，按原图转写75项标题、属性和角标，再与整屏扫描结果核对：73项字面一致，两项读错。 火凤凰面板的-1被读成1，另一张状态角标的∞被读成8。这75项是助手新增的稀疏参考，待用户确认；没有标完所有UI，也不能把73/75当作整屏识别准确率。

读到字和接入后续流程仍有距离。固定面板算法处理了97张，另20张被场景门跳过；七张文字参考里，火凤凰那张虽然能读出标题，却没有被定位为生物面板。14张半透明补采图中，还有两张通过了旧单图外观门。它们都保留在补采原图与OCR审阅页，可按文字搜索、筛出参考图、叠加框，并用左右键或滑条核对。

因此，当前采用的是短窗口离线补采，不是把所有录像改成高密度OCR，更不是降低在线稳定要求。火凤凰缺父面板的问题，后来通过独立属性列定位补回；原有面板和拒识读数不变。下面接着看找回图片后，小字是否真的更容易读。

9. 裁下来再读：负号找回了，放大却不总是更准

整屏扫描要同时找到文字和认出文字。面板已经定位后，可以把标题、属性数字和状态角标单独裁出，让识别器只读一小块。裁剪仍由程序决定，不把人工标注框或参考文字交给模型。

这次对同一批117张图统一执行，29张通过现有面板质量检查，产生392个裁剪；另33个字段裁剪被质量门跳过，其余图片也保留处理状态。每个裁剪分别交给本地PP-OCRv6_medium_rec和PaddleOCR-VL-1.6，各读原尺寸、补边后放大四倍两种输入，共1568次读取。没有为了这次比较训练模型或改变质量阈值。

下面仍只核对先前七张图的75项稀疏参考，不是392个裁剪都已经人工验收。放大是在裁剪四周补8像素后做Lanczos插值；“VL原尺寸”指送入模型前不额外放大，模型内部仍会预处理图片。

读取方式	与75项参考字面一致	仍读错
原整屏扫描	73	2
PP，原尺寸裁剪	70	5
PP，补边放大	64	11
VL，原尺寸裁剪	74	1
VL，补边放大	73	2

局部读取确实能补漏，但更大的输入不等于更准确的答案。 火凤凰的-1在原整屏结果中丢了负号；局部VL两遍都读回-1，PP原尺寸也读对，PP放大却又变成1。另一个本来能读对的8，被放大后的VL读成87。这些对照保留所有读法，没有按参考答案给每个字段挑一个胜者。

图8：左边是-1，右边是∞，均来自自动裁剪，浏览器放大显示便于看像素；不是把识别结果画回图片。原裁剪可在审阅页单独打开。

∞仍是另一类问题：VL两种输入都把它读成8，PP也没有读对。已有的字形检查能在这个裁剪中提出∞，因为它检查的是两个孔洞的横向排列。我们对全部261个可检查槽位都运行它，包括188个未检出图标的槽位；共提出5次∞，184次不作判断，72个较小的原生裁剪不支持。这里只核对了12项已有角标参考，不能据此宣称所有槽位都认对，也不把符号直接解释成效果剩余回合。

打开117张原图与局部重读对照。可以筛出“有局部重读”，并列看四次读数、原裁剪和独立字形结果；上方旧OCR与人工参考仍然分开。这个页面是新增的本地审阅入口，尚未合并进主语义时间线。

现在的结论很具体：短窗口补采把漏掉的面板送到了读取器，局部重读又找回了一个负号，但∞和暗色数量仍不能只靠放大解决。下一步扩大不同录像中的这些困难样例，再决定哪些局部读法值得接入主流程；不继续围绕这五个窗口调整稳定模型。

10. 换三段录像：图片保住了，后面的门仍会挡住字段

接着换到三段开发录像，先看已有索引指向的71张预览，再固定十个窗口，共144秒。它们包含布阵、战斗中的生物资料窗、较长的技能说明和状态悬浮提示。仍用同一个10 fps五帧筛选器，得到100张新原图，全部完成整屏和分块OCR。这一批与上面的117张分开保存，也没有动独立验收录像。

下图把几个值得收集的内容放在一起：左上数量14/220、生命3/9、下方状态图标，以及鼠标悬停后出现的“天堂之刃”说明。数量右半边颜色较暗，不能只读取明亮的当前数量；鼠标压住的角标则暂不填参考答案。

图9：9月4日开发录像，名义媒体时间1678.4秒。只裁去外围战场，没有改变原图像素。文字可帮助定位训练样本，但不从这张图推断实际伤害或效果持续回合。

我们从六张原图转写79项稀疏参考，包括名称、数量、八列属性、五个清楚角标和14行说明文字；仍待用户确认。整屏结果有76项得到唯一一致读法。其余三项不是同一种失败：一个0旁多出冲突候选xo；一个7漏掉；“(Shift)显示更多信息”被正确拆成两行，但不符合本轮“一项参考对应一条唯一文字”的计数规则。不能把它们简单统称为三个认错的字。

后续面板流程在100张中找到45个生物面板，27张通过当前质量检查，生成307个自动裁剪。没有根据人工框补裁，也没有为了增加通过数降低门槛。一张长技能说明遮住左侧能力列表，尽管上方数值清楚，整面板质量门仍挡住了它的局部读取。这是下一步更值得解决的问题：分别检查真正要读的区域，而不是把整个面板一并判为可读或不可读。

307个裁剪仍各用两个本地模型读原尺寸和放大图，共1228次，全部完成。单看属于这条局部读取路径的65项参考——名称、数量、属性和角标，不含另14行说明文字——结果如下：

方法	字面一致 / 65项	读法冲突或不同	没有可用裁剪或文字行
原整屏扫描	63	1	1
PP，原尺寸裁剪	51	3	11
PP，补边放大	47	7	11
VL，原尺寸裁剪	54	0	11
VL，补边放大	54	0	11

局部VL把整屏漏掉的7读回，也没有带入0旁的冲突文字；但它并没有读到全部65项。已经裁出来的54项读对，不等于整条链路完成了65项。 这也解释了为什么不能只比较识别器的得分：送图前的拒绝同样决定最终能得到多少信息。

逐张查看新100张原图、79项参考和自动读数。页面保留所有候选，可检索OCR、叠加框、用方向键和进度条浏览；尚未逐项审核的图片会明确标出。它仍是本地独立审阅页，不是已合并进主语义时间线，也不是100张完整训练标注。