色彩管理与 HDR - 线性空间、Gamma 校正与 HDR 渲染

引言：为什么颜色容易算错

显示器与人眼对亮度是非线性感知的，而光照计算必须在线性空间进行（光是线性叠加的）。这中间的转换（Gamma / sRGB 编码）若处理不当，就会出现"光照发灰、阴影过暗、加法不对"等经典 bug。色彩管理就是把这套转换理清楚。

---

一、Gamma 与 sRGB：非线性编码

• 人眼对暗部更敏感 → 用有限 bit 存颜色时，把更多精度分给暗部更划算。
• sRGB / Gamma 编码：存储/显示时对颜色做非线性编码（近似 pow(x, 1/2.2)），暗部精度高；显示时再解码回线性亮度。

下图对比线性与 sRGB(Gamma) 曲线：

sRGB / Gamma 编码曲线

• sRGB 编码（存储/输出）：≈ pow(linear, 1/2.4)（分段近似 1/2.2）—— 把线性值抬高，暗部展开。
• sRGB 解码（读入线性）：≈ pow(encoded, 2.4) —— 还原为线性用于计算。

---

二、线性工作流（Linear Workflow）

现代引擎的正确做法是在线性空间做所有光照计算：

关键点：

环节	处理
颜色贴图（Albedo）	按 sRGB 采样（硬件自动解码为线性）
法线/粗糙度/数据贴图	按 Linear 采样（本就是数据，不能当颜色解码）
光照/混合/后处理	全在线性空间
最终输出	编码回 sRGB 给显示器（或走 HDR 输出，见下）

常见 bug：把数据贴图当 sRGB 解码（法线错乱）、或在 Gamma 空间做光照（发灰、混合不对）。选对纹理的 sRGB/Linear 标记至关重要。

---

三、为什么必须线性空间做光照

• 光是线性叠加的：两个光源的贡献相加，必须在线性空间才正确。
• 在 Gamma 空间相加 → 亮度不对（偏亮/偏灰），混合与抗锯齿也会错。
• 这就是"线性工作流"成为标准的原因 —— 计算在线性，存储/显示用 sRGB。

---

四、HDR 渲染

• HDR（高动态范围）渲染：中间计算用浮点、可超过 1.0 的亮度，保留强光信息（太阳、灯、高光）。
• 若一开始就 clamp 到 [0,1]，Bloom、曝光、色调映射都失去依据。
• 最终要经色调映射把 HDR 压到显示范围。

---

五、HDR 显示输出

普通显示器是 SDR（sRGB，亮度有限）；HDR 显示器能显示更高亮度与更广色域：

概念	说明
SDR 输出	色调映射到 [0,1] + sRGB 编码
HDR 输出	映射到 HDR 传输函数（PQ / HLG）与广色域（Rec.2020），按显示器峰值亮度（nits）调制
色域	sRGB/Rec.709（SDR）vs Rec.2020（HDR），更广的可表现颜色范围

HDR 输出时，UI 也需正确映射到 HDR 空间（否则 UI 过暗/过曝）—— 这也是"UI 在后处理后叠加"要额外处理 HDR 的原因。

---

六、实践要点

• 纹理 sRGB 标记选对：颜色贴图 sRGB、数据贴图 Linear。
• 确认线性工作流开启：Unity 的 Color Space 设为 Linear（而非 Gamma）。
• HDR 渲染缓冲：主渲染用 HDR 格式（如 R11G11B10 / RGBA16F），别过早 clamp。
• 色调映射选 ACES 等 filmic 曲线（见后处理）。
• HDR 输出：按目标显示器峰值亮度校准，注意 UI/色调映射的 HDR 适配。

---

附：核心概念速查

概念	说明
Gamma / sRGB	非线性编码，暗部精度高
线性工作流	光照/混合在线性空间，存储/显示用 sRGB
sRGB vs Linear 采样	颜色贴图 sRGB 解码；数据贴图 Linear
HDR 渲染	浮点、可 >1 的中间亮度，保留强光
色调映射	HDR→显示范围
PQ / HLG	HDR 输出传输函数
Rec.2020	HDR 广色域

总结

• 显示器与人眼对亮度的非线性感知要求颜色在存储时采用 sRGB/Gamma 编码，以在有限 bit 下保留更多暗部细节。
• 光照计算必须在线性空间进行，因为光是线性叠加的；在 Gamma 空间做光照会导致发灰、混合错误等经典问题。
• 线性工作流将输入纹理（颜色贴图 sRGB 解码、数据贴图 Linear 采样）、光照/混合计算（线性空间）、最终输出（编码回 sRGB）串联为正确的色彩管线。
• HDR 渲染使用浮点格式保留超过 1.0 的亮度信息，配合色调映射将 HDR 值压缩到显示范围，避免过早 clamp 损失强光细节。
• HDR 显示器输出需采用 PQ/HLG 传输函数和 Rec.2020 广色域，并根据显示器峰值亮度进行校准。