Revisit role assignments

[doug-walker]

The role assignments from the aces_1.2 config have sometimes been controversial and should be re-evaluated for the new configs. The aces_1.2 roles were as follows:

roles:
  color_picking: Output - sRGB
  color_timing: ACES - ACEScc
  compositing_linear: ACES - ACEScg
  compositing_log: Input - ADX - ADX10
  data: Utility - Raw
  default: ACES - ACES2065-1
  matte_paint: Utility - sRGB - Texture
  reference: Utility - Raw
  rendering: ACES - ACEScg
  scene_linear: ACES - ACEScg
  texture_paint: ACES - ACEScc

Here's a proposed strawman with updated roles for people to react to:

roles:
  aces_interchange: ACES2065-1
  cie_xyz_d65_interchange: CIE-XYZ-D65
  color_picking: sRGB - Display
  color_timing: ACEScct
  compositing_linear: ACEScg
  compositing_log: ACEScct
  data: Raw
  default: sRGB - Texture
  matte_paint: ACEScct
  scene_linear: ACEScg
  texture_paint: sRGB - Texture

Proposed changes:

• Add the interchange roles.
• Remove the rendering role since the configs are intended to be general purpose and allow the choice of a few options rather than locking into one (ACEScg and linear Rec.709 being the most common).
• Removed the reference role, since it has caused a lot of confusion and is not interpreted consistently.
• Updated ACEScc to the more recent ACEScct, which was not around when the original ACES config was developed.
• The matte/texture paint roles always seemed backwards in the original. (A matte painting needs more than sRGB range.)
• The default role is primarily for files. While ACES2065-4 specifies OpenEXR as the preferred format for ACES image files with a color space of ACES2065-1, I'm not sure that's the case in practice. Thoughts?
• The color_picking one is more challenging. We don't have a way to refer to a display+view unless we add a color space for it. However the display color space on it's own will only get the untonemapped view transform, so we may need to add a color space for sRGB with an ACES view transform, or else omit the role.

The current draft of the CG config has the following roles:

roles:
  aces_interchange: ACES2065-1
  cie_xyz_d65_interchange: CIE-XYZ-D65
  color_timing: ACEScct
  compositing_log: ACEScct
  data: Raw
  default: ACES2065-1
  scene_linear: ACEScg

So some of the proposed changes have already been implemented. Some roles were dropped and perhaps that is even preferable for some of the less used ones. But I wanted to ensure it's an intentional choice and create an issue to capture opinions.

[KevinJW]

Easy comments first:

Interchange roles +1 ACEScc -> ACEScct +1 matte_paint +1

default role - I'd go ACES2065-1 for a generic config, what we do internally it would be more likely ACEScg but that would be too big a shift for the public

texture_paint - we do ACEScg primaries with a mixture of encoding functions "depending", but others might want something else.

Colour picking - hmm the fact that views and displays are not a colour space per se appears to be topic du jour...

[flord]

IIRC, some applications like Maya are hard coded to use the rendering role. Why are they not using the scene_linear role? Good question.

[doug-walker]

@flord , Maya uses the rendering role because, in practice, the scene_linear role is what is used for compositing and there are situations where they might need to be different (e.g. rendering in ACEScg but compositing in the camera primaries).

[zachlewis]

Thinking about Liam's ticket #1667 -- would DCCs find it useful if we defined / enumerated either a linear_srgb role, or an srgb_texture role, or both?

• PRMan requires (?) user configs to specify a "linear_srgb" role and a "rendering" role
  • https://rmanwiki.pixar.com/display/REN24/Custom+OCIO+Config
• Houdini wants users to set an env var: $HOUDINI_OCIO_SRGB_FILE_COLORSPACE
  • https://www.sidefx.com/docs/houdini/io/ocio.html
• Per Liam's #1667, Substance Painter 3D supports a substance_3d_painter_standard_srgb

On the other hand, it might be more appropriate / less contrived for DCCs to let OCIO FileRules handle whatever DCCs intend to do with an "srgb_texture" role.

[KevinJW]

Following on Zachs comment key for me would be to define the role in terms of what expectations it might have, for instance how do the applications expect it to relate to the other roles and colour spaces. Do they expect it is a full colour managed (including primaries conversion) or are they using it as a shorthand for being encoded with the sRGB transfer function, so that they can pass it direct to the GPU as a texture

Looking at the houdini docs "If this variable is not defined, the OpenColorIO config file is searched for a colorspace that matches srgb, either fully or partially." sounds scary to me.

With renderers it is quite possible they are making assumptions about true sRGB primaries and using that to do some kind of mapping to spectral for certain effects, or maybe not.

[KevinJW]

I'll also comment that Substance's use of the sRGB is not the same as my previous comment:

The color space matching the [standard sRGB](https://en.wikipedia.org/wiki/SRGB) color space (IEC 61966-2-1:1999).

This color space is used in several places inside the application:

To convert color set in the hexadecimal field of the color picker.
To save and load color swatches within the color picker.
To be listed as a Display in the color picker list.

this would not necessarily be compatible as the colour picker requirements might ned a view/display rendering and might be different depending on what other colour management is going on with the display. e.g. Should it be different if I have a P3 display vs a Rec709/1886 vs sRGB (whatever that means!)

[sharktacos]

I find "color_picking: sRGB - Display" problematic as it results, for instance in Maya, in values well above 1 in shaders, breaking the PBR rule of energy conservation. I'd propose a more sensible default for picking colors found on a reflective surface material would be:

color_picking: Utility - Linear - Rec.709

This is preferable to ACEScg as the colors on the edge of the ACEScg gamut are only found in lasers and such. That said, something a bit larger than Rec709 such as linear P3 might be worth considering.

[sharktacos]

matte_paint: ACEScct texture_paint: sRGB - Texture

This is probably something for Foundry to address, but thought I'd mention that Nuke uses the matte_paint role for the 8-bit default, and texture_paint as the 16-bit log default, which is the opposite of the above very sensible roles. That's a head-scratcher.

[doug-walker]

Thanks for all the feedback!

We've had a lot of discussion about this at the config working group meetings and also reached out to a few vendors.

@sharktacos, thank you for your comment about the *_paint roles. We decided to continue with the type of mapping that was used in the previous ACES configs, even though they seem backwards, in order to minimize disruption to apps that rely on them.

Here are the role assignments we wound up with for the initial release of the configs:

roles:
  aces_interchange: ACES2065-1
  cie_xyz_d65_interchange: CIE-XYZ-D65
  color_picking: sRGB - Texture
  color_timing: ACEScct
  compositing_log: ACEScct
  data: Raw
  matte_paint: sRGB - Texture
  scene_linear: ACEScg
  texture_paint: ACEScct

The points about the color_picking role and a possible role for an sRGB texture space are well taken and will be good to revisit after the 2.2 release.

[sharktacos]

Seeing that the “default” role is not included. How will that effect color management in Maya? The default role there plays an important part in how we set up color management. Hope that won’t be going away.

[doug-walker]

@sharktacos , the default role has been supplanted by the Default File Rule, which is still present (and set to the same value the default role had in the previous ACES configs).

Maya uses the File Rules, so removing the default role should not have any impact, but please let us know if you find any issues.

[sharktacos]

@doug-walker Thanks so much for clarifying. Yes, that works just fine in Maya.

[scoopxyz]

Just putting my vote to change texture_paint to something which doesn't linearize to values >1.0

From some historical git analysis I really think we're just persisting a bug/mistake to have it be ACEScc or ACEScct. Copying my comment from Slack here:

Just took a look. It has only been this way for the singular ACES 1.0.3 config contributed by HPD. All other configs use a "raw" or "sRGB" display-referred space. In the README for that config (here) they say "texture_paint: Raw" as roles. It seems to trace back to this single commit from HPD's branch (here). Which involves changes to the matte_paint and texture_paint roles... with no explicit comments to the intent, he sets the general matte_paint role to sRGB and the texture_paint role to ACEScc... I think we're just persisting a mistake/bug. However the 1.0.3 PR was merged by me... so I also blame myself :sob:

[doug-walker]

Most of these changes have been implemented. Please open a new issue to request further changes.