anchor.diff:  
   ----
   
  -This setting is also exposed in the Settings dialog displayed when you launch a jME application.+
  +This setting is also exposed in the Settings dialog displayed when you launch a jME application. +
   image:http://i.imgur.com/Lya1ldH.png[Lya1ldH.png,width="400",height=""]
   
   
  
positive.code: 
  [IMPORTANT]
  ====
  Only loaded images will be marked as in sRGB color space, when using assetManager.loadTexture or loadAsset.+
  The color space of an image created by code will have to be specified in the constructor or will be assumed as Linear if not specified.
  ====
  
  
  Not all images need to be linearized. Some images don't represent color information that will be displayed on screen, but more different sort of data packed in a texture.+
  The best example is a Normal map that will contains normal vectors for each pixel. Height maps will contain elevation values. These textures must not be linearized.
  
  There is no way to determine the real color space of an image when loading it, so we must deduce the color space from the usage it's loaded for.
  The usage is dictated by the material, those textures are used for, and by the material parameter they are assigned to.
  One can now specify in a material definition file (j3md) if a texture parameter must be assumed as in linear color space, and thus, must not be linearized, by using the keyword -LINEAR next to the parameter (case does not matter).
  
  For example here is how the NormalMap parameter is declared in the lighting material definition.
  
negative.code: Here is a quick overview of what lies under the “Gamma Correction term. +
  More in depth rundowns on the matter can be found here : link:http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html[http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html] and here link:http://www.arcsynthesis.org/gltut/Texturing/Tutorial%2016.html[http://www.arcsynthesis.org/gltut/Texturing/Tutorial%2016.html]
  
  We consider color values to be linear when computing lighting. What does that means? That means that we assume that the color 0.5,0.5,0.5 is half way between black and white. +
  The problem is that it’s not the case, or at least not when you look at the color through a monitor. +
  CRT monitors had physical limitations that prevented them to have a linear way of representing colors. that means that 0.5,0.5,0.5 through a monitor is not half way between black and white (it’s darker). Note that black and white remains the same though. +
  If we do not take that into account, the rendered images are overly darken and feels dull. +
  LCD monitors still mimic this physical limitation (I guess for backward compatibility). +
  *Output correct colors* +
  Gamma Correction is the technique that tends to correct the issue. Gamma is an power factor applied to the color by the monitor when lighting a pixel on screen (or at least a simplification of the function applied). So when we output the color, we have to apply the inverse power of this factor to nullify the effect : finalColor = pow(computedColor, 1/gamma); +
  
  *Knowing what colors we have as input* +
  The other aspect of gamma correction is the colors we get as input in the rendering process that are stored in textures or in ColorRGBA material params. Almost all image editors are storing color data in images already gamma corrected (so that colors are correct when you display the picture in a viewer of in a browser). Also most hand picked colors (in a color picker) can be assumed as gamma corrected as you most probably chose this color through a monitor display.
  Such images or color are said to be in sRGB color space, meaning “standard RGB” (which is not the standard one would guess).
  That means that textures and colors that we use as input in our shaders are not in a linear space. The issue is that we need them in linear space when we compute the lighting, else the lighting is wrong.
  To avoid this we need to apply some gamma correction to the colors : (pow(color, gamma);
  This only apply to textures that will render colors on screen (basically diffuse map, specular, light maps). Normal maps, height maps don’t need the correction.
  
  This is the kind of difference you can have : +
  left is non corrected output, right is gamma corrected output. +
  image:http://i.imgur.com/uNL7vw8.png[uNL7vw8.png,width="",height=""]
  
  
  
  === Implementation
  
  *  To handle proper gamma corrected ouput colors, Opengl expose an ARB extension that allows you to output a color in linear space and have the GPU automatically correct it : link:https://www.opengl.org/registry/specs/ARB/framebuffer_sRGB.txt[https://www.opengl.org/registry/specs/ARB/framebuffer_sRGB.txt]
  *  To handle the input, instead of classic RGBA8 image format, one can use SRGB8_ALPHA8_EXT which is basically RGBA in sRGB. Using this you specify the GPU that the texture is in sRGB space and when fetching  a color from it, the GPU will linearize the color value for you (for free). There are sRGB equivalent to all 8 bits formats (even compressed format like DXT).
  *  But all textures don't need this. For example, normal maps, height maps colors are most probably generated and not hand picked by an artist looking through a monitor. The implementation needs to account for it and expose a way to exclude some textures from the sRGB pipeline.
  
  Gamma Correction in jME 3.0 is based on those three statements.
  
  [IMPORTANT]
  ====
  Note that Gamma Correction is only available on desktop with LWJGL or JOGL renderer. They are not yet supported on Android or iOS renderers.
  ====
  
  
  