1. 画面发灰、暗部发紫、高光刺眼时，先别急着调灯光
我在实际项目里碰到过太多类似的情况：美术把灯光和材质调了一下午，场景远看还行，近看总觉得"假"——暗部透着一种说不出的灰，阴影边缘发紫，亮部像糊了一层雾，饱和度忽高忽低。换一台显示器看，颜色又不一样。最后定位来定位去，问题根本不在模型、不在贴图、不在灯光的数值，而是项目的色彩空间从一开始就没搞对。
Unity URP 里反复出现的 "Gamma 矫正"（Gamma Correction）就是为了解决这一整类问题。简单说，人眼、显示器和渲染器的"工作方式"不一样，渲染结果不能直接丢给屏幕，必须在关键环节做一次非线性的编码和解码。如果漏掉了这一步，或者做错了位置，光照、阴影、渐变、混合全都会失真。
这篇文章我会把 Gamma 矫正的前因后果、Unity 和 URP 里的具体开关、以及调试过程中容易踩的坑按顺序讲清楚。适合刚接触 URP 的图形开发者，也适合被画面问题折磨但不知道从哪下手的朋友。看完之后你至少能回答三个问题：Gamma 2.2 这个数字从哪来；为什么要在线性空间做光照计算；在 URP 里我到底该勾选哪些选项。
2. 2.2 这个数字从哪来：显示器、人眼和 sRGB 编码的那笔旧账
在进入 Unity 操作之前，先把 Gamma 这个东西的来龙去脉理一遍。搞清它的历史，你后面读各种渲染文档时，看到 "sRGB"、"2.2"、"0.45" 这些数字就不会再发怵。
2.1 CRT 时代的物理限制
你可能听说过：伽马值最开始是从显像管（CRT）里来的。老式 CRT 显示器的亮度与控制电压并不是线性关系，亮度大致正比于电压的 2.2 次方到 2.5 次方。也就是说，如果你给显示器一个"0.5 亮度"的电压信号，它实际显示的物理亮度只有 0.5 的 2.2 次方，约等于 0.218，而不是你想的 0.5。
这是硬件层面的事实，谁也绕不过去。为了补偿这种非线性，图形系统在把图像数据传给显示器之前，会先做一次"预加重"：把亮度值取 1/2.2 次方。这样经过显示器的 2.2 次方"掰弯"之后，最终到人眼的亮度就恢复成线性关系了。
这个编码过程就是 Gamma 编码，而显示器端的匹配过程就是 Gamma 解码。到了今天，虽然我们用的基本是液晶屏和 OLED，色彩空间标准（如 sRGB）已经把当年 CRT 的这个特性继承下来了。sRGB 的传递函数就是在 CRT 响应基础上做近似得到的，所以"2.2 次方"这个数字至今依然无处不在。
2.2 人眼的感光曲线决定了编码方式
但如果你以为 Gamma 矫正单纯是为了迁就老硬件，那就小看它了。人眼的感光能力本身也是非线性的：我们对暗部的亮度变化极其敏感，对亮部的亮度变化相对迟钝。形象的比喻是，人眼像一台"自动增益"的相机，在昏暗环境里能分辨很细微的亮度差，在强光下反而"麻木"。
这就带来一个存储问题。如果直接用 8 位整数存储线性的亮度值，暗部只有 0 到 1 之间很小的一段数值可用，经典问题就是暗部渐变出现一条条色带。反过来，如果存储的是已经做过 Gamma 编码的数值，也就是把资源更多地分配给人眼敏感的暗部，那么 8 位就能存出观感上比较均匀的亮度分辨率。
所以你现在看到的所有普通 8 位 PNG、JPG 贴图，本质上都是经过了 Gamma 编码的 sRGB 数据。它们里面存的数值，几乎都不是物理上的线性亮度，而是"便于人眼观看的感知亮度"。理解这一点，是理解 Unity 里所有 sRGB 开关的基础。
2.3 sRGB 标准的精确曲线
sRGB 具体来说并不是简单粗暴的"0.45 次方"，它在接近黑的低值区有一段线性分支，避免曲线在零点斜率过大。工程上常简化为 2.2 的幂运算，但严谨的转换曲线是下面这两段：
// sRGB 到线性（解码） float3 sRGBToLinear(float3 c) { float3 lo = c / 12.92; float3 hi = pow((c + 0.055) / 1.055, 2.4); return c <= 0.04045 ? lo : hi; } // 线性到 sRGB（编码） float3 LinearToSRGB(float3 c) { float3 lo = c * 12.92; float3 hi = 1.055 * pow(c, 1.0 / 2.4) - 0.055; return c <= 0.0031308 ? lo : hi; }在游戏开发里，你用pow(c, 2.2)和pow(c, 1/2.2)做近似，绝大多数时候误差可以忽略。但如果你的项目涉及高精度后期调色，最好还是用标准的 sRGB 曲线，避免暗部偏色。
3. 为什么光照计算必须在线性空间进行：用两杯水理解"错误加倍"
现在到了整篇文章最核心的部分。Gamma 不只是"给画面调个亮度"，它的关键影响在于：你在某个色彩空间里做的数学运算，结果是否符合物理世界。
3.1 乘法只在线性空间里才"对"
渲染的本质是大量乘法：漫反射是颜色乘以光照强度，阴影是颜色乘以遮蔽系数，体积雾是颜色乘以透射率。这些乘法有一个隐藏前提：参与运算的数值必须是物理上的线性亮度。
我举个具体数字例子。假设 A 表面真正接收到的光量是 0.5，B 是 1.0，物理上 A 就是 B 的一半亮度。在 sRGB 编码下，0.5 存成约 0.73，1.0 仍然是 1.0。如果我们在 Gamma 空间里直接拿 0.73 去做光照乘法，比如乘一个 0.5 的衰减系数，得到 0.365，送到显示器上显示的物理亮度是 0.365 的 2.2 次方，约 0.118。可是正确的物理结果应该是 0.5 乘 0.5，等于 0.25。结果比真实情况暗了一半还多。
换句话说，在 Gamma 空间做乘法，每一个乘数都会被额外的幂曲线"搅和一遍"，最后得到的是一个指数错误的值。你觉得场景"脏""灰""暗部死黑"，经常就是因为这个。
3.2 插值和混合也同样受影响
光照计算不只是乘法，还有大量线性插值：纹理的双线性过滤、Mipmap 渐变、透明混合、顶点色插值、阴影渐变。
双线性过滤如果直接对 sRGB 编码的数值求平均，得到的中间值在物理亮度上就不等于两端亮度的线性平均。一个最经典的例子：黑白渐变贴图，黑是 0，白是 1，在 Gamma 空间里对编码值取平均得到 0.5，显示出来物理亮度变成 0.22 左右；而正确的线性平均值对应的显示亮度应该是 0.5。结果就是渐变中间发暗，过渡不自然。
这也是为什么现代 GPU 在采样 sRGB 格式纹理时，会在滤波之前先解码成线性值，保证所有插值都发生在线性空间。如果纹理没有正确标记为 sRGB，GPU 就会拿编码值直接滤波，Mipmap 过得越多，画面越暗越糊。
3.3 渲染方程对空间的要求更严格
换成 PBR 渲染，问题就更严重了。基于物理的 BRDF 都建立在能量守恒的基础上，传统的高光项里有大量的pow、法线点积、高光次幂运算。这些公式推导时假设输入输出是线性辐照度。你拿着一个 Gamma 编码的 albedo 贴图和一个 Gamma 编码的光照颜色去算，高光形状、菲涅尔曲线、能量守恒全部会错位。
用一个直观的类比：线性空间是"国际单位制"，Gamma 空间是"市斤和英里"。你可以在买菜时用市斤，出门说英里，但你要是把"1 加仑"当"1 升"拿去算发动机功率，结果必然是灾难。Gamma 矫正就是给渲染管线的每一段装上"单位换算器"，让所有的乘除、积分、插值统一发生在物理正确的线性单位里。
4. Unity 和 URP 在哪些环节悄悄帮你做了 Gamma 矫正
理解了为什么需要线性空间，接下来看 Unity 在流水线的哪些位置做了转换。URP 本身不引入新的色彩空间机制，它继承的是整个 Unity 引擎的色彩空间框架，只是把开关和选项摆在更显眼的位置。
4.1 Player Settings 里的 Color Space：一个开关切换整套流程
位置在 Project Settings > Player > Other Settings > Color Space。默认常常是 Gamma，如果你做 URP 且使用了标准渲染光照，建议切到 Linear。
这个开关并不只是改一个标记，它改变的是整条渲染链路的默认行为：
| 环节 | Gamma 空间模式 | Linear 空间模式 |
|---|---|---|
| sRGB 纹理采样 | 不解码，直接用编码值 | 硬件/着色器自动解码为线性值 |
| 光照计算 | 在 Gamma 空间做 | 在线性空间做 |
| 材质颜色、灯光的数值 | 按 Gamma 空间理解 | 按线性值参与运算 |
| 后处理输入 | 基本是 Gamma 空间的 LDR 数据 | 可能是线性 HDR 数据 |
| 最终输出到屏幕 | 不做额外编码 | 编码成 sRGB 交给显示器 |
在 Linear 模式下，Unity 会把你从 Inspector 里选择的颜色、灯光的颜色和强度等，从 sRGB 转成线性，参与光照计算之后再编码回 sRGB 输出。这一套对开发者几乎是透明的。
4.2 纹理导入设置里的 sRGB 开关：不是所有贴图都是"颜色贴图"
比 Color Space 更容易被忽视的是每张纹理的 sRGB 开关。Unity 导入贴图时，默认在sRGB (Color Texture)上打勾。这个勾的含义是：这张贴图里面存的是经过 Gamma 编码的颜色数据，采样时要先解码。
但是一张贴图如果存的不是颜色，而是数据——法线、粗糙度、金属度、AO、高度、遮罩——那它里面的数值是"信息"，不是"给人看的颜色"。如果你给这些贴图勾上 sRGB，本来线性的数据会被当作 Gamma 编码去解码，等于把数值做了 2.2 次方，材质属性全乱套。
对于普通 URP 项目，我的建议是这样：
| 贴图类型 | 导入类型 | sRGB 开关 |
|---|---|---|
| Albedo / Base Color / Diffuse | Default | 勾选 |
| 自发光贴图（做颜色用） | Default | 勾选 |
| 法线贴图 | Normal Map | 自动取消 |
| Metallic / Roughness / Smoothness | Default 或数据型导入 | 取消 |
| AO / 环境遮蔽 | Default 或数据型导入 | 取消 |
| 高度图 / 位移图 | Default 或数据型导入 | 取消 |
| 各类遮罩（如流沙、血迹 Mask） | Default | 取消 |
| UI 中用到的普通颜色贴图 | Default | 勾选 |
这里有一个特别容易翻车的点：如果一张颜色贴图被错误地取消了 sRGB，在 Linear 模式下采样后拿到的数值偏"亮"（因为编码值被当成线性值直接用），画面会大面积灰白。反过来，法线贴图被错误勾选 sRGB，整个模型的光照会出现很离谱的凹凸方向偏差。我在某项目里排查了好几天才发现是批量导入工具忘了分类型。
4.3 渲染目标、后处理与最终的编码出口
说完了输入，看输出。在 Linear 模式下，Unity 的相机渲染目标通常使用线性格式的缓冲，后处理也发生在线性空间。直到最后写回屏幕前，才会把线性结果编码成 sRGB。如果你的管线最终接了 Tonemapping（色调映射），这一步还会和 ACES 等算子配合。
在 URP 里需要注意几个具体选项：
- URP Asset 的 HDR 开关：开启后相机缓冲使用 HDR 格式，后处理可以拿到更高动态范围，线性工作流的意义更完整。关闭 HDR 后，很多数值会被截断到 0~1，高光细节容易丢失。
- Volume 组件里的 Color Grading Mode：URP 提供了 LDR 和 HDR 两种颜色分级模式。LDR 模式在低动态范围内工作，兼容性好；HDR 模式在线性 HDR 空间做分级，能保留更多亮部信息。如果你的项目在 Linear 模式且开启 HDR，建议优先用 HDR 模式做调色。
- Tonemapping：URP 的 Volume 里有 Tonemapping，常用 ACES 和 Neutral。ACES 本身就是一套为线性场景设计的算子，你在 Linear 空间里使用它，结果最接近影视方案的"电影感"。如果在 Gamma 空间强行套 ACES，很容易出现饱和度异常、暗部发青一类的副作用。
- Dithering：线性空间的高精度计算配合 8 位输出，暗部渐变经常出现色带。URP 的后处理里可以开 Dithering 来抖掉色带，尤其是移动端，强烈建议开。
4.4 光照强度在两种空间下的差异
还有一个在切换色彩空间时常被忽略的连带影响：光照强度。同一个场景，从 Gamma 切到 Linear，灯光数值立刻"变暗了"。这不是 bug，而是以前在 Gamma 空间里做的乘法本身带了额外的幂曲线，结果被人为拉亮了。切到 Linear 之后，你需要重新调整灯光强度和曝光参数。
我见过很多团队切完 Linear 之后，第一反应是"画面怎么这么暗"，然后把所有灯光强度调高了一倍。这当然可以，但更好的做法是用 URP 的曝光和 Tonemapping 来重新建立画面的亮部基准。也就是说，先把灯光数值设置成物理上合理的范围，再用后处理的 Exposure、Color Adjustments 这些参数去做画面整体的明暗适配，而不是跟灯光强度死磕。
5. URP 项目里切换 Linear 的完整配置清单与避坑经验
知道了原理，下面是一份可以直接"抄作业"的实操流程，以及我实际项目里踩过的一些坑。
5.1 从 Gamma 切换到 Linear 的六个步骤
先备份项目。切色彩空间会导致所有材质的观感、烘焙光照结果发生变化，这一步没法完全无损回退。
修改 Color Space 为 Linear。Project Settings > Player > Other Settings > Color Space。
检查纹理资产。用资源扫描工具批量过一遍所有贴图的 sRGB 勾选状态。颜色贴图保留勾选，数据贴图取消，法线贴图确认导入类型为 Normal Map。
重新生成光照相关资源。如果有烘焙光照贴图、光照探针、反射探针，需要重新烘焙。否则烘焙结果和实时光照的空间不一致，场景会有拼接感和错误的明暗。
打开 URP Asset 检查 HDR 与后处理设置。建议开启 HDR，后处理 Volume 里把 Tonemapping 先选 ACES，Color Grading Mode 选 HDR，观察画面。
重新调整灯光与后处理参数。从主光源强度开始，再调环境光和反射探针强度，最后调曝光、对比度、饱和度。这个顺序很重要，否则你会在错误的地基上修修补补。
5.2 排查链路：一张图片"灰蒙蒙"到底怪谁
如果切完 Linear 之后画面依然怪，我一般按下面这个顺序排查，这个顺序帮我在好几个项目里省了大量时间：
先用 Frame Debugger 看中间渲染目标。URP 的 Frame Debugger 能列出每个 RenderPass 的输入输出。如果错误的迹象在"Lit Pass"输出时就已经存在，说明是材质、灯光、纹理的问题；如果 Lit Pass 正常、到了后处理阶段才变怪，说明问题出在 Post-processing 的配置或 Volume 参数上。
检查场景里有没有漏网的非 Linear 材质。某些第三方商店资源、老项目迁移过来的 Shader，内部可能硬编码了
pow或者缺少UNITY_DECLARE_TEX2D之类的宏，导致它一直在 Gamma 空间计算。排查办法是把怀疑对象单独拎到一个只有平行光的空场景里对比。用 RenderDoc 检查实际采样格式。如果框架排查不出来的话，用 RenderDoc 抓一帧，直接看某张贴图在 GPU 端到底是什么格式。如果贴图本应是线性数据，但 GPU 标注成了
R8G8B8A8_SRGB，那问题就在导入设置；反过来也一样。检查 UI 和粒子材质。UI 的默认材质和很多粒子的软粒子材质走的是另一套混合逻辑。Linear 空间下如果 UI 贴图没有正确标记 sRGB，或者用了带 LDR 假设的 Shader，UI 整体会偏色。粒子尤其明显，因为粒子大量依赖 Alpha 混合，混合在错误空间下会形成明显的"黑边"。
5.3 自定义 Shader 里的手动 Gamma 处理
URP 自带的 Lit Shader 已经默认正确处理了线性空间，但你自己写的 Custom Shader 不一定。最常踩的坑是：写了一个简单的采样函数，发现画面怎么都对不上。
一个比较稳妥的做法是，不要在 Shader 里写死"必须线性"还是"必须 Gamma"，而是依赖 Unity 的宏和硬件标记。用TEXTURE2D和SAMPLER宏声明纹理，用SAMPLE_TEXTURE2D采样，让 Unity 根据纹理的 sRGB 标记自动决定是否解码。如果纹理标记正确，硬件采样本身就完成了 sRGB 到线性的转换。
TEXTURE2D(_BaseMap); SAMPLER(sampler_BaseMap); half4 albedo = SAMPLE_TEXTURE2D(_BaseMap, sampler_BaseMap, uv);需要特别注意的情况是：你从 RenderTexture 里采样数据。RenderTexture 创建时，是否 sRGB 取决于它的格式和读写标记。如果它是一个普通的 HDR 中间缓冲，你希望样本保持线性；如果它是一个用于 UI 展示的 RGB 缓冲，你又希望它是 sRGB。一个救命习惯是在脚本里创建 RenderTexture 时显式指定色彩空间，不要依赖默认值：
RenderTexture rt = new RenderTexture(width, height, 0, RenderTextureFormat.ARGBHalf, RenderTextureReadWrite.Linear);5.4 移动端性能与 Gamma 模式的取舍
最后聊一个现实问题：移动端是不是非得用 Linear？不是。很多面向低端机型的 URP 项目，为了把宝贵的 ALU 运算花在刀刃上，会选择保持 Gamma 模式。Gamma 空间渲染通常意味着少做很多解码/编码，某些老 GPU 上能省出一截性能，尤其在带宽受限的 8 位渲染目标上。
但是风格化不等于"随便做"。如果强制留在 Gamma 模式，你至少要意识到自己在做什么：
- 光照是物理失真的，别把阴影和高光的数值跟 PBR 手册里的参考值对照。
- 贴图导入的 sRGB 开关在 Gamma 模式下的意义完全不同，几乎可以全部保持默认，但如果你后期把项目切到 Linear，这些纹理设置会全部变成雷区。
- 后处理的 Tonemapping 尽量用 Neutral 而不是 ACES，因为 ACES 在线性空间外使用容易翻车。
如果团队里有美术在 Linear 和 Gamma 两种预览之间切换观察，我的建议是：固定一条底线，项目启动时就定好色彩空间，所有渲染相关资产和 Shader 都按这个空间来工作。最怕的就是项目做到一半再切，那几乎是给所有材质和灯光做一次大手术。
6. 几个反直觉的结论，以及我的后处理调参习惯
原理和操作都讲完了，最后分享几条我自己的经验性结论，它们都来自真实项目里被反反复复调过的教训。
第一个反直觉的结论是：画面发灰有时候不是"对比度低"，而是"纹理解码错误导致亮部过曝，全局被拉平"。把错误标记的贴图修正之后，画面会立刻清透很多，根本不需要额外加强对比度。
第二个反直觉的结论是：在 Linear 空间里，阴影往往真的会更暗、更扎实。这是因为 Gamma 空间会把中间调"抬亮"，掩盖了很多暗部细节。第一次换过去的人会不习惯，但这是物理正确的结果。别急着把环境光和 Shadow Intensity 拉满，先把后处理的 Exposure 和 ACES 曲线调好，阴影信息其实还在。
第三个反直觉的结论是：很多号称"夜景好看"的色调，都是 Tonemapping 和 Color Grading 在起作用，跟 Gamma 矫正本身关系不大。线性渲染只是提供了干净的素材，最后把画面变成什么样，还是后处理的事。Gamma 矫正解决的是"渲染是否正确"，而"画面好不好看"永远是调色师的活儿。
我个人的后处理调参习惯是：先关掉所有 Tonemapping 和 Color Grading，只保留最简单的 Gamma 矫正项，把灯光调到一个接近物理合理的范围。确认基础光照干净之后，再一层层加 ACES、加曝光、加色彩校正。这个顺序能帮你快速分辨某一个问题到底是光照问题还是后期问题，而不是在叠加的变量里瞎猜。如果你现在正被 URP 画面问题卡住，不妨先检查色彩空间和纹理标记这两项，说不定比调三天灯光更管用。
