Hacker News Reader

Comment by kaetemi | Hacker News Reader

Pretty much all modern 3D rendering is done in this color space that supposedly doesn't exist.

Also, normal maps should be flagged as linear, since they should not get converted from the sRGB curve upon sampling.

Linear is a class of color spaces, so which one? It's like if I said some data is in "text format". Is it JSON? YAML? XML? The Unity docs[1] refer to linear vs gamma, not linear vs sRGB. Same with other resources I'm finding. They do call out sRGB as the standard non-linear space, which is consistent with what I'm saying: linear and gamma are classes of color spaces, so which linear space is it?

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.

[1] https://docs.unity3d.com/Manual/LinearLighting.html

Rendering pipelines are in linear RGB. Which has rgb(1,1,1) and rgb(0,0,0) the same as sRGB, but with 1.0 gamma.

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.

You're slightly confused I think. We operate and perform lighting in linear color spaces, but the choice of white point and primaries offers a few degrees of freedom. LDR renderers might opt to stay within linear sRGB primaries, but it's easy to clip against the gamut boundary if doing HDR lighting. A color transform is needed to go to Rec2020 or wider.

Possibly, I might be. (Hence, post processing magic, regarding white points and clipping.) Wasn't the final color space transform handled by the driver? I don't recall having to do any manual color transforms to present a linear RGB render target correctly on an sRGB display, at least. Haven't had the chance yet to experiment with high gamut displays, unfortunately, so I might be missing something.

Fortunately I mostly just deal with embedded graphics that do their technically incorrect blending math in unmanaged sRGB/display space. (:

Ok so, the final display gamut, initial source color gamut, and working gamut are three separate spaces. Effectively, the gamut defines where your primaries are, which are the positions of the unit RGB cube within a larger volume. These three working spaces can be all completely different, and the only thing to ensure is that you are consistent about transforming from one space to the next. It's possible to do operations that take you outside the final gamut, after which you clip or do some other operation. There are no hard and fast rules, although some approaches will certainly look much better depending on lighting conditions (color temperature) and so on.

Does that just mean that the color space is untagged / undefined? (That is in practice how I see a lot of games rendered - way oversaturated on my wide gamut screen.)

For normal maps, the correct color space is definitely "no color space", because the R/G/B channels are used to store a 3D vector and not an actual color.

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.

Normal maps, certainly. I was more confused by the parent's claim that this applied to "pretty much all modern 3D rendering".

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.

It'd probably be reasonable to say the output of a game's 3D renderer is sRGB or something, and to call the eye-searing colors on your P3 monitor a bug.

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 sounds like gp's issue is only with games, i.e. everything else is rendering correctly. Which sounds to me like the video driver isn't applying the correct output profile (but the OS does so regular applications work).

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.

Yeah, I believe the issue here is that games are not usually color managed because that would require tagging the rendered image with a space and then converting it, which would probably delay the render by at least a frame.

The output is either linear RGB in modern pipelines or unspecified probably-sRGB for older pipelines (which usually have wrong lighting math).

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.

In practice, linear texture means "don't mess with the data when sampling", and sRGB texture means "please convert to linear when sampling" (this is a hardware feature).

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.

Reply on news.ycombinator.com