伽马校正可能具有任何值,但考虑到线性RGB / 非线性sRGB转换,“2.2是一个近似值”,因此您的公式可能被认为既正确又错误:
https://en.wikipedia.org/wiki/SRGB#Theory_of_the_transformation
真实的sRGB传输函数基于2.4的伽马系数,并在暗值处出现不连续,如下所示:
float Convert_sRGB_FromLinear (float theLinearValue) {
return theLinearValue <= 0.0031308f
? theLinearValue * 12.92f
: powf (theLinearValue, 1.0f/2.4f) * 1.055f - 0.055f;
}
float Convert_sRGB_ToLinear (float thesRGBValue) {
return thesRGBValue <= 0.04045f
? thesRGBValue / 12.92f
: powf ((thesRGBValue + 0.055f) / 1.055f, 2.4f);
}
实际上,在一些使用GLSL的代码中,你可能会发现比2.2和2.4更粗略的近似值,以避免使用昂贵的
pow()
函数(而是使用
x*x
和
sqrt()
)。这是为了实现最大性能(在旧的图形硬件环境下)和代码简洁,而牺牲了色彩再现度。实际上,这种牺牲并不那么明显,大多数游戏都应用额外的色调映射和用户管理的伽马校正系数,因此结果并不直接符合sRGB标准。
期望使用更正确的公式的有
GL_FRAMEBUFFER_SRGB
和从
GL_SRGB8
纹理进行采样(在纹理采样的情况下,更可能是GPU上预计算的查找表而不是真正的公式,因为只有256个值需要转换)。例如,参见
GL_ARB_framebuffer_sRGB扩展的注释。
Given a linear RGB component, cl, convert it to an sRGB component, cs, in the range [0,1], with this pseudo-code:
if (isnan(cl)) {
cs = 0.0;
} else if (cl > 1.0) {
cs = 1.0;
} else if (cl < 0.0) {
cs = 0.0;
} else if (cl < 0.0031308) {
cs = 12.92 * cl;
} else {
cs = 1.055 * pow(cl, 0.41666) - 0.055;
}
The NaN behavior in the pseudo-code is recommended but not specified in the actual specification language.
sRGB components are typically stored as unsigned 8-bit fixed-point values.
If cs is computed with the above pseudo-code, cs can be converted to a [0,255] integer with this formula:
csi = floor(255.0 * cs + 0.5)
这里有另一篇关于OpenGL应用程序中使用sRGB的文章,您可能会觉得很有用:https://unlimited3d.wordpress.com/2020/01/08/srgb-color-space-in-opengl/