4. Gamma 编码与解码：编码 Gamma（1/2.2）与显示 Gamma（2.2）的配合机制
Gamma 校正这件事，说白了就是一场「编码端压缩、解码端还原」的配合游戏。我刚开始接触图像处理时，总觉得 Gamma 是个玄学——为什么非要搞个 1/2.2 和 2.2 来回折腾？直接线性存储不好吗？
后来踩了几个坑才明白，这套机制背后藏着两个核心诉求：人眼感知特性和显示设备物理特性。你想想看，如果直接把线性亮度数据扔给显示器，画面暗部细节会一团糟，亮部又过曝。嗯，这就是 Gamma 编码/解码存在的理由。
4.1 为什么需要编码 Gamma？
人眼对暗部变化极其敏感，对亮部变化相对迟钝。这是进化出来的能力——在昏暗环境中要能分辨猎物或危险。但摄像头传感器是线性的，它记录的光子数量翻倍，输出值就翻倍。
这就产生了一个矛盾：
- 线性采集：传感器均匀采样，暗部信息被压缩到很小的数值范围内
- 非线性感知：人眼需要更多暗部细节，亮部可以粗糙一点
我当年做医疗影像项目时，遇到过一张暗部细节完全丢失的 X 光片。原因就是采集时用了线性编码，暗部区域的灰度值只有 0-15，量化步长太大，细节全被「吃掉」了。从那以后，我对编码 Gamma 的重要性再也不敢马虎。
核心结论：编码 Gamma（通常取 1/2.2 ≈ 0.4545）的作用，是把线性传感器采集的 12bit/14bit 数据，压缩映射到 8bit 存储空间时，优先保留暗部细节。说白了，就是用更多的码字去表示人眼敏感的低亮度区域。
4.2 显示 Gamma 的物理必然性
CRT 显示器时代，电子枪的电压-亮度响应天然就是 2.2 次幂关系。你给显示器输入一个 0.5 的电压，它输出的亮度不是 0.5，而是 0.5^2.2 ≈ 0.22。这就是所谓的「显示 Gamma」。
LCD/LED 显示器虽然物理原理不同，但为了兼容整个生态链，也模拟了 2.2 的响应曲线。我测试过不同品牌的显示器，实测 Gamma 值在 2.0-2.4 之间浮动，但 2.2 是行业标准。
| Gamma 值 | 物理含义 | 视觉效果 |
|---|---|---|
| 1.0 | 线性响应，输入=输出 | 暗部偏暗，亮部偏亮，对比度过高 |
| 2.2 | 标准 CRT/LCD 响应 | 中间调自然，暗部细节丰富 |
| 2.6 | 影院/DCI-P3 标准 | 暗部更深，适合暗环境观看 |
| 1.8 | 早期 Mac 标准 | 画面偏亮偏灰，暗部细节过多 |
我的经验：做跨平台图像处理时，千万别假设所有设备的 Gamma 都是 2.2。我曾经在 iOS 设备上测试一张图片，在 Mac 上看起来正常，到了 Windows 笔记本上就发灰。查了半天，发现那台 Windows 笔记本的 Gamma 被设置成了 1.8。所以，永远在目标设备上做最终验证。
4.3 编码与解码的配合机制
整个 Gamma 链条是这样的：
- 采集端：传感器线性采集光信号，得到线性亮度值 L
- 编码 Gamma：对 L 做 L^0.4545 变换，得到编码后的值 V
- 存储/传输：V 被量化到 8bit（0-255），存入文件或视频流
- 显示 Gamma：显示器对 V 做 V^2.2 变换，还原出亮度 L'
如果编码 Gamma 和显示 Gamma 恰好互为倒数（0.4545 × 2.2 ≈ 1），那么 L' ≈ L，整个系统就是线性的。这就是为什么标准 Gamma 链条能忠实还原原始场景。
注意：编码 Gamma 和显示 Gamma 的乘积必须等于 1，才能实现端到端的线性。如果编码用了 1/2.2，显示用了 2.4，画面就会偏暗；反过来编码用 1/1.8，显示用 2.2，画面就会偏亮。我曾经在 HDR 视频项目中遇到过这种不匹配，结果暗部死黑、亮部 clipping，折腾了两天才找到根因。
4.4 配合机制的数学表达
用公式表示就是：
// 编码端（摄像头/渲染器）
float linear = sensor_data; // 0.0 ~ 1.0
float encoded = pow(linear, 1.0/2.2); // Gamma 编码
// 存储为 8bit
uint8_t storage = round(encoded * 255.0);
// 解码端（显示器/播放器）
float decoded = storage / 255.0; // 0.0 ~ 1.0
float displayed = pow(decoded, 2.2); // Gamma 解码
// 最终：displayed ≈ linear（当编码/解码 Gamma 互为倒数时）你想想看，如果跳过编码 Gamma，直接把线性值存成 8bit，暗部区域（比如 0-0.1）只有 25 个码字可用。而经过 Gamma 编码后，同样的暗部区域能分配到约 80 个码字。这就是编码 Gamma 的「信息分配」智慧。
4.5 实际系统中的 Gamma 配合
不同应用场景对 Gamma 配合的要求不一样：
- sRGB 标准：编码 Gamma ≈ 0.4545（近似 1/2.2），显示 Gamma = 2.2。这是互联网和消费电子的主流标准
- Rec.709：HDTV 标准，编码 Gamma 分段函数（暗部线性+亮部幂律），显示 Gamma = 2.2
- Rec.2020：4K/UHD 标准，编码 Gamma 更复杂，显示 Gamma = 2.4（暗环境观看）
- sRGB 分段近似：为了避免纯幂律在极暗处导数无穷大，sRGB 在暗部用线性段替代
我建议你在做图像处理库时，不要直接用 pow(x, 1/2.2) 这种简化实现。sRGB 的分段函数虽然麻烦一点，但能避免暗部噪声放大问题。我在一个移动端滤镜项目中就吃过这个亏——用纯幂律编码，结果暗部噪点被放大了两倍，用户投诉说「照片像蒙了一层砂纸」。
避坑指南：
- 永远不要假设输入数据已经做了 Gamma 解码。很多 SDK 返回的 YUV/RGB 数据是 Gamma 编码后的，直接做线性运算会出错
- 做颜色空间转换（如 RGB→XYZ）前，必须先做 Gamma 解码
- 显示器的实际 Gamma 会随亮度、视角、老化程度变化，专业校色仪是唯一可靠的校准手段
4.6 Gamma 配合机制全景图
下面这张图展示了从采集到显示的完整 Gamma 链条：
4.7 常见误区与调试方法
我在做图像质量评测时，总结了一套快速定位 Gamma 问题的流程：
- 现象 1：画面整体偏暗，暗部死黑 → 显示 Gamma 偏大（>2.2）或编码 Gamma 偏小（<1/2.2）
- 现象 2：画面整体偏亮，暗部发灰 → 显示 Gamma 偏小（<2.2）或编码 Gamma 偏大（>1/2.2）
- 现象 3：中间调正常，但高光 clipping → 编码 Gamma 未正确应用，线性值直接溢出
- 现象 4：暗部噪点明显 → 编码 Gamma 用了纯幂律而非 sRGB 分段函数
调试技巧：我习惯在测试图像中放一个 18% 灰卡（中性灰）。在标准 Gamma 链条下，18% 灰的编码值应该是 118（8bit）。如果实测值偏离超过 ±3，说明 Gamma 配合有问题。这个方法简单粗暴，但非常有效。
最后说一句，Gamma 编码与解码的配合，本质上是「用非线性的存储/传输信道，承载线性的视觉感知」。理解了这个底层逻辑，你就能灵活应对各种色彩空间和显示设备了。