OpenEXR color management

[doug-walker]

OpenEXR and OpenColorIO are both ubiquitous ASWF projects but do color management in (currently) incompatible ways:

OpenEXR

• Chromaticities attribute (the current official mechanism, but not widely or well implemented)
• Proprietary/Vendor-specific color space name strings (common de facto mechanism)

OpenColorIO

• Color space is declared via a name string (meaningful to a specific config file)
• No mechanism for handling chromaticity data from OpenEXR
• Historically, no way to bridge out to color spaces not included in the config (though that is now possible for apps that implement it)

It would be helpful to have a recommended best practice for reliable color management of OpenEXR files that leverages OCIO.

Probably no development work is needed in the OpenEXR library, though it may be helpful to add some features to the OCIO library. At a minimum, the ocioconvert sample app should be upgraded to implement the recommended best practice.

Here is a slide deck from an OpenEXR TSC meeting a few years ago (with some updates in blue). This outlines the problem and discusses possible solutions. This is not intended as a specific proposal as much as just a straw man to get people thinking and seed the discussion.
https://docs.google.com/presentation/d/1sY55UHYi2AJF6EPYDYY-mvaJUCzZCkWisrj-a9yhg2w/edit?usp=sharing

[lgritz]

Just my opinion, but I think that the right first steps on the OpenEXR side are:

• officially deprecate the use of the ColorPrimaries attribute (if we haven't already)
• pick and document a reserved attribute name where color space information should be stored ("ColorSpace" maybe?)
• document that if this is present and the value is one of the blessed names or aliases in the Color Interop list, it should be assumed to be the source of truth for the pixel data in the image
• advise that while libOpenEXR itself does not plan to add color space transformation functionality, the expectation is that all applications reading and displaying exr files should know what to do with at least the canonical set of names

Bonus questions for us here to ponder:

• Do we also want to add official exr attribute names to store a path reference to the config (or even the entire config contents) to allow a completely self-contained color profile for cases where the color space is not one of the blessed Color Interop canonical names?
• Do we want a notation for how to express that the pixels in the exr file have already had some kind of display/view or look transformation applied? Or in general how applications can express what's going on when it's not in one of the handful of CI color spaces?
• Anything else relevant that's not captured by the color space name but that people wish was documented in the file related to color?

[peterhillman]

@lgritz by ColorPrimaries did you mean the OpenEXR chromaticities attribute? That is part of the ACES Container format specification (SMPTE ST 2065-4) so deprecating it may be difficult.

I would be keen to continue to allow arbitrary spaces which aren't a blessed name, and can be interpreted without the need for an OpenColorIO configuration. Perhaps the ColorSpace attribute could have a value that indicates the chromaticities is correct. That logic could be supported by libOpenEXR, so calling chromaticities() on a input file returns the numbers represented by the ColorSpace name instead of the chromaticities if it defines a known space.

We should also consider whether the adoptedNeutral standard attribute needs to be deprecated or at least clarified.

[lgritz]

Oof, yeah, I misremembered the name as I dashed off that note. Sorry about that.

[ssh4net]

Adobe made a good work in its Adobe DNG SDK. With a proper authoring DNG file include explicit information about color spaces and light setup (up to storing SPD). And sound like that was inherit from ICC specs.

[KelSolaar]

Just reading this, had the same reaction than @peterhillman W.R.T. SMPTE standard.

Perhaps the ColorSpace attribute could have a value that indicates the chromaticities is correct. That logic could be supported by libOpenEXR, so calling chromaticities() on a input file returns the numbers represented by the ColorSpace name instead of the chromaticities if it defines a known space.

What about having either attributes but not BOTH at the same time, effectively making it illegal?

[peterhillman]

What about having either attributes but not BOTH at the same time, effectively making it illegal?

In effect that's what I'm suggesting. One consideration is how to handle legacy files: with the current library, a tool could write contradictory ColorSpace and chromaticities, because there's nothing to stop you doing that. It would be quite disruptive and confusing if a new library refused to read those files, but they still worked in older libraries. A later library might instead silently hide the chromaticities attribute on reading if the ColorSpace overrides it. Whether the writing side should error if you attempt to write contradictory data, or just silently fix things, is another debate.

[KelSolaar]

We could always read the files, raise a warning but forbid writing them when the two attributes are present? (Which is kinda what you wrote, just saw your reply after posting mine)

[zachlewis]

Determining contradictions between chromaticities data and OCIO color space representations could be challenging... in particular, ACES IDTs tend to use one of two different methods for chromatically adapting D65 devices to the ACES2065-1 reference space's D60 whitepoint, depending on the vendor. On the other hand, which method to use with which vendor is a known quantity.

Personally, I think we should allow both attributes when writing ACES2065-1, even if that is super redundant -- just to make things easier on downstream folks.

[brechtvl]

I'm less concerned about determining if there is a contradiction, than having a well defined and complete method to interpret the attributes.

One way or the other, an application needs to deal with getting only chromaticities, only ColorSpace, both or neither. Maybe some combinations are considered invalid, but nevertheless it has to be interpreted somehow and ideally that will be consistent across applications even when invalid.

Determining contradictions between chromaticities data and OCIO color space representations could be challenging... in particular, ACES IDTs tend to use one of two different methods for chromatically adapting D65 devices to the ACES2065-1 reference space's D60 whitepoint, depending on the vendor. On the other hand, which method to use with which vendor is a known quantity.

Not sure I understand this correctly. If there can be a contradiction between chromaticities and ColorSpace attributes, or some vendor specific metadata that should be taken into account, can the recommended practice be extended to make this well defined?

[doug-walker]

@brechtvl , I agree, the recommendation needs to provide guidance for all three scenarios (chromaticities, ColorSpace, or both).

Zach's comment was referring to the problem of matching up chromaticities data to a color space in a config which may be defined in relation to a reference space with a different white point, such as ACES2065-1. However, in practice, the difference between the two most common chromatic adaptation methods is only about 1% and I think the tolerance should be loose enough to accommodate that.

[peterhillman]

That would be for a situation where there's an image which has a chromaticities attribute with non-standard values, and it needs to be managed with OCIO? One approach would be to 'reverse engineer' the config to deduce the chromaticities of each space to find one with similar chromaticities. Indeed, chromatic adaptation will complicate that process.
Also, there may be no appropriate space in the config.

A more robust approach to handling the chromaticities tag would be to apply a matrix transform to bring the image into a standard space defined in the config that has known chromaticities, and then do further management through OCIO.

Also, what happens if a new standard color interop space is introduced? A file tagged in a new space won't be understood by older code unless it supports OCIO and an updated OCIO config is provided that specifies it. If writing software always wrote the chromaticities as well as the named ColorSpace, then reading software would always have a fallback if it didn't recognize the ColorSpace name (but should always use the ColorSpace instead of the chromaticities if it recognizes the name)

[doug-walker]

@peterhillman , yes, the config merge feature for OCIO has most of the machinery for matching up chromaticities with color spaces.

On the OCIO side, we would offer a function to return a color space from a chromaticities attribute. The application could then decide if it wants to add that to the in-memory config, or extract the matrix and apply it separately.

Your last point about versioning is key and that is why we proposed adding both a color space name attribute and a config name attribute. The name of the config with the current list of Color Interop Forum spaces is "core-renderer-config-v1.0.0" and another one would be created if more color spaces are added.

[zachlewis]

I've changed my mind. We obviously cannot prevent anyone from writing both a chromaticities attribute and the OCIO attributes, but I think we should encourage developers, by default, to only write chromaticities data when the OCIO attributes are missing.

If writing software always wrote the chromaticities as well as the named ColorSpace, then reading software would always have a fallback if it didn't recognize the ColorSpace name

I feel like this is a slippery slope... but how about this as a compromise -- what if we also provided guidance to developers for exposing a "Compatibility Mode" option to users to make the metadata a little more portable:

• If the color space indicated by the metadata can be matched to a color space in one of OCIO's builtin configs (e.g., a core-renderer-config, the ACES studio-config, etc.), drop the chromaticities attribute, and make sure the ocioConfigName and ocioColorSpace attributes match the builtin config's name and color space name.
• If the indicated color space cannot be matched to a builtin config's color space, drop the OCIO attributes entirely, and only persist / derive chromaticities. (exception: 'data' color spaces)
• Exception: ACES2065-1 encodes persist both OCIO and ACES attributes

In other words, "Compatibility Mode" means OCIO config names and color space never reference external OCIO configs -- they're either "normalized" to a common reference (e.g. one of the builtin OCIO configs), OR you end up with chromaticity data instead.