Provide a way to specify the standard `sRGB` colorspace in configs.

[MrLixm]

Hello, The suggestion is as follow : offering a way in config to specify the colorspace in charge of defining the conversion between the reference and the sRGB "display" colorspace.

Why

I think it will not be too ambitious to say that the majority of config ever created defined the sRGB display colorspace in some way and that this colorspace remains used in the majority of the data manipulated by artists.

On another side, with the implementation of OCIO in most DCCs, the vendors usually had to implement a way to convert legacy workflow and tools, most of the time "sRGB based", to whatever is defined in the OCIO config. This is the case with Substance Painter, which requires a role named substance_3d_painter_standard_srgb in the config to be used for some color-picking operations and other UI elements. Following a recent discussion in the Redshift discord, it also seems this render engine tries behind the scene to find what could be the sRGB colorspace. (I'm not sure what it is using it for though). And I'm sure we could find other examples of applications that try the same thing ...

This is where having in the config, a standard syntax to tell "look, this is the sRGB Display colorspace in this config, this is how you convert from sRGB to the reference colorspace" ; a progress in trying to have everyone speak the same language, as per OCIO initial goal.

Questionning

• Does this standard should defined the sRGB "Display" colorspace, or it's linear brother (BT.709 primaries + D65) ?
• Provide a way to also specify it via environment variable for config not defining it ? Applications needed a specific behavior ?
• What could be the potential reasons to not push for this suggestion ?

Relationship with #1639

If ever this related issue resolve to a new interchange format, OCIO could even provide the "sRGB standard" by itself. (ex: it would be trivial if the interchange is CIE-XYZ-D65 to have a built-in transform to sRGB).

I do think this deserved its own issue as its faith should not depend on this other issue.

Cheers. Liam.