Gamma Correction - Revision history

Marciano at 16:47, 3 January 2010

2010-01-03T16:47:41Z

Marciano at 20:42, 2 January 2010

2010-01-02T20:42:21Z

Marciano at 17:43, 2 January 2010

2010-01-02T17:43:12Z

Marciano at 17:42, 2 January 2010

2010-01-02T17:42:23Z

Marciano at 17:42, 2 January 2010

2010-01-02T17:42:09Z

Marciano: New page: = Gamma Correction = Being aware of and respecting gamma is essential for achieving superior rendering quality. Proper gamma correction and color management is an essential part of movie ...

2010-01-02T17:39:12Z

New page: = Gamma Correction = Being aware of and respecting gamma is essential for achieving superior rendering quality. Proper gamma correction and color management is an essential part of movie ...

New page

= Gamma Correction =

Being aware of and respecting gamma is essential for achieving superior rendering quality. Proper gamma correction and color management is an essential part of movie production and has become common in high profile games as well. Although basic gamma correction is easy to do, it can be pretty confusing at first for artists and even graphics programmers that have not dealt with it before.

=== Gamma Facts ===

* CRT monitors have a non-linear response curve (rather exponential), hence an RGB value of 0.5/0.5/0.5 will not produce the expected gray of 50% brightness but rather about 25%
* The eye is more sensitive to dark intensities and will see banding in darker areas more easily
* The non-linearity of CRTs matches very well the visual perception since it gives more precision for darker shades (so gamma is a feature, not a bug)
* Gamma was standardized as sRGB with an overall exponent of approximately 2.2 and is used for most output devices now, including TFTs
* sRGB is not a different image format, it only defines how the color intensities stored in an image should be interpreted

=== Correcting Input Gamma ===

Most standard color textures (albedo/diffuse maps) are in gamma space (usually sRGB space) to make best use of the available 8 bits of precision. Photos are almost always in sRGB space (jpegs are corrected for a gamma of 2.2 by convention) and if you paint a texture using a standard graphics editor, it will inherit the gamma of your monitor. This is good to reduce banding artefacts but the problem is that most lighting computations done in the shaders assume linear values. For that reason, textures in sRGB space need to be linearized before being used in shaders.

It is easy to have Horde3D do that linearization automatically. All you need to do is indicating which textures are in sRGB space and enabling the engine option <tt>SRGBLinearization</tt>. To tag a texture as sRGB, you can add <tt>sRGB="true"</tt> to the corresponding sampler definition of a material, as shown below:

 
{{CppSourceCode|description=Material with sRGB albedo map|code=
<source lang="xml" line="0">
<Material>
<Shader source="shaders/model.shader" />
<Sampler name="albedoMap" map="myTex.dds" sRGB="true" />
</Material>
</source>}}
 

Note that usually only color textures (photos or hand-painted images) are stored in sRGB space. Textures that contain non-color data (like normal maps) should be in linear space and no conversion is required when they are sampled in the shader. Hence these textures should '''not''' be tagged as sRGB. It is also important to know that the alpha channel of an sRGB texture is always considered to be linear and is not transformed.

=== Correcting Output Gamma ===

Before the final rendered image gets displayed on the monitor, it has to be converted from linear space to sRGB. This conversion can easily be done in a post-processing shader by raising the linear color to the inverse gamma exponent:

 
{{CppSourceCode|description=Conversion of linear color to sRGB|code=
<source lang="cpp" line="0">
finalColor = pow( color, 1.0 / 2.2 );
</source>}}
 

Linear color values should not be stored in 8 bit render targets since otherwise precision for the darker colors will get lost, resulting in noticeable banding. A 16 bit floating point render target, which is useful for HDR as well, should be used instead.

The following sample shows a basic HDR pipeline, where the gamma correction is applied after the tone mapping:

 
{{CppSourceCode|description=Sample HDR post-processing fragment shader|code=
<source lang="cpp" line="0">
uniform sampler2D buf0, buf1;
uniform vec4 hdrParams;
varying vec2 texCoords;

void main( void )
{
vec4 col0 = texture2D( buf0, texCoords ); // HDR color
vec4 col1 = texture2D( buf1, texCoords ); // Bloom

// Tone mapping (simple photographic exposure)
vec4 finalCol = 1.0 - exp2( -hdrParams.x * col0 );

// Apply bloom
finalCol += col1;

#ifdef GAMMA_CORRECTION
finalCol = pow( finalCol, 1.0 / 2.2 );
#endif

// Output gamma-corrected result
gl_FragColor = finalCol;
}
</source>}}
 

The <tt>#ifdef</tt> makes it possible to control the gamma correction from the application by configuring the shader preambles:

 
{{CppSourceCode|description=Enabling the output gamma correction from the application|code=
<source lang="cpp" line="0">
h3dSetShaderPreambles( "", "#define GAMMA_CORRECTION" );
</source>}}
 

Finally, please note that the overlays are often drawn after the HDR post processing and would hence not be gamma corrected. Since overlays are usually just displayed without any further shading computations, a simple trick is to avoid tagging them as sRGB. Although this is logically not quite correct (overlays are color textures), it will avoid the conversion to linear space and hence also the need to convert from linear back to sRGB.

=== Final Words ===

If you don't do any gamma correction, the effects of wrong input and output gamma will **almost** cancel out each other and the result will look acceptable. However, the emphasis is on "almost". There will definitely be some visual glitches which are unpleasing if you aim for a high visual fidelity.

If you have not considered gamma before and try to switch to a fully gamma aware (production) pipeline, chances are high that some brightness values like the intensity of light sources or particle colors need to be reduced. This is because without output gamma correction, everything looks darker than it actually is, and you had to adjust your light sources to compensate for that.

=== Further Reading ===

* [http://www.weltenbauer.com/upload/dateien/gamma_correct_v12.pdf Be gamma correct] (a relatively untechnical introduction)
* [http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html GPU Gems 3, The Importance of Being Linear]
* [http://download.microsoft.com/download/b/5/5/b55d67ff-f1cb-4174-836a-bbf8f84fb7e1/Picture%20Perfect%20-%20Gamma%20Through%20the%20Rendering%20Pipeline.zip Picture Perfect: Gamma through the Rendering Pipeline ]

@@ Line 1: / Line 1: @@
-__NOTOC__
+__NOTOC__ __NOEDITSECTION__{{ContentBlock|color=white|content={{!!}}
 Being aware of and respecting gamma is essential for achieving superior rendering quality. Proper gamma correction and color management is an essential part of movie production and has become common in high profile games as well. Although basic gamma correction is easy to do, it can be pretty confusing at first for artists and even graphics programmers that have not dealt with it before.
@@ Line 94: / Line 93: @@
 * [http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html GPU Gems 3, The Importance of Being Linear]
 * [http://download.microsoft.com/download/b/5/5/b55d67ff-f1cb-4174-836a-bbf8f84fb7e1/Picture%20Perfect%20-%20Gamma%20Through%20the%20Rendering%20Pipeline.zip Picture Perfect: Gamma through the Rendering Pipeline ]

← Older revision		Revision as of 17:42, 2 January 2010
Line 1:		Line 1:
	__NOTOC__		__NOTOC__
−
−	~~= Gamma Correction =~~

	Being aware of and respecting gamma is essential for achieving superior rendering quality. Proper gamma correction and color management is an essential part of movie production and has become common in high profile games as well. Although basic gamma correction is easy to do, it can be pretty confusing at first for artists and even graphics programmers that have not dealt with it before.		Being aware of and respecting gamma is essential for achieving superior rendering quality. Proper gamma correction and color management is an essential part of movie production and has become common in high profile games as well. Although basic gamma correction is easy to do, it can be pretty confusing at first for artists and even graphics programmers that have not dealt with it before.

← Older revision		Revision as of 17:42, 2 January 2010
Line 1:		Line 1:
		+	__NOTOC__
		+
	= Gamma Correction =		= Gamma Correction =

@@ Line 85: / Line 85: @@
 == Final Words ==
-If you don't do any gamma correction, the effects of wrong input and output gamma will **almost** cancel out each other and the result will look acceptable. However, the emphasis is on "almost". There will definitely be some visual glitches which are unpleasing if you aim for a high visual fidelity.
+If you don't do any gamma correction, the effects of wrong input and output gamma will '''almost''' cancel out each other and the result will look acceptable. However, the emphasis is on "almost". There will definitely be some visual glitches which are unpleasing if you aim for a high visual fidelity.
 If you have not considered gamma before and try to switch to a fully gamma aware (production) pipeline, chances are high that some brightness values like the intensity of light sources or particle colors need to be reduced. This is because without output gamma correction, everything looks darker than it actually is, and you had to adjust your light sources to compensate for that.

@@ Line 3: / Line 3: @@
 Being aware of and respecting gamma is essential for achieving superior rendering quality. Proper gamma correction and color management is an essential part of movie production and has become common in high profile games as well. Although basic gamma correction is easy to do, it can be pretty confusing at first for artists and even graphics programmers that have not dealt with it before.
-=== Gamma Facts ===
+== Gamma Facts ==
 * CRT monitors have a non-linear response curve (rather exponential), hence an RGB value of 0.5/0.5/0.5 will not produce the expected gray of 50% brightness but rather about 25%
@@ Line 11: / Line 11: @@
 * sRGB is not a different image format, it only defines how the color intensities stored in an image should be interpreted
-=== Correcting Input Gamma ===
+== Correcting Input Gamma ==
 Most standard color textures (albedo/diffuse maps) are in gamma space (usually sRGB space) to make best use of the available 8 bits of precision. Photos are almost always in sRGB space (jpegs are corrected for a gamma of 2.2 by convention) and if you paint a texture using a standard graphics editor, it will inherit the gamma of your monitor. This is good to reduce banding artefacts but the problem is that most lighting computations done in the shaders assume linear values. For that reason, textures in sRGB space need to be linearized before being used in shaders.
@@ Line 29: / Line 29: @@
 Note that usually only color textures (photos or hand-painted images) are stored in sRGB space. Textures that contain non-color data (like normal maps) should be in linear space and no conversion is required when they are sampled in the shader. Hence these textures should '''not''' be tagged as sRGB. It is also important to know that the alpha channel of an sRGB texture is always considered to be linear and is not transformed.
-=== Correcting Output Gamma ===
+== Correcting Output Gamma ==
 Before the final rendered image gets displayed on the monitor, it has to be converted from linear space to sRGB. This conversion can easily be done in a post-processing shader by raising the linear color to the inverse gamma exponent:
@@ Line 83: / Line 83: @@
 Finally, please note that the overlays are often drawn after the HDR post processing and would hence not be gamma corrected. Since overlays are usually just displayed without any further shading computations, a simple trick is to avoid tagging them as sRGB. Although this is logically not quite correct (overlays are color textures), it will avoid the conversion to linear space and hence also the need to convert from linear back to sRGB.
-=== Final Words ===
+== Final Words ==
 If you don't do any gamma correction, the effects of wrong input and output gamma will **almost** cancel out each other and the result will look acceptable. However, the emphasis is on "almost". There will definitely be some visual glitches which are unpleasing if you aim for a high visual fidelity.
@@ Line 89: / Line 89: @@
 If you have not considered gamma before and try to switch to a fully gamma aware (production) pipeline, chances are high that some brightness values like the intensity of light sources or particle colors need to be reduced. This is because without output gamma correction, everything looks darker than it actually is, and you had to adjust your light sources to compensate for that.
-=== Further Reading ===
+== Further Reading ==
 * [http://www.weltenbauer.com/upload/dateien/gamma_correct_v12.pdf Be gamma correct] (a relatively untechnical introduction)
 * [http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html GPU Gems 3, The Importance of Being Linear]
 * [http://download.microsoft.com/download/b/5/5/b55d67ff-f1cb-4174-836a-bbf8f84fb7e1/Picture%20Perfect%20-%20Gamma%20Through%20the%20Rendering%20Pipeline.zip Picture Perfect: Gamma through the Rendering Pipeline ]