为何不同方式拼接生成的PNG图像像素与文件大小存在差异？

问题场景 #

• 将拆分为4个分片的单张图像，通过3种不同方法完成分片拼接：
  • 手动在Microsoft Paint中操作拼接
  • 手动在paint.net中操作拼接
  • 借助Python PIL库编程实现拼接
• 所有拼接结果均保存为PNG格式，最初认为PNG属于无损压缩格式，不同方式生成的结果应当完全一致，但实际文件大小差异极大：Microsoft Paint生成的文件大小几乎是PIL编程生成版本的两倍。
• 使用忽略元数据、逐像素比对的程序校验后发现，3张输出图像没有任意两张完全一致。用到的比对Python脚本如下：

import sys
from PIL import Image

def compare_images(fn1, fn2):
    im1 = Image.open(fn1)
    im2 = Image.open(fn2)
    return (list(im1.getdata()) == list(im2.getdata()))
    
print(compare_images(sys.argv[1], sys.argv[2]))

首先明确核心认知：PNG的「无损压缩」定义是「解码后输出的像素和编码时输入编码器的像素完全一致」，从来没有承诺过不同编码器、不同处理流程输出的文件体积、甚至最终像素值完全相同。出现观察到的差异，主要来自以下几个独立原因：

1. 色彩空间与伽马校正的隐式处理 #

不同图像工具对PNG内嵌的色彩配置块、伽马值的处理逻辑完全不同，且多数是默认自动生效，不需要用户手动操作：

• Microsoft Paint默认会给所有导出的PNG嵌入sRGB色彩配置块，如果导入的图像分片没有标注伽马值，Paint会自动按系统默认的2.2伽马做一次像素值校正，直接修改最终写入的RGB数值；同时Paint默认会把图像DPI设为系统屏幕DPI（通常是96或120），写入pHYs物理分辨率块。
• paint.net会保留原分片的色彩配置，但在多图层合并导出时，会对不同色彩空间的分片做8bit精度对齐，可能带来像素值的±1偏差。
• PIL库默认读写PNG时不会自动应用伽马校正，也不会主动写入色彩配置、分辨率等非像素块，读入的就是文件里存储的裸像素值。
  三者处理逻辑不统一，自然会出现逐像素比对不匹配的情况，这类偏差通常很小，肉眼几乎无法识别。

2. 编码参数差异直接导致体积差 #

PNG使用DEFLATE算法做压缩，最终文件体积完全由编码器选择的压缩等级、行过滤策略、元数据块多少决定，和画质无损没有关系：

• PIL保存PNG默认使用6级压缩（0-9级，等级越高压缩率越高速度越慢），会自动遍历4种行过滤算法选择压缩率最高的组合，默认不写入多余元数据，因此压缩效率最高，体积最小。如果显式指定compress_level=9, optimize=True参数，体积还能进一步缩小。
• paint.net默认使用5级压缩，会写入软件标识、编辑历史标记等少量元数据，体积居中。
• Microsoft Paint的PNG编码器使用的压缩等级极低，基本不做行过滤优化，还会写入大量冗余块：包括内嵌缩略图、系统色彩配置、分辨率信息、文档属性等，仅冗余元数据就可能占几十KB，再加上低效的压缩策略，最终体积达到PIL版本的两倍是非常普遍的情况，不代表它的画质更高或者像素有损失。

3. Alpha通道的预乘处理差异 #

如果原图像分片带透明通道，三个工具对半透明像素的处理逻辑完全不同：Paint会自动对半透明像素做预乘Alpha校正，paint.net默认保留非预乘的RGB值，PIL读写时默认不做任何预乘处理，这部分像素值的差异会非常明显。

4. 拼接过程的隐式边缘处理 #

手动在绘图软件中拼接时，如果分片粘贴的位置没有做到像素级严丝合缝，或者选区带了1像素的羽化，Paint和paint.net会自动给拼接边缘做抗锯齿平滑处理；而用PIL编程拼接时，如果是按精确坐标直接粘贴像素，不会做任何平滑处理，边缘像素值自然会出现差异。

验证方法：将三个软件导出的PNG全部用PIL重新打开，统一转成无Alpha通道的RGB模式，丢弃所有元数据块，用完全相同的PNG编码参数重新保存后再做逐像素比对，就能排除绝大多数非内容类的差异。如果还是不一致，优先检查手动拼接时是否出现了位置偏移、软件自动加了锐化/平滑类的默认效果。

内容的提问来源于stack exchange，提问作者chasemhalasem