APNG半透明帧越叠越深，怎样比较SOURCE替换与OVER合成

APNG的blend_op决定当前矩形是替换已有像素还是按Alpha叠加。SOURCE与OVER的输入帧可以相同，最终画布却不同；核对时应把规范预期与具体读取器结果并列，不能只因为工具能打开文件就当作像素公式正确。

这组文件怎样比较

本题第一帧是不透明红色，第二帧为Alpha128的蓝色，两份APNG只改变第二帧blend值。另附独立参考合成PNG。这样输入颜色、处置和时间都固定，能够明确比较替换与叠加，而不混入视频透明边缘或WebGL状态。

按原始结构逐项检查

1. 先解析fcTL确认SOURCE为零、OVER为一，两帧处置均为零且首帧参与动画；再独立zlib解压原始RGBA，确认红底不透明、蓝帧Alpha128，并逐块核对CRC。SOURCE按规范用当前RGBA替换矩形，本地读到蓝色Alpha128；OVER应把蓝叠到不透明红底上，按公式合成后的Alpha应保持255，不能把它平均成中间透明度。

2. 参考计算使用输入Alpha分数：128/255加上底层的1乘以剩余127/255，结果为1。对应八位直通通道参考像素为127、0、128、255，reference-over.png以Image.alpha_composite独立计算并保存。RGB参考不是显示色彩准确性认证，Alpha255结论不依赖RGB是否线性化。这里采用明确的原始纯色输入，不从显示截图反推颜色。

3. 实际Pillow12.0.0的APNG读取路径给出127、0、128、191，与上述参考Alpha不一致。公开报告保留这一差异，loader_matches_reference为假，不将读取器的191冒充PNG规范预期，也不删除异常结果让样例看似全部一致。

容易误读的地方

反例是看到两个文件像素不同，便认为已经证明OVER实现完全正确。差异仅说明路径不同，正确性仍要对照公式；另一反例是把本地版本现象推广到所有浏览器或Pillow13。本题没有运行那些实现，不能替它们报告相同问题或已经修复。

下载与本地读回

generation.json、observed.csv、observed.json、over-frame0.png、over-frame1.png、over.apng、reference-over.png、source-frame0.png、source-frame1.png、source.apng。

下载全部附件到同一个独立目录，用 python verify.py 运行本题独立核验脚本。依赖为Python 3.12.4与Pillow 12.0.0；程序不联网、不连接设备，读取本题文件并在终端输出检查结果。本地实际执行回执保存实际命令、退出码和完整输出。

核验脚本同时检查两份fcTL、完整解码帧、参考Alpha算术和参考PNG。退出码零表示这些事实与本题断言一致，并不表示读取器匹配参考；执行回执内明确留下false值。若接收方需严格像素一致，应换指定实现再次核对并保存版本。

格式规则和本地Pillow实现分别核对。当前Pillow滚动文档已为13.0.0，本例实际运行12.0.0；没有测浏览器调度、目标引擎或现场屏体。

把结果带回交付

交付可带上两个最小APNG、参考PNG和实际读回值，让接收方复现差异。必要时采用经过验证的预合成完整帧方案，但要重新确认透明与处置要求；不要仅凭肉眼在白底上看着接近就签认，因为Alpha差异可能在后续叠到其他背景时显现。

相关背景见互动翻书换成高分辨率图片后卡顿，怎样测预加载成本，还可从多媒体播放专题继续查找文件处理方法。需要核对实际工程的接收条件时，可携带本题文件与读回结果进行工程对接咨询。

一级依据

• SOURCE用当前帧替换其矩形区域，OVER将当前帧按Alpha叠到既有输出。

来源核对日期：2026-10-24。引用支持文件机制；原创输入的本地结果不代表客户素材或现场系统已经通过验收。