For shader math, why should linear RGB keep the gamut of sRGB? sRGB is often contrasted with "linear RGB."


Images are stored on disk and passed to displays in sRGB, which is approximately perceptually uniform in intensity.
Shader math is done in linear RGB, which is physically uniform in intensity.
Gamma correction can be applied to convert between the two.


Now, sRGB has a standard that colorimetrically specifies its gamut, saying exactly where pure red, green, blue and white lie.  But there is no corresponding standard for just "linear RGB."  Any triangle on a chromaticity diagram could be said to be linear, and, indeed, there are several well known gamuts to choose from:



In practice, when we say "linear RGB," we mean "sRGB without the gamma correction."  (This is implicitly what we're doing when we apply sRGB gamma correction as a final post-processing step but ignore color spaces for the rest of the rendering pipeline.)

But why is that RGB gamut the correct one to use for interpolation and lighting calculations?  It seems arbitrary.  If anything, wouldn't we want to use the largest possible gamut for internal calculations, and then clip or scale colors to the output device's gamut at the very end?

Is it that RGB lighting is going to be approximate no matter what, so it doesn't matter which gamut we pick, and we may as well pick the one closest to what the display natively supports?  Is it just negligence?  Or do calculations in these different gamuts actually yield the exact same results, somehow?
Talking about Linear RGB must be avoided because it does not tell you anything about the RGB colourspace intrinsics, i.e., Primaries, Whitepoint and Colour Component Transfer Functions. A few years ago, assuming it was sRGB was middling but nowadays with DCI-P3 and BT.2020 being very common, it must be ruled out.

The ideal gamut for rendering is the one that will minimize errors in respect to a real-world reference or more conveniently a ground truth spectral render. The first takeaway from this sentence is that the various RGB colourspaces are not equivalent and will not produce similar results.

One might think that performing two renders with the same base colours but one where they are encoded with sRGB/BT.709 and the other one where they are encoded with DCI-P3 and then converting the two resulting images to for example ACES2065-1 will yield the same images but it is not the case. Some mathematical operations because of the nature of linear algebra and matrices are dependent on the given RGB colourspace primaries, i.e., on the colourspaces basis. The same operations performed in different RGB colourspace will yield different tristimulus values once converted back to CIE XYZ color space. For example multiplication, division and power operations are RGB colourspace primaries dependent while addition and subtraction are not.



This image illustrates the effect of multiplying various colours by themselves into different RGB colourspaces: the resulting colours are different. The various samples are generated as follows: 3 random sRGB colourspace values are picked and converted to the three studied RGB colourspaces, they are exponentiated, converted back to sRGB colourspace, plotted in the CIE 1931 Chromaticity Diagram on the left and displayed as swatches on the right.

Tests and research conducted by Ward and Eydelberg-Vileshin (2002), Langlands and Mansencal (2014) and Mansencal (2014) showed that gamuts with primaries closest to the spectral locus, i.e. spectrally sharp primaries, tend to minimize the errors compared to spectral ground truth renders.

Here is an image I recently rendered with Mitsuba to re-validate our findings with Anders:



Those are renders of the same scene using BT.709 primaries (first row), 47 spectral bins (second row), BT.2020 primaries (third row), spectral minus BT.709 primaries renders residuals (fourth row), spectral minus BT.2020 primaries renders residuals (fifth row). The last row showcases composite images assembled with three vertical stripes of respectively the BT.709 primaries, spectral and, BT.2020 primaries renders. Direct illumination tends to match between the renders. Areas that show the effect of multiple light bounces, i.e., the ceiling, in the BT.709 and BT.2020 primaries renders tend to exhibit increased saturation, especially in the BT.709 primaries render or slight loss of energy, especially in the BT.2020 render. Excluding outliers, e.g., the visible light source, the RMSE with the spectral render are 0.0083 and 0.0116 for respectively the BT.2020 primaries and BT.709 primaries renders.

Now it does not mean they will always perform better, and one might be able to produce examples that will exhibit a bias toward BT.709/sRGB. The main takeaway is that RGB renders cannot match spectral renders and sharp wide gamuts tend to perform better. As for choosing a rendering colourspace, I would pick one with a wide gamut that encompasses Pointer's Gamut and DCI-P3, BT.2020 or ACEScg are excellent candidates for that.