"linear" is not a color space. Presumably they mean something like, sRGB but with linear gamma, but without understanding the design goals of this format it's hard to say what purpose the linear encoding serves.
[1] The sRGB EOTF has a nominal gamma of 2.2 but it is actually a piecewise function with gamma varying from 1.0 to 2.4.
"Linear" means the colors are stored in a state that means you can do linear transformations on them (basic math in other words) without loss. You can't do this with gamma corrected colors - for example as you say, the sRGB EOTF is a piecewise function so by definition it's not a linear transformation.
So yes, when talking about "linear" colors, they still come from some gamut like sRGB or a larger HDR gamut. The linear part means they are safe for use in a renderer's internals.
Also, normal maps should be flagged as linear, since they should not get converted from the sRGB curve upon sampling.
Normal maps aren't images for all that they have an intuitive visual representation. In particular they don't have colors therefore a color space has no meaning.
ETA: a better analogy is "plain text encoded": it's probably utf8, but it could be windows-1252, windows-1250, or who knows what else.
When loading images into the GPU, you flag them as either sRGB or linear. When sampling from a shader the GPU will convert sRGB to linear (this is a hardware feature because many images are in sRGB space), and not make any changes to textures flagged as linear.
Rendering is done in linear RGB space in properly coded game engines, and the final output is generally also linear (with some post processing magic to stay in boundaries). The final swap will convert it to sRGB or whatever your display profile is set to, this is handled by the display driver as well.
Fortunately I mostly just deal with embedded graphics that do their technically incorrect blending math in unmanaged sRGB/display space. (:
On modern engines, rendering is done in linear. A lot of older engines render in unmanaged maybe-sRGB and look like potato, in which case tagging the textures does nothing.
In general either the final render output is linear or "I don't care" probably sRGB, in the first case it's up to your display driver to do the final conversion to your display color space, in which case colors should look correct, but the game engine may have already limited colors (by some post processing magic) within sRGB boundaries if it's not aware of your display range. Or it may have messed up if it can't make sense if the display range. In the other case, I'm not sure if there's a solid definition, the driver will probably assume the color space is already good.
For video game graphics, the ideal color space is "looks good on the median user's television once we apply our gamma curve", which is not actually a real color space. It's more like a statistical distribution of color spaces.
With video game graphics I'm surprised that PC games aren't handled differently. To the extent that TVs aren't garbage (huge assumption) traditional SDR TVs mostly target sRGB. But PC monitors can be almost anything, there are a ton of wide gamut (e.g. P3) screens out there, and saturated games can be retina-searing on them.
But I think kaetemi's comment was talking about the intermediate calculations, which don't usually use sRGB. The "linear" color space used for those doesn't need to have a rigorous definition; even if there's no mathematically correct way to map a video-game-linear color to an sRGB color, the game company just hand-tweaks it until the game looks good.
It's the driver that does the linear RGB to display space conversion when the engine swaps the render buffer.
In the case of non-specified probably-sRGB color space I have no idea if it converts from sRGB to your display space, or if it just does nothing because it not specified.
Can you actually specify a color profile in the driver itself? I haven't had a color managed workflow in forever but I remember only ever being able to tell the OS.
Yes, it’s exactly that, because:
- almost all the time, the display is sRGB, so that’s your gamut;
- almost all the time, you want to do your lighting and compositing in a linear space.
- and sometimes your channels are normals or something, not colors at all, as others have noted.
So it’s linear in the sRGB 0..255 gamut.
It is a bit of a shame that most easy-to-use tools and workflows are limited to sRGB, so it’s really fiddly to support HDR displays and print.
This is becoming less and less of a safe statement. On the one hand "yay HDR"!
On the other hand, we're in for many years of weird bugs. For example recently I've been working on an app that I want to look good in HDR and I tried to share screenshots. Everything looked good to me. People on the other side were complaining about weird colors. Several hours of investigation later I realized that Windows was switching color spaces in my screenshots. Pressing the print screen button gave me a subtly different result than what I was actually seeing and of course I didn't spot it when emailing off the screen shots.
It's just a laptop, nothing special.
Restricting colour to sRGB is going to be the CGA/EGA in a VGA world of the future.