📚 课程目录第3章 JPEG 编码基础

3、JPEG 编码基础：格式原理、色彩空间转换与质量因子

JPEG（Joint Photographic Experts Group）是 Android Camera 系统中最核心的静态图像编码标准。无论是 HAL 层调用软件编码器（如 libjpeg、libjpeg-turbo），还是通过硬件 JPEG 引擎（如 Qualcomm 的 JPEG Encoder、MediaTek 的 ISP 内嵌编码器），其底层都遵循同一套编码范式：色彩空间转换、离散余弦变换（DCT）、量化、熵编码（霍夫曼编码）。理解这套流水线，是后续分析 HAL 层编码器性能瓶颈、调试图像质量、优化编码延迟的前提。本章将从 JPEG 的编码链路出发，深入拆解每个环节的数学原理与工程实现，并重点剖析质量因子（Quality Factor）如何影响输出大小与主观画质。

3.1 JPEG 格式原理与编码流水线

JPEG 是一种有损压缩标准，其核心思想是利用人眼对亮度变化敏感、对色度变化不敏感，以及对高频细节不敏感的特性，在频域中丢弃人眼不易察觉的信息。Android Camera 的 JPEG 编码器（无论是 HAL 层的软件实现还是硬件 IP）都遵循 ISO/IEC 10918-1 标准。完整的编码流程包括：色彩空间转换（RGB→YCbCr）、色度下采样（4:4:4→4:2:0）、8×8 分块、DCT 变换、量化、Zig-Zag 扫描、差分编码（DC 系数）与游程编码（AC 系数）、最后进行霍夫曼熵编码。

在实际的 Android HAL 实现中，编码器通常接收来自 ISP（图像信号处理器）的 YUV 数据，而非原始 RGB。这是因为 ISP 已经完成了去马赛克、白平衡、降噪等处理，输出格式通常为 NV21 或 NV12（均为 YUV420 的变体）。编码器需要正确处理 YUV 数据的存储布局——NV21 的 U/V 分量交错排列（V 在前），而 NV12 则是 U 在前。如果 HAL 层错误地将 NV21 当作 NV12 处理，会导致输出图像出现严重的颜色错乱。

  工程要点：在 HAL 层集成 JPEG 编码器时，务必确认 ISP 输出的 YUV 格式与编码器期望的输入格式一致。例如，Qualcomm 的硬件 JPEG 引擎通常支持 NV12 输入，而部分软件编码器默认接受 NV21。格式不匹配时，需要在编码前插入一个格式转换步骤，这会增加额外的内存拷贝和延迟。

3.2 色彩空间转换：从 RGB 到 YUV420/NV21

色彩空间转换是 JPEG 编码的第一步，其数学本质是一个 3×3 的线性变换矩阵。标准 BT.601 转换公式如下：

Y  =  0.299R + 0.587G + 0.114B
Cb = -0.169R - 0.331G + 0.500B + 128
Cr =  0.500R - 0.419G - 0.081B + 128

转换后，Y（亮度）分量保留全部分辨率，而 Cb/Cr（色度）分量进行下采样。YUV420 表示每 2×2 的 Y 像素块共享一个 Cb 和一个 Cr 采样点，因此色度数据量仅为亮度的 1/4。NV21 是 YUV420 的一种内存布局：先存储全部 Y 数据，然后交错存储 V 和 U 数据（V 在前）。这种布局在 Android Camera 中极为常见，因为它是 Camera2 API 的默认输出格式之一。

格式	Y 分辨率	U/V 分辨率	内存布局	常见场景
YUV420 (I420)	W×H	W/2 × H/2	Y 平面 + U 平面 + V 平面	视频编码输入
NV21	W×H	W/2 × H/2	Y 平面 + VU 交错	Camera 预览/拍照
NV12	W×H	W/2 × H/2	Y 平面 + UV 交错	硬件编码器输入
YUV444	W×H	W×H	三个独立平面	高质量图像处理

在 HAL 层实现中，色彩空间转换通常由 ISP 硬件完成，软件编码器接收到的已经是 YUV 数据。但若使用纯软件编码路径（如调试模式），则需要手动实现 RGB→YUV 转换。此时应使用整数运算替代浮点运算以提升性能，例如将系数乘以 256 后取整：

Y  = (77*R + 150*G + 29*B) >> 8
Cb = (-43*R - 85*G + 128*B + 32768) >> 8
Cr = (128*R - 107*G - 21*B + 32768) >> 8

风险提示：色彩空间转换中的舍入误差会导致颜色偏移。在 Android 的 Camera HAL 中，如果发现 JPEG 输出偏绿或偏紫，首先检查转换矩阵是否正确，其次检查 YUV 的偏移量（通常为 128）是否被正确添加。此外，BT.601 与 BT.709 矩阵不可混用，否则在宽色域场景下会出现明显的饱和度异常。

3.3 DCT 变换与量化：频域中的信息取舍

DCT（离散余弦变换）将 8×8 像素块从空间域转换到频域。变换后，左上角为 DC 系数（代表块内平均亮度），其余 63 个为 AC 系数（代表不同频率的细节）。人眼对高频信息不敏感，因此高频 AC 系数可以被更粗地量化。标准 DCT-II 公式为：

F(u,v) = (1/4) * C(u) * C(v) * ΣΣ f(x,y) * cos[(2x+1)uπ/16] * cos[(2y+1)vπ/16]

其中 C(0)=1/√2，C(u>0)=1。在实际编码器中，DCT 通常通过快速算法（如 AAN 算法）实现，硬件编码器则直接使用蝶形运算单元。

量化是 JPEG 有损压缩的核心步骤。每个 DCT 系数除以量化表中对应的步长，然后四舍五入取整。量化表由质量因子（QF）决定，标准 JPEG 库（如 libjpeg）提供默认的亮度/色度量化表，并通过缩放因子调整：

// libjpeg 内部逻辑（简化）
scale = (QF < 50) ? 5000/QF : 200 - 2*QF;
quant_table[i] = (base_table[i] * scale + 50) / 100;
quant_table[i] = clamp(quant_table[i], 1, 255);

QF 越高，量化步长越小，保留的细节越多，文件越大；QF 越低，量化步长越大，高频系数被大量清零，文件显著减小但出现块效应和振铃效应。

经验值参考：在 Android Camera 默认设置中，QF=85 是“高质量”与“文件大小”之间的常用平衡点。对于文档扫描类应用，QF=70 即可满足 OCR 需求；对于专业摄影应用，QF=95 以上可减少可见压缩伪影，但文件大小会急剧增加（一张 12MP 照片可能超过 8MB）。

3.4 霍夫曼编码与 Zig-Zag 扫描

量化后的系数矩阵中，大量高频系数变为 0。为了提升压缩率，JPEG 采用 Zig-Zag 扫描将二维系数矩阵转换为一维序列，使得连续的 0 尽可能集中。随后，DC 系数使用差分编码（与前一块的 DC 差值），AC 系数使用游程编码（连续 0 的个数 + 非零值）。最后，这些符号通过霍夫曼编码映射为变长码字。

霍夫曼编码表是 JPEG 标准的一部分，分为标准表（供基线模式使用）和自定义表（供扩展模式使用）。Android 的硬件 JPEG 引擎通常内置标准霍夫曼表，而软件编码器（如 libjpeg-turbo）允许自定义表以优化特定图像的压缩率。霍夫曼编码的核心原则是：出现频率高的符号分配短码字，出现频率低的符号分配长码字。

// Zig-Zag 扫描顺序（前 16 个位置）
0, 1, 8, 16, 9, 2, 3, 10,
17, 24, 32, 25, 18, 11, 4, 5, ...

在 HAL 层调试中，如果 JPEG 文件无法解码或解码后图像错位，常见原因是 Zig-Zag 扫描顺序实现错误，或霍夫曼表与编码数据不匹配。硬件编码器通常不会出现此类问题，但软件编码器在移植到新平台时需格外注意字节序（大端/小端）和位填充逻辑。

3.5 质量因子对图像大小与画质的影响

质量因子（QF）是 JPEG 编码器最常用的控制参数，其取值范围为 1-100。QF 直接影响量化表的缩放，进而影响压缩比和画质。以下是一张 12MP（4000×3000）照片在不同 QF 下的实测数据：

质量因子	量化缩放	文件大小	压缩比	主观画质	典型场景
95	10	6.2 MB	5:1	几乎无损	专业摄影
85	30	3.1 MB	10:1	优秀	默认拍照
70	60	1.8 MB	17:1	良好	社交分享
50	100	1.1 MB	27:1	可接受	缩略图
20	160	0.5 MB	60:1	明显块效应	预览/调试

从表中可以看出，QF 从 95 降到 85，文件大小减少约 50%，而画质损失几乎不可察觉；但从 50 降到 20，文件大小仅减少约 55%，画质却急剧下降。这是因为量化表在低 QF 区间已经趋于饱和，继续降低 QF 只会增加块效应而不会显著减小文件。

  工程调优建议：在 Android HAL 层设置 JPEG 质量时，不要简单地使用线性映射。建议采用分段策略：当目标文件大小优先时，使用 QF=75-80；当画质优先时，使用 QF=90-92；当内存/带宽受限时（如连拍模式），使用 QF=60-65。同时，应结合分辨率动态调整——高分辨率图像对 QF 降低的容忍度更高，因为块效应在缩放后不易察觉。

3.6 实战案例：HAL 层 JPEG 编码器集成中的画质与性能调优

背景：某 Android 设备在集成第三方硬件 JPEG 编码器时，遇到两个问题：一是 12MP 拍照时编码延迟高达 450ms（目标 <200ms）；二是输出图像在暗光场景下出现明显的色彩噪点。

初始现象与数据：通过 systrace 抓取编码器运行时间，发现硬件编码器本身仅耗时 80ms，但 ISP 输出到编码器输入之间的格式转换（NV21→NV12）耗时 250ms，且使用了低效的逐像素拷贝。图像质量方面，在 ISO 3200 下拍摄，JPEG 输出中的色度噪点比 YUV 预览数据明显增多。

分析过程：首先，格式转换的瓶颈在于内存访问模式——NV21 的 VU 交错布局导致读取时缓存命中率低。其次，色度噪点问题源于编码器内部的色度下采样滤波器过于简单，未对高频色度噪声进行抑制。

解决方案：

将格式转换改为 NEON 优化版本，使用 16 字节对齐的批量拷贝，延迟从 250ms 降至 45ms。
在 ISP 侧增加色度低通滤波（3×3 均值滤波），在编码前抑制色度噪声。
将 QF 从默认的 90 调整为 85，在暗光场景下文件大小减少 20%，且主观画质无明显下降。

结果对比：优化后编码总延迟降至 180ms，满足目标；暗光场景下的色度噪点减少约 60%，用户主观评价“画面更干净”。

风险与代价：色度滤波会轻微损失色彩细节（如红色文字边缘），但在此场景下可接受。QF 调整后，在极端高对比度场景下可能出现轻微振铃效应，需通过后续软件算法补偿。

复盘要点：JPEG 编码器的性能瓶颈往往不在编码本身，而在数据通路（格式转换、内存拷贝）。在 HAL 层集成时，应优先检查数据流路径，避免不必要的格式转换。同时，质量因子的选择应结合场景（暗光/高 ISO）动态调整，而非固定不变。

3.7 常见误区与总结

误区一：认为 QF 越高越好。实际上，QF 超过 95 后，文件大小急剧增加但画质提升微乎其微，因为传感器噪声和 ISP 处理误差已经掩盖了压缩损失。

误区二：混淆 YUV420 与 NV21/NV12 的关系。YUV420 是采样格式，NV21/NV12 是内存布局。HAL 层代码中经常出现“将 NV21 当作 YUV420”的错误描述，导致调试时方向错误。

误区三：忽略量化表的平台差异。不同硬件编码器的默认量化表可能不同，即使 QF 相同，输出文件大小和画质也可能有显著差异。在跨平台对比时，应使用标准量化表或明确标注编码器型号。

误区四：在低 QF 下期望无损输出。JPEG 永远是有损的，QF=100 也不等于无损。对于需要无损的场景，应使用 PNG 或 WebP 无损模式。

总结而言，JPEG 编码器的集成不仅是调用一个编码接口，更需要对色彩空间、DCT、量化、熵编码的完整链路有深入理解。在 Android HAL 层，质量因子的选择、YUV 格式的处理、以及数据通路的优化，是决定最终图像质量和编码性能的关键因素。掌握这些基础原理，才能在面对具体工程问题时做出正确的权衡与决策。