先说个真实踩坑的事。前阵子帮一个做电商的朋友排查线上问题同一张商品主图安卓端糊成一片iOS 端却清清楚楚。查了半天 CDN、查了客户端解码库最后发现是设计团队导出时把源图存成了质量参数 35 的 JPG还带 4:2:0 色度子采样安卓那批低端机在缩小渲染时又叠加了一层双线性插值细节直接被抹平。问题不在链路在文件本身。这类事我碰到过太多次。多数人对 JPG、PNG、GIF 的认知停留在“照片用 JPG、图标用 PNG、动图用 GIF”这句口诀上真要抠体积、保画质、留透明、防元数据泄露的时候基本靠试。所以这篇我想把这三个格式从像素、颜色、压缩、元数据四个维度彻底拆开讲一遍——它们不是三种“后缀”而是三套完全不同的数据结构与编码哲学。看完你至少能做到知道一张图为什么大、大在哪、砍哪一刀不伤画质、什么时候该换格式、以及那张图里除了画面还藏着什么。新手能建立体系老手能补齐那些“一直这么干但没想过为什么”的空白。1. 三种格式的定位与整体设计思路1.1 从“一张图到底是什么”开始建立坐标系要理解格式差异得先统一语言。一张位图在计算机里就是三层结构像素网格宽×高多少个点、颜色模型每个点用什么方式描述颜色、编码方式这些颜色数值怎么变成字节流存进文件。JPG、PNG、GIF 的全部差异本质上都是在这三层上做了不同取舍。像素网格这层三者基本一致都是矩形栅格没有矢量路径。差别从第二层就开始了JPG 和 PNG 的常规模式都是直接色direct color每个像素独立记录自己的颜色值GIF 和 PNG-8 走的是索引色indexed color像素里存的不是颜色而是一个指向调色板的编号。这个差别决定了后面所有事情——索引色的图改一个像素颜色可能要改整张调色板直接色的图改哪算哪。第三层编码是分水岭。JPG 是有损的它在编码阶段就主动丢弃信息且丢弃不可逆PNG 是无损的解码出来的像素和编码前逐位相同GIF 的压缩本身无损但它在进入压缩之前先把颜色砍到 256 色这一刀是有损的。所以准确说法是GIF 单帧有损、帧间无损。提示很多人以为“PNG 比 JPG 清晰”这句话只在特定场景成立。PNG 只是不丢信息如果源图本身就是一张低质量 JPG转成 PNG 不会变清晰只会变大。理解这三层之后很多“玄学”就有解释了。比如为什么 PNG 截屏文件动辄几 MB因为屏幕截图里有大量纯色块和高频文字边缘无损压缩对前者效率极高、对后者效率很低而 JPG 压同样内容会糊掉文字边缘因为它的算法假设“高频细节人眼不敏感”这个假设在照片上成立在文字上完全失效。1.2 为什么不是一种格式通吃压缩哲学的三条岔路三种格式诞生于不同年代、面向不同场景它们的分歧点其实就一个假设什么信息可以被牺牲。JPG 的假设最激进人眼对亮度敏感、对色度迟钝对低频轮廓敏感、对高频细节迟钝。基于这两条生理学观察它敢把色度分辨率砍一半敢把高频系数粗暴量化。这个赌注在自然照片上赢得漂亮压缩比轻松做到 10:1 到 20:1 而肉眼难辨但在图标、截图、线稿上输得彻底8×8 分块边界会形成肉眼可见的“方块噪”文字边缘会出现彩色晕边。PNG 的假设最保守一个比特都不能丢。它的压缩全靠“找重复”——相邻像素往往高度相关那就先做差分预测再把残差用 DEFLATE 压。这个策略在有大面积纯色、规则渐变的图上效率惊人UI 稿、图标、截图但对噪点多的照片几乎无效因为噪声不重复压不动。所以一张照片存 PNG体积可能是 JPG 的十倍以上。GIF 的假设最“古老”颜色够用就行。它诞生于 1987 年那时候显存和带宽都极端紧张256 色是硬约束。它的聪明之处在于帧间优化——动图里相邻两帧往往只有一小块在变那就只存变化区域。这个思路放到今天依然实用只是被更现代的格式继承了。我的经验判断法很简单问自己“这张图的观看者会不会逐像素对比”。会就用 PNG不会就用 JPG。中间地带比如需要透明的照片级素材才需要更细的权衡。2. 像素与颜色格式差异的物理根源2.1 像素排列与通道模型每像素到底占几个字节先把“每像素多少位”这件事算清楚这是理解文件体积的第一把钥匙。格式/模式每像素通道构成位深每像素字节透明支持JPG 灰度Y81无JPG 彩色Y Cb Cr8×33未子采样无JPG 4:2:0Y全采样Cb/Cr 2×2共享8平均 1.5无PNG-8调色板索引811 位索引透明PNG-24R G B8×33无PNG-32R G B A8×448 位 AlphaGIF调色板索引811 位索引透明这张表能解释很多现象。一张 1920×1080 的图PNG-32 裸数据是 1920×1080×4 ≈ 8.3 MB经过 DEFLATE 压缩后通常能到 1~3 MB同样内容存 JPG 4:2:0裸数据只有约 3.1 MB压完可能只有 200~400 KB。差距不是压缩算法谁更强而是入场时的数据量就不在一个量级。通道模型上还有一个容易忽略的点JPG 内部存的是 YCbCr不是 RGB。编码时先做色彩空间转换把 RGB 拆成亮度 Y 和两个色度分量 Cb、Cr解码时再转回去。这个转换本身有精度损失尤其是快速整数近似算法所以 JPG 即使质量设为 100往返一次也不是逐位无损的。我实测过同一张图存成质量 100 的 JPG 再读回来和原图做像素差分绝大多数像素差 0~2但极少数区域强饱和色边缘能差到 5 以上。2.2 色彩深度与调色板256 色到底够不够用GIF 和 PNG-8 的调色板上限是 256 个颜色条目。这个数字在 1987 年很合理今天就很紧张了。关键在于颜色不是均匀分布在色彩空间里的而是聚团的。一张人像照里肤色可能占了实际使用颜色的 60% 以上天空占 20%剩下的颜色加起来不到 20%。所以聪明的量化算法不会在 RGB 空间里均匀取 256 个点而是用中位切分或八叉树聚类把有限的颜色槽位优先分配给高频出现的颜色区域。即便如此256 色在渐变色上必然出现色带banding。一张天空渐变图减到 256 色平滑过渡会变成一圈一圈的台阶。解决办法是抖动dithering——用相邻像素的颜色混合来模拟中间色代价是引入噪点而且抖动后的图压缩率会暴跌因为规律性被破坏了。我做过一组对照一张 800×600 的渐变图256 色无抖动存 GIF 约 18 KB开抖动后到 60 KB 以上而且放大看有明显颗粒感。实操心得需要渐变过渡的图别硬塞进 GIF 或 PNG-8。真要做小体积渐变宁可上 JPG。反过来纯色 UI 界面用索引色几乎无损因为颜色种类本来就少量化误差接近零。PNG 有个中间态很多人不知道PNG-8 虽然是索引色但它的压缩方式和 PNG-24 一样走 DEFLATE所以同样 256 色PNG-8 通常比 GIF 小 10%~30%。唯一丢的是动画能力。2.3 透明通道的三种实现以及那个能把人逼疯的黑边透明是选格式时最常踩的坑三种格式的透明机制完全不同。GIF用的是“索引透明”调色板里指定某一个索引为“透明”所有用了这个索引的像素都不画。这是硬透明一个像素要么全透明要么全不透明没有半透明。所以 GIF 图的边缘会有锯齿因为它没法做 1 像素宽的半透明羽化过渡。PNG-8也是索引透明但支持一个调色板条目上的 Alpha 值实际能力仍接近二值。PNG-32有完整的 8 位 Alpha 通道每个像素的透明度可以是 0~255 之间任意值。这是做阴影、毛玻璃、圆角羽化的唯一正确选择。JPG 完全不支持透明。这是硬事实不是配置问题。由此派生出那个经典故障一张带透明背景的 PNG logo 转成 JPG透明区域会被填充成黑色或白色。为什么是黑色因为多数编码器把 Alpha0 的像素的 RGB 当作 0,0,0 处理丢弃 Alpha 后剩下的就是纯黑。这个坑我见过太多次尤其是新手把 UI 稿批量转 JPG 上传。正确做法是先合成背景色再转而不是转完再补救from PIL import Image src Image.open(logo_with_alpha.png).convert(RGBA) # 造一张白底画布把源图贴上去Alpha 会自动参与混合 bg Image.new(RGB, src.size, (255, 255, 255)) bg.paste(src, masksrc.split()[3]) bg.save(logo_on_white.jpg, quality90, subsampling0)这段代码里subsampling0对应 4:4:4 无子采样是保证边缘锐利的关键参数后面会细说。另一个隐蔽的坑是白色透明陷阱有些图的透明区域 RGB 值是白色有些是黑色。如果你直接丢弃 Alpha 通道而不合成结果取决于源图同一批图可能一半变白底一半变黑底非常分裂。所以永远走显式合成这条路。3. 压缩算法拆解有损与无损的本质分野3.1 JPGDCT 变换、量化表与质量参数的真实含义JPG 的完整链条是色彩空间转换 → 分块 → DCT → 量化 → 之字形重排 → 游程编码 → 霍夫曼编码。真正产生信息损失的只有量化这一步其他全是可逆的。流程细节值得过一遍。先把图像切成互不重叠的 8×8 小块每块 64 个像素。对每块做二维离散余弦变换把 64 个空间域的像素值变成 64 个频率域的系数——左上角那个是直流分量DC代表这块的平均亮度其余 63 个是交流分量AC代表不同频率的纹理强度越往右下频率越高。然后是量化把每个系数除以量化表里对应的步长再取整。量化表是 8×8 的低频位置步长小保护轮廓高频位置步长大狠狠砍细节。这就是 JPG 的核心赌注——高频信息砍掉人眼感知不到。质量参数 Q 不是“保留百分比”而是量化表的缩放因子。大致规律是Q 值量化表缩放典型压缩比适用场景95-100极小3:1 ~ 5:1需要二次编辑的中间稿85-92小8:1 ~ 12:1网页大图、商品主图75-82中15:1 ~ 20:1列表缩略图60-70大25:1 ~ 40:1可接受轻微劣化的场景50极大50:1 以上基本只在极低带宽场景用这个表是我自己长期测出来的经验区间不同编码器会有出入但量级不会差太多。有个反直觉的现象Q 从 100 降到 95体积可能掉 40%肉眼几乎无差别Q 从 75 降到 70体积只掉 10%但劣化开始明显。所以性价比拐点通常在 80 附近做网页图我会优先试 85实在超预算再往 80 压。还有一个必提的参数色度子采样。采样模式含义相对数据量建议4:4:4Cb/Cr 全分辨率100%文字、UI、需要锐利边缘4:2:2水平减半约 67%折中4:2:0水平垂直都减半约 50%自然照片、体积敏感4:2:0 是绝大多数默认值也是很多“JPG 图有彩色晕边”的元凶。红底白字这种强对比场景4:2:0 会让红色往白色区域渗形成粉边。做带文字的图我基本强制 4:4:4。注意事项JPG 每保存一次就重新做一遍 DCT 和量化误差会累积。同一张图存 10 次 Q85画质劣化肉眼可见。工程上一定要保留一份无损源稿所有导出版本都从源稿生成绝不要在成品 JPG 上反复编辑保存。3.2 PNG行滤波与 DEFLATE 的两级组合拳PNG 的压缩分两级第一级是行滤波第二级是 DEFLATE。行滤波的思路是“先做差分再压缩”。PNG 定义了五种滤波器类型名称预测方式0None不预测直接输出1Sub减去左边像素2Up减去上面像素3Average减去左与上的平均值4Paeth用左、上、左上做梯度预测编码器会对每一行逐个试五种滤波选“滤波后残差绝对值之和最小”的那种然后把类型字节写进行首。这个启发式很朴素但极其有效——对水平渐变图Sub 滤波后残差几乎全零对垂直渐变图Up 最好。第二级 DEFLATE 是 LZ77 滑动窗口加霍夫曼编码的组合。它先在一段窗口内找重复字节串用“距离长度”的引用替代再对剩下的字面量和引用做霍夫曼编码。因为 PNG 滤波后大量出现连续 0x00LZ77 能找到超长重复串压缩效率极高。关于 PNG 压缩级别有个常见误解级别 1~9 只影响编码速度和尝试匹配的深度解码结果完全一致。级别 9 比级别 6 慢但通常只小 2%~5%级别 1 快但可能大 10%。批量处理时我用级别 6单张精修时用 9。PNG 还有个杀手级优化调色板化 位深压缩。一张原本 32 位色的图如果实际只用了 12 种颜色可以转成 4 位索引色每像素 4 bit文件能小一个数量级。所以给 UI 资源做优化时第一步永远是统计实际颜色数。from PIL import Image im Image.open(ui_asset.png).convert(RGBA) # 统计实际使用颜色数 colors im.getcolors(maxcolors1 24) print(颜色总数:, len(colors)) # 颜色数在 256 以内转索引色体积通常砍掉一半以上 if len(colors) 256: im.convert(P, paletteImage.ADAPTIVE, colorslen(colors)).save( ui_asset_opt.png, optimizeTrue )3.3 GIFLZW 字典压缩与帧间只存变化GIF 的 LZW 是一种字典压缩从单字节码长 9 位起步随着新组合出现不断往字典里加条目码长逐步涨到 12 位字典满 4096 条就重置。它的压缩率取决于数据重复模式对索引色数组效果中等。GIF 真正的价值在动画。它把动画拆成“逻辑屏幕 一串图像块 控制扩展”。每个图像块可以只覆盖整个画布的一部分也就是只编码变化区域。这才是 GIF 动图能比逐帧 PNG 小得多的原因。配套的控制扩展块定义了三个关键字段延迟时间单位 1/100 秒、透明索引、以及处置方式disposal method0不指定由解码器决定1保留当前帧下一帧画在上面2画完后还原为背景色3还原为上一帧内容这几种处置方式决定了透明区域的累积行为。很多人做的 GIF 动图出现“残影拖尾”就是因为用了方式 1 又带透明前一帧的内容没被清掉逐帧累积。想做出干净的透明动图要么用方式 2 每帧重置要么老老实实给每帧画全尺寸不透明背景。提示GIF 的延迟时间有个历史包袱——很多早期浏览器把 0 或 1即 0~10ms当作 100ms 处理。要做 10fps 以上的动图延迟字段填小数在很多解码器里会被取整。这是 GIF 动图“看起来卡”的常见原因之一。3.4 一组实测对比同源图三种格式的体积与画质光讲原理没体感。我用一张 1600×1200 的风光照片和一张同尺寸的 UI 界面截图做过对照结果如下数值为多轮测试的典型值具体会随内容波动源图内容格式与参数体积主观画质风光照片JPG Q90 4:4:4620 KB优几乎无差异风光照片JPG Q85 4:2:0310 KB良放大看天空有轻微块状风光照片JPG Q70 4:2:0145 KB中暗部细节明显丢失风光照片PNG-243.9 MB完美UI 截图JPG Q90 4:4:4480 KB差文字边缘有彩色晕UI 截图PNG-24210 KB完美UI 截图PNG-8实际 64 色86 KB完美UI 截图GIF64 色118 KB完美这张表最有说服力的两行是照片存 PNG 是 JPG 的 12 倍体积UI 截图存 JPG 体积反而比 PNG 大画质还更差。所以“照片用 JPG、图标用 PNG”这句口诀不是玄学是数据支撑的最优解。真正需要额外判断的只有中间地带。4. 元数据藏在文件头尾的信息层4.1 JPG 的 APP 段EXIF、XMP 与那个被忽略的方向标记JPG 的文件结构是一串“标记段”marker segment。起始是FFD8SOI结尾是FFD9EOI中间各种FFxx标记承载不同内容标记段名典型内容FFE0APP0JFIF 版本、密度单位FFE1APP1EXIF 或 XMPFFE2APP2ICC 色彩配置文件FFDBDQT量化表FFC0SOF0图像尺寸、通道数FFC4DHT霍夫曼表FFDASOS扫描数据开始FFFECOM注释文本EXIF 是最值得单独说的。它记录的不只是“相机型号 拍摄时间”还包括光圈、快门、ISO、镜头型号、软件版本以及——GPS 经纬度。这个字段是隐私泄露的重灾区。我见过有人把自家阳台拍的照片直接发到公开社区EXIF 里带着精确到米的坐标。EXIF 里还有个特别容易被忽略的字段Orientation方向标记取值 1~8表示图像应该旋转/镜像多少度显示。手机竖拍的图像素数据通常是横向存的靠这个标记告诉查看器“请转 90 度”。问题在于有些老工具、某些服务端处理管线会忽略这个标记导致图片“躺着”显示。这就是“为什么我上传的图在某个平台上方向不对”的根本原因。处理方案有两种一是保留标记指望下游都遵守二是直接把像素旋转到位然后把标记重置为 1。工程上我倾向前者做兼容、后者做保险——读取时按标记旋转写出时清标记。Pillow 有现成支持from PIL import Image, ImageOps im Image.open(phone_shot.jpg) # 按 EXIF 方向标记实际旋转像素 im ImageOps.exif_transpose(im) # 保存时元数据默认不继承方向标记自然被清掉 im.save(fixed.jpg, quality90, subsampling0, exifb)exifb这一句是显式清空 EXIF。如果不写某些 Pillow 版本会把原 EXIF 一起写回坐标就跟着走了。4.2 PNG 的文本块与 GIF 的扩展块另一种信息载体PNG 的块结构非常规整8 字节固定签名然后每个块是“4 字节长度 4 字节类型 数据 4 字节 CRC”。除了必需的 IHDR、IDAT、IEND还允许挂载各种辅助块块类型用途tEXt纯文本键值对ASCIIzTXt压缩文本适合长内容iTXt国际化文本支持 UTF-8pHYs物理像素密度DPIgAMA伽马值iCCP内嵌 ICC 色彩配置tIME最后修改时间tRNS透明信息这些块里tEXt常被各种工具塞进软件名、作者、版权声明。我在做图床项目时统计过一批公开图片超过三成带Software字段能反推出生成工具和版本。这类信息单独看无害但和发布时间、发布者行为关联起来就可能暴露工作流细节。GIF 的结构是“头部 逻辑屏幕描述符 全局颜色表 一系列块”。除了图像块还有三类扩展块0x21 0xF9图形控制扩展含延迟、透明索引、处置方式0x21 0xFF应用扩展最著名的是NETSCAPE2.0用来标记循环次数0x21 0xFE注释扩展可以藏任意文本那个 NETSCAPE2.0 应用扩展块就是“无限循环动图”的开关。它其实是当年某浏览器厂商的私有扩展后来变成事实标准。把它删掉动图在某些环境下只播一次就停。4.3 剥离元数据体积账与合规账元数据该不该留取决于两个账体积账和合规账。体积上EXIF 通常几十 KB带缩略图的能到 100 KB 以上。对于一张 300 KB 的网页图来说这就是三分之一的浪费。更重要的是EXIF 里嵌的缩略图是另一个隐私漏洞——你把大图裁掉一半再发缩略图可能还是完整原图有些工具能把它抽出来。合规上用户上传的图片必须清元数据这几乎是所有平台的默认规则。原因很直接GPS 坐标、设备序列号、软件授权信息都不该跟着图片流出去。清理方式很简单但要用对参数# 命令行工具把所有元数据剥干净同时重编码 magick input.jpg -strip -quality 88 -sampling-factor 4:2:0 output.jpg # 只剥元数据不动像素对 JPG 需重编码实际仍会重压 magick input.png -strip output.pngPython 侧更可控from PIL import Image def strip_meta(path_in, path_out): im Image.open(path_in) # 只保留像素数据不传任何 info/exif 参数 clean Image.new(im.mode, im.size) clean.putdata(list(im.getdata())) clean.save(path_out)这段代码用“重建图像”的方式规避了所有附加信息代价是 PNG 的多帧信息、JPG 的 ICC 配置都会丢。所以生产环境更稳妥的做法是按需保留只保留 ICC 色彩配置否则颜色可能变其余一律清掉。注意事项清 ICC 配置会让带广色域的图在某些显示器上“变灰变淡”。这是我遇到过最迷惑的问题之一——同一张图在一台机器上鲜艳另一台发闷。原因是原图带 Adobe RGB 之类的配置剥离后被当作 sRGB 解释饱和度整体偏移。要跨设备一致标准做法是转换到 sRGB 再剥离而不是直接丢配置。5. 选型决策与问题排查实录5.1 一张表决定用什么格式把前面的内容收敛成可执行的判断流程。拿到一张图按顺序问四个问题判断顺序问题是否1需要动画吗走 GIF 或考虑现代格式继续2需要半透明/羽化边缘吗只能 PNG-32继续3内容是照片级连续色调吗JPGQ 80~88继续4颜色数在 256 以内吗PNG-8 或 GIFPNG-24再补几条经验规则都是踩坑换来的带文字的图一律不用 JPG。8×8 分块的振铃效应会在字符边缘形成毛刺4:2:0 还会加彩色晕。哪怕体积大也要用 PNG。需要缩放的图优先 PNG。JPG 的块效应在放大时会变成明显方格PNG 放大只是变模糊观感好得多。大面积纯色的图用 PNG。DEFLATE 对这种数据效率极高经常比 JPG 更小。带噪点的图用 JPG。噪点破坏 PNG 的重复模式压缩率崩盘。动图帧数少、变化区域小用 GIF帧数多、全屏变化GIF 体积会失控考虑换方案。5.2 常见问题速查与排查思路问题一PNG 转 JPG 后背景变黑。根因是透明像素的 RGB 值被直接保留丢掉 Alpha 后露出底色。修法是合成背景前面给过代码。判断方法用工具查看原图是否有 Alpha 通道如果有必须先合成。问题二图片在浏览器里颜色发灰、发闷。两个可能。一是 ICC 配置被剥离且原图不是 sRGB二是 JPG 用了 CMYK 模式多见于印刷流程导出的图浏览器对 CMYK 的渲染差异极大。排查顺序先看色彩模式再看 ICC 段是否存在。修复方式是统一转换到 sRGB 后再输出。问题三JPG 保存多次后画质雪崩。有损编码的累积误差。每保存一次都重新量化一次高频信息被反复削减。唯一的解法是保留无损源稿所有版本从源稿生成。如果只有成品图可以用工具做一次轻度去块滤波再重存能缓解但不能恢复。问题四GIF 动图在某处播放速度不对。延迟字段的单位是 1/100 秒且很多解码器对小于 2 的值做特殊处理。另外不同平台对“帧延迟为 0”的理解不一致。稳妥做法是延迟不小于 5即 50ms20fps 上限且帧数不要太极端。问题五同一张图在不同平台体积差很多。平台侧通常有二次压缩。上传后体积变小但画质下降说明服务端按固定参数重编码了。对抗方式只有提高源图质量余量——比如源图存 Q92 而不是 85让二次压缩后仍有可接受画质。但要注意源图质量设太高有时反而会让二次压缩的体积变大因为服务端按质量参数压输入细节越多输出也越大。这个平衡点需要按平台实测。问题六PNG 文件体积莫名其妙地大。先查三件事实际颜色数能不能降到索引色、是否带 16 位深度很多专业软件默认导出 16 位通道体积翻倍但肉眼无差、是否嵌了大块元数据。这三项通常能砍掉一半以上。5.3 我个人的几条硬规矩做了这么多年图和优化有几条已经变成条件反射第一任何进入版本库的图都必须是无损源 脚本化导出。手改参数、手点导出三个月后没人记得当时用的什么配置出了问题无法复现。我会给每个项目写一个导出脚本参数写死在代码里。第二体积优化永远先测量再动手。我见过太多人凭感觉把 Q90 改成 Q60体积降了一半但画质崩了其实改成 85 就能拿到 70% 的收益。正确的做法是把 Q 从 95 到 60 扫一遍画出体积曲线找拐点。第三别迷信“无损就更好”。PNG 无损但一张 4 MB 的 PNG 换成 300 KB 的 JPG在列表页缩略图场景下用户根本看不出差别加载速度却是天壤之别。格式选择永远是画质、体积、场景三者的平衡不是技术优越性的比拼。第四元数据默认清空需要时显式加回。这条规矩救过我一次——某次批量处理图片时发现部分图的 EXIF 里带着内部测试环境的路径信息如果直接对外发布就是信息泄露。从那以后所有对外输出管线都强制经过一道元数据清理。第五保留一份原始文件永远不要在原图上做破坏性编辑。这条听起来像废话但真到了赶进度的时候最容易犯的错就是“先转成 JPG 再说”。等发现要改的时候源稿已经没了。最后分享一个我常用的小技巧收尾判断一张 JPG 被压过几次、质量大概多少可以看它的量化表。量化表里高频位置的数值越大说明压缩越狠。用脚本把 DQT 段读出来打印成 8×8 矩阵粗略就能反推质量区间。这个办法在处理别人给的素材时特别有用——你不用猜直接看文件的“指纹”就知道它经历过什么。