Just wanted to clarify this one. For some reason, they have used "sRGB" to denote "linear color space" in DirectX and OpenGL, which are just two separate things.
Indeed, you can convert from linear to non-linear color spaces and vice-versa by using
Gamma correction.
RGB color space by itself lacks any standard or definition, so sRGB was proposed as a standard, which is defined by specifying
white point and three
chromaticities. For instance, there is also
Wide gamut RGB,
Adobe RGB and so on.
Now, the conversion from one color space to another, where the color gamut is different, you would need to convert your initial color space to
CIE XYZ by using linear transformation and then to the desired color space.
This is why it is simply wrong to call sRGB "linear" and non-sRGB "non-linear" and do the conversion between both using gamma correction. In reality, both typical RGB and sRGB may or may not be linear.
In fact, typically, you can assume that your RGB color space is
actually linear. You don't need to voluntarily apply any gamma correction there. Since it lacks standard definition, you can simply assume that when you work with RGB, you work in sRGB, or in Adobe RGB - whatever your choice is. In order to properly standarize your color space, you would need to convert it to one of perceptually uniform (or supposedly) color spaces such as
CIELAB,
CIELUV, DIN99, ATD95,
CIECAM, or at least CIE XYZ, which can actually represent all visible colors by human eye, unlike RGB, which is limited by triangle in CIE diagram.
Now, the problem is that most LCD displays apply huge gamma correction to the input image. Not only that, they may also pre-process images and oversaturate them too. Why? To sell better since higher contrast and crispier images appear prettier, but in the end you receive a very distorted image.
This is not your problem, it is a problem of display's manufacturers and vendors! You simply can't make an application that will predict all of the monitors out there, so it's their responsibility to generate final image as accurate as possible.
I don't know why they introduced "sRGB" into DirectX and OpenGL - after all, suposedly, you are already working in sRGB and it's display's job to properly represent input sRGB data so that output strictly conforms to sRGB, or any other standard. If you do gamma correction in your application - well, you still don't know how display is going to re-transform your image data, so in the end you may actually get less accurate results.
My guess is that they introduced so-called "sRGB" in APIs just for the hype of it, e.g.: "We can now store textures and front-buffer in gamma-adjusted format! WOW!" (like we couldn't do it back in 1969).
You may check some of the following bibliography to figure out more about different color spaces (you can see by the dates that this is a very studied topic, yet it seems that people making changes in DirectX/OpenGL standards regarding sRGB have never read them):
1. Poynton, Charles. Digital Video and HDTV Algorithms and Interfaces. Morgan Kaufmann, 2003.
2. Poynton, Charles. "Frequently-Asked Questions about Color."
http://www.poynton.com/ColorFAQ.html
3. Hill, Francis S. Computer Graphics using OpenGL. Prentice Hall, 2000.
4. Hearn, Donald, and Pauline M. Baker. Computer Graphics, C Version. Prentice Hall, 1996.
5. Luo, Ronnier M., Guihua Cui, and Changjun Li. "Uniform Colour Spaces Based on CIECAM02 Colour Appearance Model." Color Research & Application (Wiley InterScience) 31, no. 4 (June 2006): 320-330.
6. Lindbloom, Bruce J. "Accurate Color Reproduction for Computer Graphics Applications." Computer Graphics 23, no. 3 (July 1989): 117-126.
7. Brewer, C. A. "Color Use Guidelines for Data Representation." Proceedings of the Section on Statistical Graphics. Alexandria VA: American Statistical Association, 1999. 55-60.
8. MacAdam, David L. "Visual Sensitivities to Color Differences in Daylight." (Journal of the Optical Society of America) 32, no. 5 (May 1942): 247-273.
9. Schanda, Janos. Colorimetry: Understanding the CIE system. Wiley Interscience, 2007.
10. Pratt, William K. Digital Image Processing. 3rd Edition. Wiley-Interscience, 2001.
11. Keith, Jack. Video Demystified: A Handbook for the Digital Engineer. 5th Edition. Fremont, CA: Newnes, 2007.