有损与无损压缩在格式转换中的体积取舍

PNG、JPEG与WebP转换：体积、画质与兼容性的测试方法

照片通常应比较JPEG与WebP有损编码；截图、文字和透明图标通常应比较PNG与WebP无损编码。但不能仅凭格式判断体积，必须固定编码器和参数后，实测文件大小、画质与兼容性。

先分清转换、重新压缩和改扩展名

• 格式转换：对PNG、JPEG、WebP这类编码格式来说，先解码原数据，再按目标格式重新编码。
• 重新压缩：用新的编码器、模式或参数再次编码，可能引入新的量化误差。
• 改扩展名：只改变文件名，不改变文件内部的编码数据。

把photo.png改名为photo.webp，不会把PNG变成WebP。仅修改扩展名不会改变文件字节内容，也不会改变其中可解码的像素数据；但文件可能因此无法被按扩展名识别的程序打开。

PNG使用无损压缩，适合截图、界面文字、图标和线稿；照片保存为PNG时，体积可能较大。JPEG主要使用有损压缩，不支持Alpha透明度，适合照片，却容易在锐利文字、渐变和重复编辑中出现伪影。WebP同时支持有损和无损模式，并支持Alpha通道；具体体积取决于编码器、参数和图像内容。

• PNG：无损，支持Alpha；照片体积可能较大。
• JPEG：有损，不支持Alpha；可能出现量化、色度抽样和重复编码伪影。
• WebP：支持有损和无损，也支持Alpha；结果依赖编码器和参数。

WebP由Google于2010年推出，其有损编码基于VP8帧内编码技术。本文不把WebP历史版本作为比较条件，实验时直接记录所用工具的版本，避免把不同实现的结果混在一起。

画质损失来自哪里

JPEG编码器可能把RGB转换为YCbCr，并对色度分量进行抽样，例如4:2:0或4:4:4；随后进行8×8块DCT、量化和熵编码。使用何种抽样方式取决于编码器和参数，不能只看文件扩展名判断。4:2:0通常更省空间，但小字号文字和彩色细线更容易受影响。

每次以JPEG重新编码都可能引入新的量化误差。重复次数、质量参数、色度抽样和编辑内容共同决定损失是否明显。JPEG转PNG不会恢复原始细节；在不改变解码后像素的前提下，PNG输出通常比原JPEG更大，但具体结果仍取决于图像内容、位深、色彩空间和编码参数。

WebP的Alpha通道可与有损或无损图像编码结合，但Alpha数据的编码方式和质量设置可能由编码器单独控制。透明图像也不等于单一格式：Alpha可以是二值、灰度或预乘Alpha，实验必须记录实际处理方式。

用固定条件做可复现实验

1. 准备四类样本：照片、截图、透明图标和线稿。每类至少准备10张，并覆盖不同尺寸、纹理复杂度和透明边界；报告每类文件大小的中位数、平均值以及最小值和最大值。
2. 从同一无损源文件生成各格式，统一像素尺寸、裁切范围、色彩空间、位深、Alpha处理、输出范围和元数据策略。JPEG与WebP还要分别记录质量参数、色度抽样、编码器名称和版本。
3. 以libwebp 1.x中的cwebp为例，将-q 75、-q 80、-q 85、-q 90作为起始档位，并单独测试无损模式。这里的数值只是本实验起点，不是跨编码器的通用质量等级；不同编码器的质量参数没有统一标尺，不能直接比较“q=80”。
4. 统一按字节统计，并分别计算三种基准：相对源PNG的体积变化、相对原始JPEG的体积变化、相对无损源文件的体积变化。公式为（输出字节数−基准字节数）÷基准字节数×100%。必须注明是否包含ICC配置文件、其他元数据和文件头。
5. 先规定透明图像的比较方式。是直接比较RGBA，还是先合成到固定背景？两种结果不要混用。

如果使用客观指标，应将输出解码后与无损源图对齐，再计算PSNR或SSIM，并报告计算实现、窗口设置和色彩空间。透明图像还要固定背景合成方式；否则不同Alpha处理会影响结果。没有实际指标数据时，不要只列出指标名称冒充实验结论。

人工验收可以这样执行：由两名评审分别在100%和200%倍率下检查文字边缘、渐变、暗部、细线和透明边界。任一评审发现输出相对源图新增伪影，就淘汰该参数；合格档位中再选择字节数最小者。

• 截图、文字和线稿：先比较PNG与WebP无损。只有在允许轻微伪影，且实测显示体积收益明确时，才考虑WebP有损。
• 照片：可从-q 75、-q 80、-q 85、-q 90开始比较；这些数值不是所有照片的推荐值，也不代表测试了-q 70以下或-q 95以上。
• 逐像素一致：将源图和输出解码到相同色彩空间、位深和通道排列后逐点比较，并明确是否比较Alpha。无损编码只保证编码前后的解码数据一致，不保证不同软件导出的源图彼此一致。

工具、兼容性与发布检查

• 支持有损和无损模式；
• 支持质量或压缩参数，并显示编码器版本；
• 说明Alpha的编码方式、位深和预乘处理；
• 说明ICC配置文件、EXIF等元数据是否保留；
• 发布WebP时以image/webp返回正确的MIME类型。

兼容性取决于实际浏览器、移动端、查看器和内容管理系统的版本，不能用一句“浏览器支持”代替测试。发布前至少检查目标桌面浏览器、移动端浏览器和CMS上传流程，并确认缓存与内容协商配置不会把WebP错误地发给不支持的客户端。

如果目标客户端仍可能不支持WebP，再保留相应的JPEG或PNG回退版本。网页可以使用<picture>提供多种资源，也可以采用服务器内容协商；选择哪种方式，取决于现有缓存、CDN和应用架构。