伽马颜色空间
为什么会有伽马颜色空间?这是由于早期的CRT显示设备输入的电压与显示的亮度并非线性关系,显示设备内部会进行伽马校正,于是造成了显示出来的图片颜色偏暗的效果。
观察上图,左边的图片更加接近人眼实际看到的样子,但显示器真正显示出来的却是右边图片的样子。为了确保我们看到的图片与显示器显示出来的一样,就需要显示器去进行伽马校正计算来中和抵消输入信号与输出亮度的非线性关系。伽马校正的通用公式,可以表达成:
当 值小于1的时候,我们称为 伽马编码(Gamma Encoding)。
当 值大于1的时候,我们称为 伽马解码(Gamma Decoding)。
由于没有一个很好的时机可以在显示器校正输出前对数据进行伽马编码,于是普遍的做法是,我们会在图片存储的时候进行伽马编码,它的公式如下:
因此实际图片存储的颜色会偏亮一些,等到在显示器输出时,再通过伽马校正(解码)得到更接近我们人眼识别到的图像。
但是这样又引发了另一个问题,如果显示设备的Gamma值与图片存储时输入的Gamma值不同,这该如何正确地进行伽马校正呢?
聪明的人们又发明了 Color Profile 这个东西,这里有篇文章 ,建议大家阅读一下:
What is a Color Profile
在我们最常使用的RGB颜色模型下,假设每个通道用8bit来表示,这样最多能表示的颜色种类也就 255 * 255 * 255 = 16581375 种而已,这是远远低于我们人眼所能识别的颜色的。因此 Color Profile 就是为了解释映射颜色数值到光谱波长的对应关系而建立的一套折中方案。
在存储图片的时候,记录 Color Profile 去描述如何将RGB颜色值转成光谱波长。当显示器需要显示图片时,先根据图片的 Color Profile 来将颜色变换成波长,再通过显示器自己的 Color Profile 来得到该波长对应的RGB颜色值。这样就保证了同一张图片在不同的显示设备上看起来都是相同的,即使图片存储时的Gamma值与显示器显示图片时的Gamma值不相同。
为了避免这样转来转去过于繁琐,微软和惠普联合制定了一个规范,也就是目前我们最最常用的 Color Profile : sRGB 。除了在某些特殊的专业领域,你基本上可以将 sRGB 等同于唯一的 Color Profile 了。既然图片存储和设备显示都用的一套规范,自然也就省去了转换的操作。
线性颜色空间
既然使用伽马颜色空间能够方便在显示器上显示出更接近人眼感知的颜色,为什么还要用线性颜色空间呢?
答案就是 光照计算 。
假设我们在shader中定义 输出颜色 = 贴图颜色 * 光照系数 ,其中这里的贴图颜色是经过Gamma Encoding 过的,所以就需要我们再乘上 Gamma 系数。这样公式就变成了:
但实际上,我们并不希望在这里做伽马校正,而是应该在输出到屏幕的时候。在shader中仅直接操作贴图的颜色,于是公式又变成:
显而易见
因此,当需要模拟逼真的物理写实光照,就得转换到线性空间下进行计算。而实际游戏开发过程中,在伽马颜色空间下也是调出来一些看起来还“不错”的光照效果的。不过需要注意的是,颜色计算一定要统一在同一个颜色空间下,否则还是会遇到一些怪异的表现。
最后,推荐阅读下面的两篇文章