提起图形学里最“反直觉”的一个知识点我的第一反应一定是Gamma校正。它在百人计划课程里排到图形2.6算是一个很小但至关重要的环节小到可能只是一个pow函数大到整个渲染管线的光影正确性都跟它挂钩。如果只用一个词来形容它的地位那就是“地基上的地基”。这套课程我完整过了一遍单把这节拿出来写是因为Gamma校正所牵连的细节实在太多了从CRT显示器的物理特性、sRGB图像的编码历史再到线性空间渲染、硬件纹理格式、shader输出编码每一步都有可能掉坑。很多人觉得“不就是一道pow嘛”但当我真正做起PBR材质、调整美术资源、调试画面偏色时才发现理解不透Gamma校正后面做光照和材质永远隔着一层纱。这篇文章就围绕霜狼May百人计划中图形2.6的主题把Gamma校正的技术背景、核心原理、shader代码、排查方法全部串起来适合正在学图形学基础、准备做材质渲染、或者看课只看懂了一半的同学。内容上尽量保持和课程一致的节奏但会补一些我在实际项目中反复用到的经验。1. 先搞清楚Gamma校正到底在解决什么问题1.1 CRT时代的意外遗产Gamma的故事要从显示器说起。最早的CRT阴极射线管显示器控制亮度的核心机制是电子束打在荧光粉上而荧光粉的发光强度并不是和输入电压线性对应的。实测下来亮度大致和电压的2.2次方成正比。也就是说你给显示器一个0.5的电压信号屏幕实际显示出来的亮度不是最大亮度的一半而是0.5的2.2次方大约0.217。这在视觉上就是明显偏暗的。所以最早的显示设备厂商就在硬件层面做了一次逆变换在信号进入显像管之前先把电压信号做一次1/2.2次方的预扭曲让最终显示出来的亮度接近线性。这套机制被固化成标准后就产生了“Gamma 2.2”这个经典值。后来液晶显示器虽然物理原理完全不同但为了让既有内容的观感一致也刻意模拟了这条2.2左右的响应曲线。这里有个特别反直觉的点人眼对亮度的感知本身也不线性。人对暗部变化的敏感程度远高于亮部如果把物理亮度从0到1均匀切100份你会发现暗部的每一档看起来“跨度”特别大亮部却几乎分不出区别。Gamma曲线的存在顺便还起到把量化误差从暗部挪到亮部的作用让8bit图像的观感看起来过渡均匀。这也是为什么图像文件存储时就默认带上了Gamma它本质上是一种“感知编码”。1.2 数字图像的编码Gamma现在几乎所有照片、贴图资源在保存成JPEG、PNG、TGA这类常见格式时存储的都不是物理上的线性亮度值而是已经做了一次“sRGB编码”或近似sRGB编码的非线性值。说得直白一点你从网上下载的任何一张普通图片它的像素值里已经包含了一道Gamma。那这道Gamma是怎么来的相机传感器采集到的本来应该是线性光但相机内部的ISP在今天所有手机、相机的标准流程里都会自动把线性数据映射到sRGB空间再存成图像文件。这样做有两个原因一是适配显示器的Gamma特性让照片在屏幕上看起来“正常”二是充分利用8bit的存储精度因为人眼对暗部更敏感把更多bit分配给暗部在视觉上能获得更平滑的渐变。所以问题就来了渲染引擎里做光照计算时我们需要的是物理正确的线性亮度值。光照的能量强度是线性的两个光源叠加在一起能量就该是直接相加。而贴图里存储的是感知编码过的sRGB值如果直接拿这个值去计算光照等同于在错误的坐标系里做运算。结果就是暗部越算越脏高光区域表现奇怪两种颜色插值出来的中间色在物理上完全错误。1.3 为什么渲染必须回到线性空间道理说得再具体一点用一个最简单的混合例子假设屏幕左边是一块亮度1.0的白色右边是一块亮度0.0的黑色现在要屏幕正中间出现一个过渡色物理正确的结果应该是0.5的灰色。这个0.5是按照能量比例混合出来的是线性亮度。但如果我们手里拿到的贴图颜色是sRGB编码后的0.5直接拿它们在Gamma空间里混合计算得到的结果再输出到显示器最终的视觉亮度大概只有0.217左右中间值会明显偏暗过渡带看着像一条深灰色的峡谷。更麻烦的是光照叠加在Gamma空间里做加法、乘法全都不是物理线性的运算。这就像做菜时电子秤本身没校准所有配料的重量都被压缩了一半你按正确菜谱加300克面粉结果只有150克效果菜谱里的一切比例都乱了。光照模型从漫反射、镜面反射到PBR的能量守恒全部建立在“参与计算的数值代表物理辐射能量”这个前提上。所以现代图形管线里约定俗成的做法是贴图进入管线先解码回线性空间所有光照计算在线性空间完成最后输出前再编码回sRGB空间交给显示器。理解到这一步再看下面的管线流程就顺理成章了。2. 渲染管线里Gamma校正的两个正式岗位采样解码与输出编码2.1 一张贴图从文件到屏幕的完整旅程任何一张贴图资源从硬盘加载进显存、被GPU采样参与光照到最终显示在屏幕上它需要经过下面这些环节图片文件解析得到的是sRGB编码后的像素值。GPU把纹理上传到显存如果纹理创建时被标记为sRGB格式硬件会在每次采样时自动调用“sRGB转线性”的换算函数。Shader里拿到的就是已经解码后的线性颜色值参与光照、颜色混合、后处理计算。计算完成后得到线性空间的渲染结果写入渲染目标时要么通过硬件端的“线性转sRGB”自动转换要么在Shader手动调用编码函数。显示器硬件再根据自身的Gamma响应把sRGB信号还原成物理光输出。很多初学者容易忽略的一点是显示器的“物理Gamma”和图像文件里的“sRGB编码”在视觉上互相抵消所以最终用户看到的画面是正常的。但渲染引擎内部必须自己管理好这些转换如果某个环节缺了转换、或者转换做了两次画面就会出现整体偏灰、暗部死黑、高光发白等问题。2.2 采样解码把sRGB纹理换回线性先说采样这头。目前主流API都支持原生sRGB纹理格式。在DirectX下对应格式是DXGI_FORMAT_R8G8B8A8_UNORM_SRGB在OpenGL下是GL_SRGB8_ALPHA8Vulkan里是VK_FORMAT_R8G8B8A8_SRGB。这类格式的本质是存储的bit还是原来的bit但GPU在纹理单元做采样后、把数据送到Shader之前会自动执行一次sRGB解码。这样的好处首先是省电省指令你不需要在每个Shader里手动写pow函数硬件帮你算完了。其次是统一性更好美术资源无论从哪里来只要格式标记对了引擎内部自动保持线性。在Unity等引擎中你只需要在纹理导入设置里勾选“sRGB (Color Texture)”选项引擎就会创建对应的硬件sRGB格式。这里必须多说一嘴只有颜色贴图才应该勾sRGB。法线贴图、粗糙度贴图、金属度贴图、AO贴图、高度图、数据Mask这些贴图存储的不是“给人看的颜色”而是“给计算用的数据”它们的值必须原样进入Shader保持线性绝对不能勾sRGB。否则你等于在数据贴图上做了一次非线性扭曲法线方向会算错BRDF里的粗糙度参数会整体漂移最终渲染出来就是各种莫名其妙的脏和暗。2.3 输出编码线性计算结果回填到sRGB采样解码只解决了一半问题。Shader做完整套光照计算后得到的是一个线性空间的RGB值。如果直接写回一个常规RGBA渲染目标这个值就会作为sRGB值被动显示等于丢失了编码过程画面会整体偏暗且饱和度异常暗部糊成一团。正确的做法是在写入渲染目标之前把线性值编码回sRGB。这件事也有两种实现方式。第一种是硬件自动转换。把你输出到的渲染目标格式设置成sRGB格式例如Unity的RenderTexture勾选sRGB选项或者图形API里创建RT时用SRGB格式。这样GPU在像素着色器输出阶段会自动帮你做线性到sRGB的矩阵和曲线变换性能和便携性都非常好。第二种是Shader手动转换。常见于后处理特效的中间步骤或者某些不能使用硬件sRGB输出的特殊场景。代码很简单本质就是对线性值做一次近似1/2.2次幂的操作。但如果管线里既开了硬件sRGB格式转换、Shader里又手动做了编码画面就会被压两次暗这是不少新手容易踩的双重重影坑。2.4 线性空间光照与Gamma空间渲染管线的分野说句题外话传统上很多旧引擎为了性能选择把光照计算也放在Gamma空间里。它们认为反正最终结果都要输出到Gamma空间只要美术在制作时把贴图“预先调亮”一些光照结果在视觉上勉强也能看。这就是所谓“Legacy Gamma管线”移动端早期大量使用。但这样的做法终究是打补丁物理不正确的光照在PBR时代根本藏不住。金属度、粗糙度这类参数需要在线性空间里严格遵守能量守恒粗糙度低的高光会在Gamma空间里显示成一个突兀的硬点过渡完全不自然。所以从游戏主机到移动端主流方案最终都统一到了“线性空间光照线性空间混合最终sRGB编码”这套模型上付出的代价是多几次硬件转换指令换来的是物理正确和跨平台观感一致。3. 百人计划2.6的实战手写一遍Gamma校正3.1 搭建一个正确的工程工作流我建议每一位学习这部分内容的同学都亲手新建一个测试工程把整套环节从零走一遍重点确认三件事色彩空间设置、纹理导入标记、后处理链结构。如果你的引擎支持色彩空间选择优先把渲染管线设置成线性空间。在Unity里就是Project Settings Player Color Space Linear如果你用的是URP或HDRP还要检查文档里对色彩空间的要求。设置完成后创建一个简单的PBR材质球丢入基础颜色贴图、法线贴图、金属度贴图和粗糙度贴图。这时候打开Frame Debugger看一眼贴图采样前后的数值对比你就能直观感受到“解码”这件事真的发生了。移动端同学可能会犹豫线性空间在移动设备上性能开销大吗实测下来纯编码转换指令的开销其实非常小一次pow级别的ALU操作在现代移动GPU上几乎可以忽略。真正有成本的是线性空间下部分混合操作需要更高精度的中间缓冲但只要你不在老古董设备上做实验收益远大于成本。3.2 Shader里亲手实现解码与编码哪怕引擎帮你搞定了大部分硬件转换我依然强烈建议你至少在Shader里手写一次转换函数把数学原理彻底刻在脑子里。以下是精确到工程级别的代码已经过多个平台验证可以直接抄// sRGB转线性从贴图采样得到的sRGB值进入计算前 float3 sRGBToLinear(float3 col) { float3 linear col * (col * (col * 0.305306011 0.682171111) 0.012522878); return linear; // 这属于一种近似拟合精度已经足够 } // sRGB转线性精确分段版用于对精度要求极高的场合 float3 sRGBToLinearExact(float3 col) { float3 lo col / 12.92; float3 hi pow((col 0.055) / 1.055, 2.4); return lerp(hi, lo, col 0.04045); } // 线性转sRGB精确分段版 float3 LinearToSRGBExact(float3 col) { float3 lo col * 12.92; float3 hi 1.055 * pow(max(col, 0.0), 1.0 / 2.4) - 0.055; return lerp(hi, lo, col 0.0031308); } // 线性转sRGB近似版很多引擎在内置后处理里用的就是它 float3 LinearToSRGB(float3 col) { return max(1.055 * pow(col, 0.41666) - 0.055, 0.0); }在材质Shader里如果你用的是非sRGB硬件采样你可以在采样后立刻调用sRGBToLinear把所有后续计算都搬进线性空间在最终的片元输出语句前再调用LinearToSRGB。如果你确认引擎已经通过RT的sRGB标记帮你做了输出编码那就千万不要再手动调用LinearToSRGB否则就会“双倍压暗”。3.3 为什么标准值不是2.0也不是2.4很多人写Gamma校正时只会背2.2。但2.2只是sRGB标准在视觉上的一个整体近似并不是sRGB曲线的精确指数。真正的sRGB标准是一条分段曲线暗部低于0.04045的区间用线性段12.92x亮部以上用1.055乘以x的1/2.4次方再减0.055。这个分段设计的好处是暗部区域的线性段可以避免纯指数曲线在接近0处斜率为无穷大带来的数字噪声同时让整个曲线在暗部到亮部的过渡保持导数连续。实际渲染中绝大多数情况你用2.2或者2.4近似视觉差异并不会太大。但在高精度美术工作中尤其处理暗部细节和抗锯齿边缘时精确分段版会避免一些微妙偏差。另一个值得记住的是16bit浮点RT和8bit定点RT对Gamma非常敏感。许多移动端设备默认的中间缓冲是低精度格式在线性空间下暗部容易出现条纹感这时候要么把RT精度调高要么对中间结果做轻微抖动但核心原则仍然是宁可牺牲一点点精度也别回到Gamma空间去算光照。3.4 用渐变球和灰阶卡验证自己有没有配错实操验证手段非常关键否则你以为自己配好了结果画面早就偏色了几十个色阶你都感知不到。我常用的方法是这样在当前场景里放一个纯白平行光材质基础色设为纯白粗糙度调到0.6左右然后打开一个可以显示数据贴图的调试视图。在UI面板上实时显示“屏幕中心像素的线性RGB值”。正常情况下如果灯光的亮度是1.0白球受光面的线性值应该约等于1.0阴影面接近0。如果你发现中间调数值在0.5左右但屏幕观感却偏暗那么十有八九是输出阶段少了一次编码如果受光面整体超过1.0且高光爆成一片那往往是解码和编码叠加了两次。更直白一点把屏幕切到一个纯色渐变条从0到1均匀渐变正确配置下这个渐变从暗到亮应该是视觉上均匀的。如果你看到暗部被压得太狠中段明显下沉就说明当前把sRGB当线性算了。4. 我踩过的坑Gamma相关高频问题排查实录4.1 画面整体发灰发暗怎么查都查不出来这是我见过最多的症状所有材质颜色感觉都正常但整个画面像蒙了一层灰蒙蒙的纱对比度不够暗部发闷。排查看似复杂其实只需检查两个地方所有贴图是否按“颜色或数据”正确设置sRGB标记以及最终输出到显示器的RT格式是否是sRGB格式。如果你在线性空间工作流里不小心把颜色贴图标记成了“非sRGB”引擎就会把已经编码过的值直接当线性值算画面会整体偏灰白。反过来你把法线贴图标记成了sRGB法线波形的幅度会被非线性压缩光照方向直接算歪所有物体的明暗关系都变得模糊看起来也像蒙了灰。遇到这种情况先别急着调灯和材质参数。打开Frame Debugger截帧选中一个明确是纯色的材质采样节点对比采样前后的数值。如果数值几乎没变化说明纹理被当作线性数据采样了看导入设置如果数值被明显拉伸到0.4左右再检查是不是所有图都统一做了转换法线贴图是否也被误伤。4.2 法线贴图和粗糙度贴图千万别勾sRGB这个坑我已经见过太多次所以单独拎出来说。法线贴图存储的是一组方向向量它是把物体表面的切线方向映射成RGB值用来扰动光照计算中的法线。它里面没有任何“视觉颜色”含义相反它必须被线性读取任何一个缩放或偏移都会导致切线空间方向变化表现在画面上就是高光位置跳变、光照轮廓扭曲比普通贴图丢失色彩更严重。粗糙度、金属度这类PBR参数同理。金属度为0或1粗糙度为0到1它们在BRDF公式中都是作为线性权重出现的任何Gamma变换都相当于在权重上又挂了一层指数让高光半径整体失真。实践建议在你团队的资源规范里明确写出“只有Base Color和Emissive可以勾sRGB法线、粗糙度、金属度、AO、Mask全部关闭”。这个体验项目里如果两种贴图都勾了渲染那一刻你就能看到高光忽大忽小整场效果无法挽救。4.3 纹理过滤和Mipmap边缘的微妙发暗学过纹理基础的同学都知道GPU采样贴图时会做双线性过滤在不同Mip等级之间做三线性过渡。这些过滤操作也是对值进行加权平均。如果权重平均放在线性空间做它是物理正确的如果放在sRGB空间做结果就会暗一点。所以硬件sRGB纹理真正的实现逻辑是硬件先把sRGB值解码成线性值然后做过滤平均得到的结果是线性的。这也是为什么硬件sRGB格式采样比手动在Shader里“先采样再pow”质量更高——因为你在Shader里做的是“先算平均再解码”顺序反了。一个最直观的现象黑白交界处的中灰色在sRGB空间平均后再解码和在线性空间平均后直接得到的结果数值可以相差接近0.1在边缘部分就会看到一条不自然的暗线。这个细节平时不太显眼但一旦你的场景里有很多细线条纹理、天空盒边缘、抗锯齿程度较高的高光点它就会变成那种“说不出来哪里不对但总觉得脏”的问题源头。4.4 界面UI与后处理特效用错空间的额外处理UI贴图通常由美术在sRGB空间下绘制它们的默认意图是让人直接看到最终颜色。因此UI的采样和渲染有两种做法一是让UI在Gamma空间直接输出不参与线性空间光照这样它的颜色观感最接近美术所见二是在线性空间流程中把UI贴图也解码、最终再编码回去相当于走了一个完整Gamma循环颜色预期也能保持。但很多Shader中透明UI混合还会涉及到Alpha通道。Alpha值的混合天然应该在线性空间做这也意味着UI的Alpha部分也应该遵循线性规则。我发现的最典型的问题是UI整体色彩没问题但半透明子元素叠在一起时边缘会出现一圈明亮的泛白这就很可能是Alpha通道在线性空间被错误地做了Gamma编码转换。解决思路是UIShader里采样时把RGB从sRGB解码到线性再做Alpha混合最后输出时编码回sRGB如果引擎强制硬件转换就要确保UI资源和RT格式匹配。过度后处理也是一个盲区。Bloom泛光这类特效通常在线性空间计算它的效果是用高亮区域的能量扩散到周边。如果在Gamma空间做Bloom扩散的范围和衰减会变成指数关系高光会拉出一圈极其难看的硬边。同样的逻辑适用于抗锯齿和模糊算法这些“平均”操作都必须在线性空间完成。所以在搭建后处理栈时时刻提醒自己滤镜是计算不是展示计算必须在物理正确的空间里进行。5. 回顾这节百人计划的学习心得5.1 课程节奏为什么值得细品回到霜狼May百人计划图形2.6这节课我注意到它最优秀的一点是并没有在一开始就直接甩出公式和代码而是花了大量篇幅讲历史背景、人眼感知、以及“为什么你的显示器长得和数学公式不一样”。这个设计极其聪明因为Gamma校正这个知识点最大的门槛不是数学而是直觉你看到了一个明明“很暗”的画面却要去解释“这是线性空间里正确的亮度”如果没有物理背景铺垫纯粹背公式迟早会出问题。课程里还把“解码”和“编码”两个环节刻意分开强调这点特别重要。很多教程只会讲一句“记得转换”但实际工程里每个采样点、每个RT、每个后处理节点都可能需要单独判断。只有把每个环节的输入输出空间都搞清楚你才能真正判断哪里需要转换、哪里已经转换过。5.2 从Gamma校正学到的图形学通用思维最后分享一个我在实际开发里越来越深刻的体会显卡里所有看不见的自动转换其实都是为了让你少写错代码。但越是自动化越要求你理解它在干什么。Gamma校正就是最典型的例子当你理解了它你会发现画面偏色、高光脏、暗部糊这些玄学问题百分之六七十都能用“空间对不对、转换有没有重”来解释。我个人的习惯是每接触一个新引擎、新渲染管线第一件事就是找到它的色彩空间设置然后做一组最简单的渐变球测试确保整个链路里的Gamma转换是正确的。再往后做材质、调光照之前的几乎所有参数都不需要推翻重来。这套方法帮我避开了很多“调了五十版灯光最后发现只是色彩空间搞错”的无效工作时间也让我对引擎的信任度提高了一大截。如果你刚学完图形2.6不妨也给自己留一个下午从头到尾亲手搭一次线性渲染流程跑一遍渐变球测试你会回来感谢这节课的。
提起图形学里最“反直觉”的一个知识点我的第一反应一定是Gamma校正。它在百人计划课程里排到图形2.6算是一个很小但至关重要的环节小到可能只是一个pow函数大到整个渲染管线的光影正确性都跟它挂钩。如果只用一个词来形容它的地位那就是“地基上的地基”。这套课程我完整过了一遍单把这节拿出来写是因为Gamma校正所牵连的细节实在太多了从CRT显示器的物理特性、sRGB图像的编码历史再到线性空间渲染、硬件纹理格式、shader输出编码每一步都有可能掉坑。很多人觉得“不就是一道pow嘛”但当我真正做起PBR材质、调整美术资源、调试画面偏色时才发现理解不透Gamma校正后面做光照和材质永远隔着一层纱。这篇文章就围绕霜狼May百人计划中图形2.6的主题把Gamma校正的技术背景、核心原理、shader代码、排查方法全部串起来适合正在学图形学基础、准备做材质渲染、或者看课只看懂了一半的同学。内容上尽量保持和课程一致的节奏但会补一些我在实际项目中反复用到的经验。1. 先搞清楚Gamma校正到底在解决什么问题1.1 CRT时代的意外遗产Gamma的故事要从显示器说起。最早的CRT阴极射线管显示器控制亮度的核心机制是电子束打在荧光粉上而荧光粉的发光强度并不是和输入电压线性对应的。实测下来亮度大致和电压的2.2次方成正比。也就是说你给显示器一个0.5的电压信号屏幕实际显示出来的亮度不是最大亮度的一半而是0.5的2.2次方大约0.217。这在视觉上就是明显偏暗的。所以最早的显示设备厂商就在硬件层面做了一次逆变换在信号进入显像管之前先把电压信号做一次1/2.2次方的预扭曲让最终显示出来的亮度接近线性。这套机制被固化成标准后就产生了“Gamma 2.2”这个经典值。后来液晶显示器虽然物理原理完全不同但为了让既有内容的观感一致也刻意模拟了这条2.2左右的响应曲线。这里有个特别反直觉的点人眼对亮度的感知本身也不线性。人对暗部变化的敏感程度远高于亮部如果把物理亮度从0到1均匀切100份你会发现暗部的每一档看起来“跨度”特别大亮部却几乎分不出区别。Gamma曲线的存在顺便还起到把量化误差从暗部挪到亮部的作用让8bit图像的观感看起来过渡均匀。这也是为什么图像文件存储时就默认带上了Gamma它本质上是一种“感知编码”。1.2 数字图像的编码Gamma现在几乎所有照片、贴图资源在保存成JPEG、PNG、TGA这类常见格式时存储的都不是物理上的线性亮度值而是已经做了一次“sRGB编码”或近似sRGB编码的非线性值。说得直白一点你从网上下载的任何一张普通图片它的像素值里已经包含了一道Gamma。那这道Gamma是怎么来的相机传感器采集到的本来应该是线性光但相机内部的ISP在今天所有手机、相机的标准流程里都会自动把线性数据映射到sRGB空间再存成图像文件。这样做有两个原因一是适配显示器的Gamma特性让照片在屏幕上看起来“正常”二是充分利用8bit的存储精度因为人眼对暗部更敏感把更多bit分配给暗部在视觉上能获得更平滑的渐变。所以问题就来了渲染引擎里做光照计算时我们需要的是物理正确的线性亮度值。光照的能量强度是线性的两个光源叠加在一起能量就该是直接相加。而贴图里存储的是感知编码过的sRGB值如果直接拿这个值去计算光照等同于在错误的坐标系里做运算。结果就是暗部越算越脏高光区域表现奇怪两种颜色插值出来的中间色在物理上完全错误。1.3 为什么渲染必须回到线性空间道理说得再具体一点用一个最简单的混合例子假设屏幕左边是一块亮度1.0的白色右边是一块亮度0.0的黑色现在要屏幕正中间出现一个过渡色物理正确的结果应该是0.5的灰色。这个0.5是按照能量比例混合出来的是线性亮度。但如果我们手里拿到的贴图颜色是sRGB编码后的0.5直接拿它们在Gamma空间里混合计算得到的结果再输出到显示器最终的视觉亮度大概只有0.217左右中间值会明显偏暗过渡带看着像一条深灰色的峡谷。更麻烦的是光照叠加在Gamma空间里做加法、乘法全都不是物理线性的运算。这就像做菜时电子秤本身没校准所有配料的重量都被压缩了一半你按正确菜谱加300克面粉结果只有150克效果菜谱里的一切比例都乱了。光照模型从漫反射、镜面反射到PBR的能量守恒全部建立在“参与计算的数值代表物理辐射能量”这个前提上。所以现代图形管线里约定俗成的做法是贴图进入管线先解码回线性空间所有光照计算在线性空间完成最后输出前再编码回sRGB空间交给显示器。理解到这一步再看下面的管线流程就顺理成章了。2. 渲染管线里Gamma校正的两个正式岗位采样解码与输出编码2.1 一张贴图从文件到屏幕的完整旅程任何一张贴图资源从硬盘加载进显存、被GPU采样参与光照到最终显示在屏幕上它需要经过下面这些环节图片文件解析得到的是sRGB编码后的像素值。GPU把纹理上传到显存如果纹理创建时被标记为sRGB格式硬件会在每次采样时自动调用“sRGB转线性”的换算函数。Shader里拿到的就是已经解码后的线性颜色值参与光照、颜色混合、后处理计算。计算完成后得到线性空间的渲染结果写入渲染目标时要么通过硬件端的“线性转sRGB”自动转换要么在Shader手动调用编码函数。显示器硬件再根据自身的Gamma响应把sRGB信号还原成物理光输出。很多初学者容易忽略的一点是显示器的“物理Gamma”和图像文件里的“sRGB编码”在视觉上互相抵消所以最终用户看到的画面是正常的。但渲染引擎内部必须自己管理好这些转换如果某个环节缺了转换、或者转换做了两次画面就会出现整体偏灰、暗部死黑、高光发白等问题。2.2 采样解码把sRGB纹理换回线性先说采样这头。目前主流API都支持原生sRGB纹理格式。在DirectX下对应格式是DXGI_FORMAT_R8G8B8A8_UNORM_SRGB在OpenGL下是GL_SRGB8_ALPHA8Vulkan里是VK_FORMAT_R8G8B8A8_SRGB。这类格式的本质是存储的bit还是原来的bit但GPU在纹理单元做采样后、把数据送到Shader之前会自动执行一次sRGB解码。这样的好处首先是省电省指令你不需要在每个Shader里手动写pow函数硬件帮你算完了。其次是统一性更好美术资源无论从哪里来只要格式标记对了引擎内部自动保持线性。在Unity等引擎中你只需要在纹理导入设置里勾选“sRGB (Color Texture)”选项引擎就会创建对应的硬件sRGB格式。这里必须多说一嘴只有颜色贴图才应该勾sRGB。法线贴图、粗糙度贴图、金属度贴图、AO贴图、高度图、数据Mask这些贴图存储的不是“给人看的颜色”而是“给计算用的数据”它们的值必须原样进入Shader保持线性绝对不能勾sRGB。否则你等于在数据贴图上做了一次非线性扭曲法线方向会算错BRDF里的粗糙度参数会整体漂移最终渲染出来就是各种莫名其妙的脏和暗。2.3 输出编码线性计算结果回填到sRGB采样解码只解决了一半问题。Shader做完整套光照计算后得到的是一个线性空间的RGB值。如果直接写回一个常规RGBA渲染目标这个值就会作为sRGB值被动显示等于丢失了编码过程画面会整体偏暗且饱和度异常暗部糊成一团。正确的做法是在写入渲染目标之前把线性值编码回sRGB。这件事也有两种实现方式。第一种是硬件自动转换。把你输出到的渲染目标格式设置成sRGB格式例如Unity的RenderTexture勾选sRGB选项或者图形API里创建RT时用SRGB格式。这样GPU在像素着色器输出阶段会自动帮你做线性到sRGB的矩阵和曲线变换性能和便携性都非常好。第二种是Shader手动转换。常见于后处理特效的中间步骤或者某些不能使用硬件sRGB输出的特殊场景。代码很简单本质就是对线性值做一次近似1/2.2次幂的操作。但如果管线里既开了硬件sRGB格式转换、Shader里又手动做了编码画面就会被压两次暗这是不少新手容易踩的双重重影坑。2.4 线性空间光照与Gamma空间渲染管线的分野说句题外话传统上很多旧引擎为了性能选择把光照计算也放在Gamma空间里。它们认为反正最终结果都要输出到Gamma空间只要美术在制作时把贴图“预先调亮”一些光照结果在视觉上勉强也能看。这就是所谓“Legacy Gamma管线”移动端早期大量使用。但这样的做法终究是打补丁物理不正确的光照在PBR时代根本藏不住。金属度、粗糙度这类参数需要在线性空间里严格遵守能量守恒粗糙度低的高光会在Gamma空间里显示成一个突兀的硬点过渡完全不自然。所以从游戏主机到移动端主流方案最终都统一到了“线性空间光照线性空间混合最终sRGB编码”这套模型上付出的代价是多几次硬件转换指令换来的是物理正确和跨平台观感一致。3. 百人计划2.6的实战手写一遍Gamma校正3.1 搭建一个正确的工程工作流我建议每一位学习这部分内容的同学都亲手新建一个测试工程把整套环节从零走一遍重点确认三件事色彩空间设置、纹理导入标记、后处理链结构。如果你的引擎支持色彩空间选择优先把渲染管线设置成线性空间。在Unity里就是Project Settings Player Color Space Linear如果你用的是URP或HDRP还要检查文档里对色彩空间的要求。设置完成后创建一个简单的PBR材质球丢入基础颜色贴图、法线贴图、金属度贴图和粗糙度贴图。这时候打开Frame Debugger看一眼贴图采样前后的数值对比你就能直观感受到“解码”这件事真的发生了。移动端同学可能会犹豫线性空间在移动设备上性能开销大吗实测下来纯编码转换指令的开销其实非常小一次pow级别的ALU操作在现代移动GPU上几乎可以忽略。真正有成本的是线性空间下部分混合操作需要更高精度的中间缓冲但只要你不在老古董设备上做实验收益远大于成本。3.2 Shader里亲手实现解码与编码哪怕引擎帮你搞定了大部分硬件转换我依然强烈建议你至少在Shader里手写一次转换函数把数学原理彻底刻在脑子里。以下是精确到工程级别的代码已经过多个平台验证可以直接抄// sRGB转线性从贴图采样得到的sRGB值进入计算前 float3 sRGBToLinear(float3 col) { float3 linear col * (col * (col * 0.305306011 0.682171111) 0.012522878); return linear; // 这属于一种近似拟合精度已经足够 } // sRGB转线性精确分段版用于对精度要求极高的场合 float3 sRGBToLinearExact(float3 col) { float3 lo col / 12.92; float3 hi pow((col 0.055) / 1.055, 2.4); return lerp(hi, lo, col 0.04045); } // 线性转sRGB精确分段版 float3 LinearToSRGBExact(float3 col) { float3 lo col * 12.92; float3 hi 1.055 * pow(max(col, 0.0), 1.0 / 2.4) - 0.055; return lerp(hi, lo, col 0.0031308); } // 线性转sRGB近似版很多引擎在内置后处理里用的就是它 float3 LinearToSRGB(float3 col) { return max(1.055 * pow(col, 0.41666) - 0.055, 0.0); }在材质Shader里如果你用的是非sRGB硬件采样你可以在采样后立刻调用sRGBToLinear把所有后续计算都搬进线性空间在最终的片元输出语句前再调用LinearToSRGB。如果你确认引擎已经通过RT的sRGB标记帮你做了输出编码那就千万不要再手动调用LinearToSRGB否则就会“双倍压暗”。3.3 为什么标准值不是2.0也不是2.4很多人写Gamma校正时只会背2.2。但2.2只是sRGB标准在视觉上的一个整体近似并不是sRGB曲线的精确指数。真正的sRGB标准是一条分段曲线暗部低于0.04045的区间用线性段12.92x亮部以上用1.055乘以x的1/2.4次方再减0.055。这个分段设计的好处是暗部区域的线性段可以避免纯指数曲线在接近0处斜率为无穷大带来的数字噪声同时让整个曲线在暗部到亮部的过渡保持导数连续。实际渲染中绝大多数情况你用2.2或者2.4近似视觉差异并不会太大。但在高精度美术工作中尤其处理暗部细节和抗锯齿边缘时精确分段版会避免一些微妙偏差。另一个值得记住的是16bit浮点RT和8bit定点RT对Gamma非常敏感。许多移动端设备默认的中间缓冲是低精度格式在线性空间下暗部容易出现条纹感这时候要么把RT精度调高要么对中间结果做轻微抖动但核心原则仍然是宁可牺牲一点点精度也别回到Gamma空间去算光照。3.4 用渐变球和灰阶卡验证自己有没有配错实操验证手段非常关键否则你以为自己配好了结果画面早就偏色了几十个色阶你都感知不到。我常用的方法是这样在当前场景里放一个纯白平行光材质基础色设为纯白粗糙度调到0.6左右然后打开一个可以显示数据贴图的调试视图。在UI面板上实时显示“屏幕中心像素的线性RGB值”。正常情况下如果灯光的亮度是1.0白球受光面的线性值应该约等于1.0阴影面接近0。如果你发现中间调数值在0.5左右但屏幕观感却偏暗那么十有八九是输出阶段少了一次编码如果受光面整体超过1.0且高光爆成一片那往往是解码和编码叠加了两次。更直白一点把屏幕切到一个纯色渐变条从0到1均匀渐变正确配置下这个渐变从暗到亮应该是视觉上均匀的。如果你看到暗部被压得太狠中段明显下沉就说明当前把sRGB当线性算了。4. 我踩过的坑Gamma相关高频问题排查实录4.1 画面整体发灰发暗怎么查都查不出来这是我见过最多的症状所有材质颜色感觉都正常但整个画面像蒙了一层灰蒙蒙的纱对比度不够暗部发闷。排查看似复杂其实只需检查两个地方所有贴图是否按“颜色或数据”正确设置sRGB标记以及最终输出到显示器的RT格式是否是sRGB格式。如果你在线性空间工作流里不小心把颜色贴图标记成了“非sRGB”引擎就会把已经编码过的值直接当线性值算画面会整体偏灰白。反过来你把法线贴图标记成了sRGB法线波形的幅度会被非线性压缩光照方向直接算歪所有物体的明暗关系都变得模糊看起来也像蒙了灰。遇到这种情况先别急着调灯和材质参数。打开Frame Debugger截帧选中一个明确是纯色的材质采样节点对比采样前后的数值。如果数值几乎没变化说明纹理被当作线性数据采样了看导入设置如果数值被明显拉伸到0.4左右再检查是不是所有图都统一做了转换法线贴图是否也被误伤。4.2 法线贴图和粗糙度贴图千万别勾sRGB这个坑我已经见过太多次所以单独拎出来说。法线贴图存储的是一组方向向量它是把物体表面的切线方向映射成RGB值用来扰动光照计算中的法线。它里面没有任何“视觉颜色”含义相反它必须被线性读取任何一个缩放或偏移都会导致切线空间方向变化表现在画面上就是高光位置跳变、光照轮廓扭曲比普通贴图丢失色彩更严重。粗糙度、金属度这类PBR参数同理。金属度为0或1粗糙度为0到1它们在BRDF公式中都是作为线性权重出现的任何Gamma变换都相当于在权重上又挂了一层指数让高光半径整体失真。实践建议在你团队的资源规范里明确写出“只有Base Color和Emissive可以勾sRGB法线、粗糙度、金属度、AO、Mask全部关闭”。这个体验项目里如果两种贴图都勾了渲染那一刻你就能看到高光忽大忽小整场效果无法挽救。4.3 纹理过滤和Mipmap边缘的微妙发暗学过纹理基础的同学都知道GPU采样贴图时会做双线性过滤在不同Mip等级之间做三线性过渡。这些过滤操作也是对值进行加权平均。如果权重平均放在线性空间做它是物理正确的如果放在sRGB空间做结果就会暗一点。所以硬件sRGB纹理真正的实现逻辑是硬件先把sRGB值解码成线性值然后做过滤平均得到的结果是线性的。这也是为什么硬件sRGB格式采样比手动在Shader里“先采样再pow”质量更高——因为你在Shader里做的是“先算平均再解码”顺序反了。一个最直观的现象黑白交界处的中灰色在sRGB空间平均后再解码和在线性空间平均后直接得到的结果数值可以相差接近0.1在边缘部分就会看到一条不自然的暗线。这个细节平时不太显眼但一旦你的场景里有很多细线条纹理、天空盒边缘、抗锯齿程度较高的高光点它就会变成那种“说不出来哪里不对但总觉得脏”的问题源头。4.4 界面UI与后处理特效用错空间的额外处理UI贴图通常由美术在sRGB空间下绘制它们的默认意图是让人直接看到最终颜色。因此UI的采样和渲染有两种做法一是让UI在Gamma空间直接输出不参与线性空间光照这样它的颜色观感最接近美术所见二是在线性空间流程中把UI贴图也解码、最终再编码回去相当于走了一个完整Gamma循环颜色预期也能保持。但很多Shader中透明UI混合还会涉及到Alpha通道。Alpha值的混合天然应该在线性空间做这也意味着UI的Alpha部分也应该遵循线性规则。我发现的最典型的问题是UI整体色彩没问题但半透明子元素叠在一起时边缘会出现一圈明亮的泛白这就很可能是Alpha通道在线性空间被错误地做了Gamma编码转换。解决思路是UIShader里采样时把RGB从sRGB解码到线性再做Alpha混合最后输出时编码回sRGB如果引擎强制硬件转换就要确保UI资源和RT格式匹配。过度后处理也是一个盲区。Bloom泛光这类特效通常在线性空间计算它的效果是用高亮区域的能量扩散到周边。如果在Gamma空间做Bloom扩散的范围和衰减会变成指数关系高光会拉出一圈极其难看的硬边。同样的逻辑适用于抗锯齿和模糊算法这些“平均”操作都必须在线性空间完成。所以在搭建后处理栈时时刻提醒自己滤镜是计算不是展示计算必须在物理正确的空间里进行。5. 回顾这节百人计划的学习心得5.1 课程节奏为什么值得细品回到霜狼May百人计划图形2.6这节课我注意到它最优秀的一点是并没有在一开始就直接甩出公式和代码而是花了大量篇幅讲历史背景、人眼感知、以及“为什么你的显示器长得和数学公式不一样”。这个设计极其聪明因为Gamma校正这个知识点最大的门槛不是数学而是直觉你看到了一个明明“很暗”的画面却要去解释“这是线性空间里正确的亮度”如果没有物理背景铺垫纯粹背公式迟早会出问题。课程里还把“解码”和“编码”两个环节刻意分开强调这点特别重要。很多教程只会讲一句“记得转换”但实际工程里每个采样点、每个RT、每个后处理节点都可能需要单独判断。只有把每个环节的输入输出空间都搞清楚你才能真正判断哪里需要转换、哪里已经转换过。5.2 从Gamma校正学到的图形学通用思维最后分享一个我在实际开发里越来越深刻的体会显卡里所有看不见的自动转换其实都是为了让你少写错代码。但越是自动化越要求你理解它在干什么。Gamma校正就是最典型的例子当你理解了它你会发现画面偏色、高光脏、暗部糊这些玄学问题百分之六七十都能用“空间对不对、转换有没有重”来解释。我个人的习惯是每接触一个新引擎、新渲染管线第一件事就是找到它的色彩空间设置然后做一组最简单的渐变球测试确保整个链路里的Gamma转换是正确的。再往后做材质、调光照之前的几乎所有参数都不需要推翻重来。这套方法帮我避开了很多“调了五十版灯光最后发现只是色彩空间搞错”的无效工作时间也让我对引擎的信任度提高了一大截。如果你刚学完图形2.6不妨也给自己留一个下午从头到尾亲手搭一次线性渲染流程跑一遍渐变球测试你会回来感谢这节课的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
