Align MaterialX to ASWF Color Interop Forum recommendation

[doug-walker]

As proposed at the August 11th TSC meeting, this PR brings to MaterialX full support for the ASWF Color Interop Forum recommendation Color Space Encodings for Texture Assets and CG Rendering that is used in other ASWF projects and OpenUSD. It supersedes PR #2514.

Support has been retained for all existing colorspace names and cmlib nodes.

Per the discussion at the TSC meeting, this PR does not upgrade existing documents when reading them to use the new names, however, that is still recommended as a follow-on step. Converting to the new names would likely simplify loading of MaterialX documents into OpenUSD. As things stand with this PR, the earlier MtlX names persist into the USD representation of the material, where they won't be recognized.

PR contents:

• Adds color spaces and nodegraph implementations for "Linear Rec.2020", "ACES2065-1", "CIE XYZ-D65 - Scene-referred", and "sRGB Encoded AP1".
• Since these are public-facing, existing stdlib nodedefs have been retained without changing their signature to the new name. The nodedefs for the new color spaces use the new names.
• Improves the accuracy of the matrix converting P3 D65 to Rec.709 primaries.
• Adds support for the Color Interop Forum "data" colorspace designation (equivalent to the earlier "none").
• Adds ColorManagementSystem::isNoOpColorSpace to manage what colorspaces are no-ops (includes unit test). Note: this will break ABI-compatibility with the current release.
• Adds ColorManagementSystem::getUserFacingName to convert the colorspace's color interop ID into a name suitable for use in a user interface.
• Updates all documentation. Clarified that the rendering space is not guaranteed to be the document's working color space.
• Adds new mtlx test files in resources/Materials/TestSuite/stdlib/color_management. All colorspace names (new and old) are tested. I validated the resulting renders against OCIO's built-in CG config for ACES.
• Fixes the texture mapping in existing color management tests so that renders may be properly evaluated. Previously, some parts of the tests were not visible in the image because of where they were mapped onto the sphere.
• Changes usage of "lin_rec709" to "lin_rec709_scene" in various .cpp modules that call targetColorSpaceOverride.

Notes:

• All unit tests pass with MATERIALX_BUILD_OCIO both off and on.

Open questions:

• I don't think the nodedefs/nodegraphs in libraries/cmlib should be public. They should more properly be considered part of the implementation of the DefaultColorManagementSystem. The fact that they only convert into Linear Rec.709 makes them fairly useless for people to use in MaterialX documents. In MaterialX.Proposals.md there is a proposed transformcolor node which potentially could be useful in documents, unlike the existing cmlib nodes.
• I did not update references to the earlier color space names in the other .mtlx files in the repo, outside of the color_management test directory, but I'm open to doing so, just let me know.

[doug-walker]

This is actually a trimmed-down version of color_management.mtlx. I did a git mv on that file, so I'm surprised this is showing as a new file rather than as a rename of the existing one. The original "color_management" name was effectively meaningless and so I wanted to make it more precise.

I trimmed the test down to just a few values since the new all_colorspace_names.mtlx test is where we now test that all color space names are supported.

[doug-walker]

@jstone-lucasfilm, I've made the changes to the nodedefs we discussed in the Nanocolor meeting. I updated the PR description accordingly.

[jstone-lucasfilm]

Thanks for this substantial contribution, @doug-walker! I'll defer to you on the correctness of the new matrices, and it's very encouraging that you've validated that the values in all_colorspace_names.mtlx round-trip to the orange target color.

From an initial review, I see two potentially important issues to address:

The first is the default for ColorManagementSystem::isNoOpColorSpace. Before this change, populateColorTransformMap filtered "none" for every color management system, but with a base default of false, any subclass that doesn't override the new method (including the PyColorManagementSystem trampoline in the Python bindings) will be handed a transform from none to lin_rec709_scene, and shader generation will throw on documents that previously worked. Since none and data are reserved by the specification rather than by any particular CMS, I'd suggest the base class recognize them directly, with subclasses extending that set as the OCIO implementation does through isData(). Keeping the early return in populateColorTransformMap would also preserve the current behavior of leaving the port's color space unset, which otherwise flows into the OSL textureresource metadata and the GLSL/Slang uniform inputs.

The second is the potential cost of OCIO lookups. getSupportedColorSpaceName parses a full built-in config on every miss, and populateColorTransformMap now calls it up to four times per color port. Since lin_rec709_scene is a miss for any user config that predates the interop aliases in OCIO, a typical studio config would take the slow path on every color input. Your TODO already identifies this, but since this changelist is what makes the hot path hotter, I'd suggest addressing it here with a memo of resolved names in the implementation class.

A few smaller notes:

1. The Python bindings should expose isNoOpColorSpace and getUserFacingName, with overrides in the trampoline class, since much of the UI code that would use the latter is in Python.
2. The specification lists g18_ap1 and lin_srgb among the names that are "still supported", but cmlib has never provided graphs for either, so I'd suggest either dropping them or adding the trivial remaps. It may also be worth noting that none remains an accepted alias for data.
3. The comment above CHECK(!colorManagementSystem->isNoOpColorSpace("Raw")) says the opposite of what the check asserts.

On your open questions: I agree that the cmlib graphs are more properly an implementation detail of the default CMS than a public node set, and I'd suggest we take that up as a change for a future MaterialX version bump (e.g. v2.x), so that we have the ability to provide upgrade logic to legacy documents. For the other .mtlx files in the repository, I'd suggest updating the ones that act as defaults for downstream documents, namely the colorspace attributes in pbrlib_defs.mtlx, the document color spaces in libraries/bxdf, and the srgb_texture default in creatematerial.py, with the example materials following in a later PR.

Finally, this work interacts with #3005, which adds a GenOptions::xyzToWorkingSpace transform for blackbody and thin-film shading. The XYZ-to-Rec.709 matrix there is a four-digit version of the one you've added to cmlib, and your table of linear working spaces is the natural source for deriving that default from the target color space. Your perspective on the white-point question in that thread would be valuable as well.

Overall this is an excellent proposal, and let's aim to include it in our v1.39.6 release.

[doug-walker]

Thank you for the careful review @jstone-lucasfilm! Totally agree with your findings, and I think they should all be addressed now. I will plan a separate PR to update names in the example materials, as you suggested.

I made a comment in #3005, I hope it was what you had in mind, please let me know if not.

[jstone-lucasfilm]

Thanks so much for this contribution, @doug-walker, and this looks good to me!