Roadmap goal: Clean up color management for OIIO 3.0

[lgritz]

I think we should make sure that for OIIO 3.0 (i.e. this fall's release), we should fully align to the core color space nomenclature that OpenColorIO, MaterialX, and OpenUSD are gravitating toward, which is documented here: https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.Specification.md#color-spaces-and-color-management-systems

This means a few things, at least:

1. We should decide once and for all if OCIO should be a required dependency of OIIO -- in particular, a new enough version to support the "built-in configs" -- so it can do most of the heavy lifting for us and 100% be confident we don't implement any color transforms differently than they do (because we'd always be using their code).
2. We should support all of those names, both in implementation and documentation, for the color spaces they describe and be sure we're talking about them and behaving consistently with those other projects.
3. If in (1) above we choose not to require OCIO, we should ensure we have fallbacks that let us properly transform between them. (We currently do a few special cases.)

[lgritz]

🎣 Mackerel! This would be a great task for somebody to take on who cares about this topic and being consistent in our treatment of color space names. It's not really rocket science in terms of requiring especially advanced programming skills, nor extensive knowledge of deep OIIO internals. The surface area of the code base that it needs to touch is not very large, but getting it right would have a big impact on user experience. Adding OIIO to the alliance of {OCIO, MaterialX, USD} all using these names consistently would be a good thing.

[BrianHanke]

I might be able to help with this! I'm knowledgeable about OCIO and I'm interested in making it more accessible and user friendly. I get by in C++ and Python but I'm not a pro developer by any means.

[JGoldstone]

Thanks for stating the problem; I think this came up earlier when I was in a four-day fugue going after a multithreading/multihost caching bug, and never went back, so now ... I can.

[lgritz]

Update

For 3.0, we took the following important steps forward for color management:

• OCIO 2.2+ is now a required dependency. That's new enough to include "built-in" configs, so all builds of OIIO 3.0+ can be counted on to at least support the built-in color spaces.
• We now no longer user "linear" generically. Generally, we eschew its use, but when encountered, it will be interpreted as "lin_rec709". Image reader plugins are much more explicit and careful about the color spaces that they think the images are.

We hope that for 3.1 and beyond, we can shift to as closely as practical, following the color space naming conventions of the Color Interchange Forum, as their choices solidify.

[mccartnm]

Update: I see I've missed a PR dealing with this issue. I will direct any followup there: #4840

---

Original post:

I don't mean to bring up an old post so let me know if this would be better served as it's own question (or tell me to go have words with other parties!).

In terms of ACES, or other color standards, lin_rec709 is not typically the scene_linear role. So when we booted up our rendering util with OIIO 3.X we were puzzled to see the app apply that as an input transform of already scene-referred-linear material (in terms of that color pipeline's references).

Defaulting to scene_linear over lin_rec709, to let the configuration decide what that means, is what I think we're after. This appears, from a super-quick glance, to be what Nuke and other DCCs are doing. Unless there's just an avoidance of that close of a tie with OCIO's naming convention?

Or perhaps a global attribute like OIIO::attribute("scene_linear_colorspace", "...")?

We've had to pin a small hack in our image reading code to avoid this but I would like to explore more robust options or at least add enough details to the hack comment 😅

[lgritz]

The strategy has been revised again for 3.1.

"scene_linear" means whatever that role is in your active OCIO config.

"linear" is considered deprecated, since it was sloppy and ambiguous.

OpenEXR files that do not explicitly say what they are will not have any assumptions made, and in particular will not assume to be lin_rec709.

[lgritz]

I'm going to close this issue, which referred to goals of 3.0. Should have been closed when 3.0 was released.