Standardized Color Spaces (Initial focus: texture/rendering)

[carolalynn]

Agree on a minimal set of reserved baseline color space encodings that are universally available in addition to definitions of user-defined spaces (i.e., the meaning of “lin_rec709” may not be modified). This set of color spaces would initially be based upon the spaces that MaterialX and OpenUSD support today, specifically for use in texture and render pipelines. Deliverables will include an OCIO config that documents the agreed upon names and transforms for the baseline set.

Here is the current list in MaterialX / USD as a starting point:

• srgb_texture
• lin_rec709 / lin_srgb
• g22_rec709
• g18_rec709
• acescg / lin_ap1
• lin_adobergb
• g22_ap1
• g18_ap1
• adobergb
• srgb_displayp3
• lin_displayp3
• none

[carolalynn]

Linking the NanoColor Charter here for reference: https://docs.google.com/document/d/1eGLtOHY-hNKXdtBUJWQHK25WQcK2zjDJYkldmE6eZVY/edit?usp=sharing

[lgritz]

I've said it before many times, but just to memorialize it in the issue itself:

I think all of these are great except for srgb_texture, and my concern there is twofold, both related to the word "texture":

1. For people who want sRGB for things other than texture, this is confusing -- it's hard to know if this the the space you should use if you're just trying to convert to what will display correctly on an sRGB monitor, or if you are looking for a label to apply to an obligatory-sRGB format you're reading like JPEG or PNG.

2. For people trying to make textures, the fact that only one item in the list has the word "texture" in it might cause them to convert their textures to this color space, whereas I (coming from the high-end renderer world) think that textures stored in sRGB are a bad idea and I'd prefer to steer users to store their textures certainly in a linear encoding, and ideally as either acescg or lin_srgb, depending on which is the working color space the renderer is using for computation.

[anderslanglands]

Just wanted to +1 Larry’s concerns here. I realise it’s almost defacto now but srgb_texture is really a terrible name. Unfortunately looking at the rest of them it sort of implies that the “correct” name here would be srgb_srgb…

I don’t have any better suggestions but it feels like it would be a real shame to canonicalize this since it’s likely these names will be with us for ever more.

[SonyDennisAdams]

I saw it mentioned elsewhere, but I really like when a color space name includes the name of the primaries as well and the name of the curve, and in consistent order. An exception is when the color space name is standard and implies both (e.g., "ACEScc").

[jstone-lucasfilm]

From the USD/MaterialX perspective, I believe all of these names are flexible, and can be safely upgraded through the versioning system in MaterialX. I agree the name srgb_texture is a bit unusual, and its origins can be traced to the OpenColorIO configuration for ACES 1,2, where the MaterialX project inherited its original set of color space names:

https://github.com/colour-science/OpenColorIO-Configs/blob/feature/aces-1.2-config/aces_1.2/config.ocio#L4746

[KelSolaar]

I saw it mentioned elsewhere, but I really like when a color space name includes the name of the primaries as well and the name of the curve, and in consistent order. An exception is when the color space name is standard and implies both (e.g., "ACEScc").

This is what I was doing at work until harder adoption of the ACES config. I go as far as putting the primaries if required:

[KelSolaar]

I would also like to see srgb_ap1, we use this one almost exclusively in Unreal Engine.

[scoopxyz]

Kind of echoing Larry's point and to comment on Doug's excellent point in tonights meeting that we would ideally codify the image state of these spaces as well...

Although I don't agree with the current name I think the intention of the "texture" suffix is to inform that the image state of the texture/buffer/image is scene-referred, which is necessary to distinguish with output-referred spaces like sRGB or Display P3.

So I would be curious to hear if there are non-overloaded terms that could be used to distinguish the two? As a first thought (mostly to spur discussion):

• scene - scene-referred

So: scene_srgb and the rather silly scene_srgb_displayP3

I also must admit that even this distinction is not wholly satisfiying. For example, color textures that drive the "tint" of specular/coat/sheen BxDF shader parameters, while certainly not output-referred, may stretch the meaning of scene-referred image state a little. Perhaps the scene-referred concept of relative scene colorimetry safely encapsulates these concepts...

[anderslanglands]

Thomas’s scheme makes the most sense. Its explicit and consistent.

[KelSolaar]

Proposal for the names:

The User-facing Name (UI name) column represent the current names, what I'm proposing is that we pick one of the Analytical Name \d+, even for UI.

4 variants programmatically generated from the gamut, whitepoint and transfer function, if the 3 of them correspond to a standard, then we use the standard name.

I do think we need to put the whitepoint name in which case it would mean that this is the colourspace adopted whitepoint, i.e., original primaries and new whitepoint, and not that the colourspace has been chromatically adapted to the whitepoint, i.e., chromatically adapted primaries and new whitepoint.

[anderslanglands]

Shouldn't F9 be P3 - D65 - Linear? I'd also make F10 P3 - D65 - sRGB