JPEG压缩原理解析与实战优化：量化表、编码器与保存策略

你有没有过这种经历：一张照片在相机里看锐利通透，天空的渐变也很自然，发完朋友圈再点开大图，边缘就像蒙了一层薄纱，天空还隐隐出现一道一道的横纹。大部分时候问题不在手机，而在一种已经用了三十多年的老格式——JPEG。

JPEG全称Joint Photographic Experts Group，1986年成立，1992年发布第一版标准。到今天，数码相机、网页、社交媒体的默认输出几乎全被它包揽。围绕它的争议也不小，有人嫌它有损、越存越糊，但实际上大多数人并没有真正搞清楚它到底损在哪、怎么损的。如果你做数字图像处理相关的工作，或者平时会批量处理照片、搭图片服务，把JPEG的原理摸透，能帮你少踩很多坑。

这篇文章我不打算把ISO/IEC 10918-1标准从头过一遍，那读起来像天书。我按自己这些年处理图片的经验，把JPEG从原理到文件结构再到实战保存策略，拆成几个能直接上手的部分。文里涉及的数据和流程我都实际验证过，你可以放心参考。

1. JPEG做了哪些"偷懒"决定：三处关键的信息丢弃

JPEG之所以能做到极高的压缩比，一台相机拍出来的12MB原图能压到2~3MB，甚至更小，靠的不是某个单一技巧，而是三处层层递进的"信息丢弃"。这三处丢弃都是在对人眼视觉系统做了深入研究之后设计的，本质上是在迎合你眼睛的"感知偏好"。

1.1 颜色空间转换：为什么要把RGB拆成亮度色度

日常显示设备用的是RGB三通道，每个像素的红、绿、蓝各占8比特，共24比特。但JPEG编码的第一步，就是把RGB转换到YCbCr颜色空间。Y是亮度分量，Cb和Cr是两个色度分量，分别表示蓝色差和红色差。转换公式是：

code复制Y  =  0.299R + 0.587G + 0.114B
Cb = -0.1687R - 0.3313G + 0.5B + 128
Cr =  0.5R - 0.4187G - 0.0813B + 128

为什么非要换颜色空间？因为人眼对亮度的敏感程度远高于对颜色的敏感程度。你回想一下：大晚上路灯下看不清路人穿的是什么颜色的衣服，但你一眼就能看出那是个人——这就是亮度信息远比色度信息重要。把亮度单独抽出来，接下来就可以对不同分量区别对待，把精力集中在保留亮度细节上，色度细节则可以适当放水。

这个转换本身是固定的矩阵运算，不会损失信息，但它为后面"偷懒"创造了条件。现实中很多图像处理库在解码JPEG时会直接输出YCbCr数据，你转回RGB显示的时候会发现边缘略微有点偏色，这就是在色度分量上放水留下的痕迹。

1.2 色度下采样：人眼的天然漏洞

第二步是色度下采样，也叫色度抽稀。前面提到人眼对色度不敏感，所以JPEG允许把Cb和Cr分量的分辨率降低一半甚至更多。最常见的采样格式有四种：

你手机拍出来的JPEG，绝大多数是4:2:0。也就是说，色度信息其实只有亮度信息的四分之一。一张800x600的照片，亮度分量要存800x600个数值，而色度分量只需要存400x300个数值，三个通道加起来的信息总量直接从原来的三倍变成一点五倍。压缩还没正式开始，数据量已经打了一个六折。

这也是为什么有些摄影师在后期时会觉得JPEG的颜色"不够扎实"：不是相机传感器不行，而是JPEG的采样机制本身就是以牺牲色度细节为代价换空间。

1.3 8x8分块：JPEG的基本操作单元

JPEG对每个分量（Y、Cb、Cr）都按8x8像素的小块为单位处理。为什么选8x8而不是16x16或4x4？这是基于对自然图像相关性的统计研究得出的折中方案——块越大，去相关效率越高，但局部细节的适应性越差；块太小，DCT变换的频域集中性不够，压缩率上不去。

你打开一张JPEG调试信息，能看到"MCU"（最小编码单元）这个词。在4:2:0采样下，一个MCU由四个Y块、一个Cb块、一个Cr块组成，对应原图的16x16像素区域。这个结构的直接后果是：任何JPEG的压缩操作都要按这个块网格进行，一旦块边界处的处理不当，就会留下"方格"痕迹。

注意，这里有两个方向的问题：一是编码时如果某个块的内容和周围差异太大，解码还原后块边界可能肉眼可见；二是编辑JPEG时，如果旋转了任意角度或者裁切尺寸不是16的倍数，解码器强制对齐到新的块网格，又会产生新的误差。后面讲块效应的时候我会再细说。

2. 编码流水线拆解：DCT变换、量化、Z字扫描到熵编码

理解了JPEG在哪些地方"故意丢信息"之后，我们顺着编码器的执行顺序走一遍完整的流水线。方便起见，这里以灰度图为例——一张灰度图只有一个亮度通道，没有色度下采样，这样拆解最清晰。

2.1 DCT：从像素到频率成分

拿到一个8x8的像素块后，JPEG对它做离散余弦变换。DCT的输出同样是一个8x8的系数矩阵，但含义从"每个位置的亮度值"变成了"每个频率成分的幅度"。变换后，左上角那个数是直流系数（DC），代表整个块的平均亮度；往右下走，横纵频率越来越高，代表越来越细的纹理细节。

DCT公式本身是二维可分离的，实际实现里先对行做一维DCT再对列做一维DCT，时间复杂度可以接受。它的核心价值在于能量集中：自然图像的大多数像素块在变换后，能量全部集中在左上角少数几个低频系数上，右下角的高频系数普遍趋近于零。这正是后续压缩能够下手的地方。

可以这样直观理解DCT的作用：如果原8x8块是一片蓝天，DCT后左上角的DC系数是一个很大的数，其余系数几乎全是零；如果原8x8块是密密麻麻的树叶，DCT后高频系数就会有较多非零值。一片区域越平滑，变换后越容易用一个或几个系数表达完整块——这就是"变换编码"的魔力。

JPEG标准里还规定了DCT的精度问题，标准规定DCT输入经过电平偏移，把无符号的[0, 255]变成有符号的[-128, 127]，避免直流偏置影响变换效率。这个细节不在位流里，但解码端需要对称地加回128，否则画面整体偏暗或偏亮。你要是自己实现编码器，电平偏移是最容易忽略的第一步。

2.2 量化：压缩点全在这里

DCT之后，每个8x8块得到64个频率系数，大部分数值还很大。量化这一步就是对每个系数除以对应的量化步长再取整，公式是：

code复制量化后的系数 = 四舍五入( DCT系数 / 量化步长 )

量化步长放在一个8x8的量化表里，表里每个位置对应DCT系数矩阵的每个频率。低频位置的量化步长小，高频位置的量化步长大，因为高频成分对人眼的贡献小，可以更粗暴地丢弃。

这一步是JPEG唯一的真正有损环节。DCT本身是无损变换，色度下采样确实丢了信息，但量化才是让高频系数变成零的"大砍刀"。量化步长越大，被置零的系数越多，压缩率越高，但还原图像的细节损失也越严重。其他所有环节——颜色空间转换、DCT、熵编码——都是可逆的，理论上逆变换能完全还原原始值。

这里有一个非常关键的直觉：JPEG的"损"不是随机的噪点，而是系统性的高频细节丢失。一块平滑的天空可以完美还原，一片密集的草地、头发、树叶这类高频纹理丰富的区域，还原后要么糊成一团，要么出现人工痕迹。所以评价一张JPEG压缩得好不好，把画面放大看纹理最集中的区域就能看出来。

2.3 Z字扫描、游程编码与Huffman

量化之后，64个系数中高频位置大概率变成零。JPEG按Z字形顺序把二维系数矩阵拉成一维序列，从左上角的DC系数出发，按对角线方向遍历到右下角。为什么要Z字扫描？因为自然图像的能量集中在低频，经过量化和Z字排序后，非零系数都聚在序列前部，后面跟着一长串零。这种排列对游程编码非常友好。

游程编码统计每个非零系数前面有多少个零，比如"0, 0, 0, 5"就编码成"跳过3个零，值为5"。Z字扫描之后，序列尾部的连续零会特别长，用"块结束"标记（EOB）一口气表示，见一个EOB就能结束当前块，彻底省掉后面的零。

最后一步是Huffman编码（标准也允许用算术编码，但实际产品几乎不用）。JPEG的Huffman表分成两类：一类给DC系数用，一类给AC系数用。DC系数采用差分编码，当前块的DC值减去上一个块的DC值再编码，利用相邻块亮度相近的特点让差值集中在零附近；AC系数则把"游程+非零值大小"组合成一个符号来查表。查表的结果是变长码，高频出现的东西用短码，低频出现的东西用长码，整体数据量进一步下降。

这一整套编码流程走完，原始图像才能变成一串紧凑的二进制流。你如果手动写一个编码器，最繁琐的不是DCT，而是Huffman表的构建和位流的写入——位流的每一位都必须精确对齐，差一个bit解码端就错乱。

3. 量化表是JPEG画质的真正闸门

很多人使用JPEG只知道"质量"或者"quality"这个参数，往深一层就说不清了。实际上quality不过是编码器根据一个默认量化表按比例缩放后得到的量化表，真正决定画质的是量化表本身。搞懂量化表，你就掌握了JPEG调优的命门。

3.1 量化矩阵长什么样

JPEG标准在附录K里给出了一组推荐的量化表，亮度表和色度表各一张。以亮度量化表为例：

code复制16  11  10  16   24   40   51   61
12  12  14  19   26   58   60   55
14  13  16  24   40   57   69   56
14  17  22  29   51   87   80   62
18  22  37  56   68  109  103   77
24  35  55  64   81  104  113   92
49  64  78  87  103  121  120  101
72  92  95  98  112  100  103   99

可以看到右下角的量化步长明显比左上角大，这就是"高频让它更糙一点"的具体体现。第三行第三列是16，而第八行第一列是72——同是8x8块里两个系数，被舍弃的容易程度差了四倍多。这张表对应的就是quality=50左右的压缩水平，是个很好的参考基线。

标准推荐的表并非不可更改，每个编码器都可以自定义量化表。比如mozjpeg就重新设计了一套更贴合人眼视觉的量化表，同样是quality=75，它的画质主观感受比老libjpeg好一截。文件里存的量化表就在DQT段里，解码时必须按文件里的表来反量化，否则画面全乱。

3.2 质量因子与量化表的换算

libjpeg是整个生态使用最广泛的参考实现。它内部维护了一张默认量化表，然后根据传入的quality参数做缩放。我翻过它的源码，核心逻辑是这样的：

• 如果quality在1到50之间：缩放比例 = 5000 / quality
• 如果quality在50到100之间：缩放比例 = 200 - 2 * quality

缩放后每个量化步长都乘以这个比例，再上下取整保证落在1到255之间。quality=100时，比例是0，理论上量化步长都变成1，也就是无损量化，但JPEG在有损环节上依然有DCT精度损失和色度下采样，所以即使quality=100也不是无损压缩。

举几个常见数值对照一下：

注意，缩放比例越小，量化表里的数值越小，被保留的系数越多，文件越大。反过来，quality太低时，量化步长巨大，一个高频系数可能直接除以一百多变成零，画面细节大量丢失。

3.3 quality=100不等于无损

上面提到quality=100时，量化步长全为1，为什么还不是无损？原因有三个：一是色度下采样仍然存在，4:2:0会让色度分辨率减半；二是DCT变换本身有浮点精度问题，虽然用整数DCT可以规避，但标准允许的实现误差始终存在；三是色度分量的量化表在quality=100时也并非全为1，因为编码器会对色度表做不同的缩放。

如果你需要"无损"地保存一张图的像素数据，就不要用JPEG，直接用PNG或者无损WebP。JPEG的哲学从来就不是像素级无损，而是"视觉上够用"。

我遇到过不少设计师，导出图片时一律选100质量，觉得这样才能"原汁原味"。实际上100质量的文件体积比90大很多，但肉眼几乎看不出差别。这种不划算的用法在批量存储场景里会白白浪费大量磁盘空间。按我的经验，线上展示的JPEG用quality=80到85就能覆盖绝大多数场景，不需要更高。

4. JPEG文件结构探秘：从文件头到像素数据的字节巡游

JPEG不是一个简单的"数据块"，它有严格的段结构。你随便打开一个.jpg文件，用十六进制工具看一眼，开头必然是FF D8，结尾必然是FF D9。这两字节分别叫SOI标记和EOI标记，相当于文件的"开始"和"结束"。

4.1 用二进制视角看JPEG：段标记与文件结构

JPEG文件由一系列标记段组成，每个标记段以FF开头，后面跟一个字节的标记码。常见的标记码如下：

• FFD8：SOI，文件开头
• FFE0：APP0，存JFIF版本、分辨率、缩略图
• FFE1：APP1，最常见的是存Exif拍摄参数
• FFDB：DQT，存量化表
• FFC0：SOF0，存图像宽高、量化精度、分量信息
• FFC4：DHT，存Huffman表
• FFDA：SOS，扫描开始，后面跟着压缩图像数据
• FFD9：EOI，文件结束

以一张手机拍的图为例，用十六进制编辑器看，通常顺序是FFD8后面紧跟FFE1（Exif），然后FFDB（量化表），FFC0（基础帧参数），FFC4（Huffman表），最后FFDA进入图像数据。不同的编码器排列顺序会有差异，但整体结构一致。

FFC0段里有一个字节表示每个分量的采样因子（sampling factor），Y分量是0x22，Cb、Cr是0x11，说明Y方向上下左右都采样两份、色度只采样一份——这就是4:2:0采样在文件层面的体现。

这里有个常见的坑：你拿一个.jpg直接改扩展名成.png，文件并不会变成PNG。解码器检查文件头时，看到FFD8就知道这是JPEG，不会理会扩展名。反之，一个PNG文件开头是89 50 4E 47，所以判断一个图片到底是什么格式，永远要看文件头，不要看扩展名。

4.2 从段标记看参数：哪些数据藏在JPEG里

除了图像数据，JPEG文件里还藏了很多"额外负担"。APP0段（JFIF）会写分辨率和缩略图；APP1段（Exif）会写相机型号、镜头参数、拍摄时间、GPS信息等。对于隐私敏感的场景，比如你要把照片传到论坛上，务必要清理Exif信息，否则就可能泄露拍摄位置。用Python处理的话，Pillow的Image.open配合img.getexif()就能读取，清理则可以用piexif库把exif字典设为空再保存。

更值得关注的是Huffman表和量化表，它们直接决定了解码端如何还原数据。JPEG解码器读取文件时，必须严格按DQT段里的量化表做反量化、按DHT段里的Huffman表做熵解码。如果你把一张标准编码器的JPEG的DHT段删掉，解码器会直接报错。

注意有些JPEG用了渐进式编码（progressive JPEG），这种文件的SOS段会出现多次，数据分多个扫描层次。浏览网页时那种"先模糊后清晰"的加载效果，就是渐进式JPEG在起作用。这个特性对网速不友好的环境很实用，但老一些的解码器可能会有兼容性问题。

4.3 编辑与再保存：为什么要转存

JPEG解码后是像素矩阵，编码时重新分块做DCT，这意味着每次编辑后保存，都会在原始压缩损失的基础上叠加新的损失。有实验表明，同一张图连续保存50次quality=90的JPEG，文件大小变化不大，但画质会稳步下滑。因为每次保存都会经历一次有损量化，误差会在局部边缘积累。

我自己做过一个测试：用一张有大量文字边界的截图，以quality=80反复保存5次，到第三次开始边缘出现明显的"光晕"，第五次时细节区域已经有可见的块状模糊。如果你要反复编辑，请务必用无损格式作为工作格式（如PNG或TIFF），最后导出JPEG时再转一次即可。

5. 换一种编码器，质量能差多少：libjpeg、mozjpeg与WebP对比

JPEG是一种格式标准，但实际编码器的实现可以千差万别。标准只规定了位流和熵编码的合法性，并没有规定编码时量化表必须怎么设计、Huffman表必须怎么优化。于是同样一张图，用不同编码器、同样的quality值，压缩出来的文件大小和画质可以有明显差距。

5.1 JPEG编码器与解码器的差异

这里要分清编码器和解码器。解码端必须严格按位流来还原，几乎没什么操作空间；编码端则完全不同，编码器可以选择不同的颜色空间转换系数、不同的量化表、不同的Huffman表优化策略，甚至可以在量化前后做一些额外的视觉优化。

最经典的老牌参考实现是libjpeg，由于历史原因其量化表设计是在上世纪末完成的，放到今天的屏幕上看并不是最优的。libjpeg-turbo是SIMD加速版，计算速度极快，但算法基本还是沿用libjpeg的思路，画质上没有本质变化。

Google的mozjpeg在libjpeg-turbo基础上重新设计了量化表，引入了trellis quantization（格状量化），把量化过程当成一个率失真优化问题来求解，同样quality下文件更小、主观画质更好。Cloudflare和很多CDN在优化图片时都用它。我在实际项目里对比过，同样肉眼可接受的质量水平，mozjpeg比libjpeg省下约10%~25%的体积——别小看这个数字，在图片流量很大的网站上是实打实的成本。

另一个极端是Google的Guetzli，它追求的是在低文件大小下人眼感知上更接近原图，思路是把人类的视觉感知模型建模进编码过程。效果确实好，但编码速度极慢，一张普通照片可能要跑几十秒甚至几分钟，不适合在线流程，只适合离线全量压缩。

5.2 不同编码器实测对比

我拿一张分辨率4000x3000的实拍照片做了一组测试，条件完全相同，只看编码器差异，结果如下：

这只是单次测试，不同图像内容差异可能很大，但趋势是明确的：在兼容JPEG的前提下，换用更现代的编码器能白赚不少体积。如果你的图片处理链路是你自己控制的，建议直接把libjpeg换成mozjpeg，API兼容性几乎一样，收益却立竿见影。

5.3 新的竞争对手：WebP、AVIF、JPEG XL

JPEG虽然老了，但生态极其庞大，十几年积累的硬件解码头、浏览器支持、图像库兼容性不是说换就换的。不过现代Web场景里，WebP和AVIF已经逐渐普及。

WebP在无损和有损两档都有优势，无损模式比PNG小20%~30%，有损模式同质量下比JPEG小20%~35%。AVIF基于AV1编码，压缩率更高，但编码速度也慢，适合静态图片资源。JPEG XL则是近年新出的格式，号称兼容JPEG解码，又支持无损和有损，比JPEG压缩率高不少，但浏览器普及度还不算高。

工具链方面，如果你只是想把图片转成WebP或AVIF，用ImageMagick或者libvips就能一条命令搞定：

bash复制# 转成WebP，质量80
cwebp -q 80 input.jpg -o output.webp

# 转成AVIF，质量80
avifenc --min 1 --max 63 -s 10 input.jpg -o output.avif

我的建议是：如果你的用户群体基本在主流浏览器上，且图片资源量大，完全可以把JPEG的CDN换成WebP/AVIF双格式，兼容旧设备时再兜底回退JPEG。

6. 最常见的画质损伤，以及一条务实的保存策略

技术原理聊了不少，最后落到大家最关心的实际问题：JPEG画质损伤长什么样？怎么尽量避免？以及遇到不该用JPEG的场景该怎么选。

6.1 块效应与振铃：JPEG的两大画质缺陷

块效应是最容易看出的JPEG伪影，表现为8x8块边界处出现肉眼可见的网格。它的本质是量化误差在每个块内的分布不一致，导致相邻块的像素值在边界上不连续。低quality、强压缩、底色均匀的天空或墙面区域，块效应最容易暴露。

振铃效应（ringing）出现在高对比度边缘附近，比如白纸上的黑字、窗框边缘。压缩后这些边缘周围会出现一圈一圈的涟漪状条纹，原理是高频系数被截断后，DCT逆变换在边缘区域产生过冲震荡。从信号处理角度理解，就像你用低通滤波器滤掉高频，阶跃信号附近自然会震荡。

还有一种常见伪影叫"蚊子噪声"，本质是振铃效应在视频编码里的表现，画面高细节区域看起来有蚊虫一样的噪声在闪烁。这些伪影没有特别好的修图办法，只能在编码阶段尽量降低量化步长，或者换用滤波后处理。

6.2 世代损失：反复保存会发生什么

"世代损失"这个概念借用录音磁带翻录时的术语，指每次复制保存都引入新的损耗。JPEG每次保存都有量化误差，虽然误差不算大，但反复保存后误差会积累。

我自己实际操作下来，图像细节多的照片反复保存5次以上才会看到可察差异，但纯色渐变区域在第3次就能感觉到色阶断裂。原因在于渐变区域在低频上能量集中，量化误差每一次保存都局部放大，最后形成肉眼可见的条带。

如果你要从JPEG里裁剪一小块区域再保存，更要注意：解码后整张图存在内存里，裁切后输出JPEG时，新生成的块网格和原来的块网格不对齐，边界处会再次损失。正确做法是，裁剪和调整操作在无损中间格式上完成，最后一次输出JPEG。专业修图软件里"存储为"底层逻辑就是这样的，但很多浏览器扩展或简易截图工具不会缓存中间态，你每按一次保存就多一次损耗。

6.3 什么场景不该用JPEG

JPEG虽然万能，但有些场景是它的死穴：

• 文字截图：文字边缘锋利，高频成分极重，JPEG压缩后文字边缘会有明显脏边和振铃。截图工具输出的PNG通常比JPEG小，且更清晰。
• 线条图、CAD图、灰度图纸：这类图像颜色少、细节锐利，PNG无损压缩后体积也不大。
• UI图标、Logo、带透明通道的图：JPEG没有alpha通道，直接排除。
• 需要二次编辑的原图：存档格式选PNG、TIFF或相机原始格式（RAW），而不是JPEG。

有一个简单的经验法则：如果你的图色彩层次丰富、内容连续自然，JPEG非常合适；如果图里包含大量锐利边缘、文字、纯色块，优先用PNG或WebP无损模式。

6.4 务实的保存策略

结合上面的原理，我总结一套切实可用的保存策略，适用于大部分内容处理流程：

1. 原始素材一律保留无损格式或相机RAW，不拿JPEG做原始存档。
2. 工作过程中编辑的中间文件用PNG、TIFF或无损WebP，所有裁剪、调色、滤镜都在这个阶段完成。
3. 最终交付或上线的文件再转成JPEG，质量值选80~85，根据内容类型微调。
4. 如果图片存储空间紧张，优先考虑mozjpeg或WebP/AVIF替换，而不是单纯调低quality。
5. 批量处理时用libvips或ImageMagick的批处理能力，能直接读取源格式输出目标格式，避免中间反复解码编码的损耗。

这套策略听起来简单，实际落地能省下大量存储成本，同时稳定保证用户看到的图片质量。我在多个线上图片服务上按这个思路做过改造，效果都很明显。

最后分享一个排查JPEG问题的小技巧：如果你怀疑一张在线图片压缩过头，把文件下载下来，用十六进制工具查看它的DQT段里的量化表数值。如果量化表里出现了大量200以上的步长，说明压缩率非常高，画质受损是必然的，这时应该找原始素材重新压缩，而不是继续在压缩后的图上二次处理。图像处理的核心从来不是学会了多少滤镜和算法，而是能在正确的时间选对正确的格式与参数。JPEG作为一个有三十年历史的老家伙，原理虽深，但掌握好这几个关键环节，就能让它为你的图片服务发挥出最大价值。