ACES 2 in Game Engines: Variable reference/max luminance

[allenwp (Allen Pestaluky)]

I thought about this again. Textures may should still use sRGB curve. Since creators won’t directly display them as pictures but render them with models, and the tools they used to create textures have higher possibility to use sRGB curve rather than 2.2 curve.

I agree.

I looked into this a bit more and it looks like the glTF spec says this:

The base color texture MUST contain 8-bit values encoded with the sRGB opto-electronic transfer function so RGB values MUST be decoded to real linear values before they are used for any computations.

Which isn’t entirely clear on what function should be used to decode to real linear values.

It does imply that they should be decoded using the inverse sRGB opto-electronic transfer function, but it is not clearly stated. The original sRGB spec CIE 61966-2-1 doesn’t use this sort of terminology for the transfer functions, but it does state that transformation from sRGB code values to CIE 1931 XYZ values should use the piecewise functions and that the resulting XYZ values “represent optimum image colorimetry when viewed on the reference display, in the reference viewing conditions, by the reference observer…”

…in spite of the fact that the reference display uses 2.2 power function for its decoding.

So “simulating” the reference display’s 2.2 power function would be incorrect because using the piecewise function to linearize, according to the sRGB spec, will produce linear values that match the 2.2 power reference display. (It actually doesn’t in practice, but this is how the spec says to do it.)

All that to say, the approach that Windows uses is correct according to the sRGB spec. The sRGB spec also goes on to acknowledge that this creates a mismatch, but states that this mismatch was worthwhile, at least back when sRGB came into existence:

One impact of this encoding specification is the creation of a mismatch between theoretical reference display tristimulus values and those generated from the encoding implementation. The advantages of optimising encoding outweigh the disadvantages of this mismatch. A linear portion of the transfer function of the dark-end signal is integrated into the encoding specification to optimise encoding implementations.

[Stat_headcrabbed (Shengyu Qu)]

@allenwp

Which isn’t entirely clear on what function should be used to decode to real linear values.

I guess contacting Khoronos might help.

@allenwp

All that to say, the approach that Windows uses is correct according to the sRGB spec. The sRGB spec also goes on to acknowledge that this creates a mismatch, but states that this mismatch was worthwhile, at least back when sRGB came into existence:

When sRGB spec was designed(1996), they never thought about the existence of modern HDR spec, so we can’t always follow what the spec says in terms of HDR.

@allenwp

One impact of this encoding specification is the creation of a mismatch between theoretical reference display tristimulus values and those generated from the encoding implementation. The advantages of optimising encoding outweigh the disadvantages of this mismatch. A linear portion of the transfer function of the dark-end signal is integrated into the encoding specification to optimise encoding implementations.

Where does this sentence come from?

[allenwp (Allen Pestaluky)]

Where does this sentence come from?

sRGB CIE 61966-2-1: 5.1 Encoding transformations: Introduction (page 21), just before where it describes the use of a piecewise function to transform sRGB code values to linear XYZ values, in spite of this not matching the way that a reference display with 2.2 power behaves.