There is a canvas color space proposal under development for both WebGL and 2D canvases. It describes some of the issues with the current situation as well as a solution. The proposal is being discussed here.
It is imprecise to say that gl_FragColor is in gamma space. BTW, this is the first time I have heard it called gamma space. I like to think of it as compressed or non-linear space. Values written to gl_FragColor, OpenGL ES 2 and WebGL 1, or user-defined color outputs, OpenGL ES 3 and WebGL 2, are in linear space. If the the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is SRGB then the values will be compressed to non-linear before being written to the framebuffer. Otherwise they are written as is.
WebGL 1 & OpenGl ES 2 do not support sRGB rendering so the values are written as is. The framebuffer is therefore considered to hold linear data and its values should be compressed to non-linear (a.k.a. gamma corrected) by the browser or window/operating system before being sent to the display, assuming a non-linear display. Unfortunately browsers differ in how they handle this and, especially on mobile devices, it is unclear which if any OSes apply gamma correction. Only in cases where no gamma correction is applied can the values written to gl_FragColor be considered to be in non-linear space.
The canvas color space proposal together with sRGB rendering support is intended to resolve these and other color space issues.
Description: Message signed with OpenPGP using GPGMail