Refine colorInteropID support - #2560
Conversation
Signed-off-by: Doug Walker <doug.walker@autodesk.com>
|
|
doug-walker
left a comment
doug-walker
left a comment
There was a problem hiding this comment.
Here are some comments that might be helpful to reviewers of this PR.
| // New in OpenEXR v3.4 | ||
|
|
||
| IMF_STD_ATTRIBUTE_DEF (colorInteropID, ColorInteropID, std::string) | ||
|
|
There was a problem hiding this comment.
Updated the links and moved this up to be next to chromaticities.
|
|
||
| If the `chromaticities` attribute of inFile contains chromaticities that | ||
| do not match ST 2065-1, a 3x3 matrix will be computed and applied to convert | ||
| the color space while generating outFile. |
There was a problem hiding this comment.
I found the existing comment about chromaticities very confusing and misleading, so decided to rewrite it, even though I did not change anything about how exr2aces works in this regard.
| For RGB images, specifies the CIE (x,y) chromaticities of the | ||
| primaries and the white point. | ||
| primaries and the white point. Note: For most purposes, this | ||
| attribute has now been superseded by the colorInteropID. |
There was a problem hiding this comment.
Was trying to figure out the right language here to capture the fact that the CIF OpenEXR document recommends that people switch over to using colorInteropID rather than chromaticities for most purposes.
|
|
||
| </td> | ||
| </tr> | ||
|
|
There was a problem hiding this comment.
Updated the links and moved this up to be next to chromaticities.
| Application developers are asked to take care when writing OpenEXR | ||
| files to avoid writing or propagating color space metadata which may | ||
| be incorrect. The colorInteropID should be omitted or set to ``unknown`` | ||
| unless the application is confident in the value being written. |
There was a problem hiding this comment.
Rewrote this based on colorInteropID rather than chromaticities.
In particular, you will notice that I removed the sentence: "If a file doesn't have a chromaticities attribute, display software should assume that the file's primaries and the white point match Rec. ITU-R BT.709-3." This was intentional for several reasons:
- It contradicts the new Color Interop Forum OpenEXR recommendation.
- It should probably be up to the application and/or color management system to determine the default, rather than making a blanket statement in OpenEXR.
- I feel this is partially responsible for application developers sometimes setting the chromaticities to Rec.709 even if they have no idea what the color space actually is, thereby breaking trust in the chromaticities attribute.
And I removed the part about CIE XYZ since it was misleading. If anyone did want to write XYZ values into an EXR file, it would typically not be using illuminant E (1/3, 1/3) as the white point.
There was a problem hiding this comment.
I think it would be worth retaining some description of the chromaticities attribute, even if it is described as deprecated/legacy/ACES-only, since such files will continue to exist and need to be understood.
I'm also not clear if there's still a use case for using it to store completely arbitrary chromaticities, which the recommendation allows as long as no colorInteropID is set.
The Rec,709 and XYZ bits can go, though!
| Color Interop ID. Provides a mechanism to identify the color space of the RGB images. | ||
| See `An ID for Color Interop <https://github.com/AcademySoftwareFoundation/ColorInterop/blob/main/Recommendations/03_ColorInteropID/ColorInteropID.md>`_ | ||
| and `Identifying the Color Space of OpenEXR Files <https://github.com/AcademySoftwareFoundation/ColorInterop/blob/main/Recommendations/04_OpenEXRFiles/OpenEXRFiles.md>`_ for details. | ||
| New in OpenEXR v3.4. |
There was a problem hiding this comment.
Updated the links and moved it up to be next to chromaticities.
| // Color Interop Forum recommendation for OpenEXR files. | ||
| // | ||
|
|
||
| const std::string& acesColorInteropID (); |
There was a problem hiding this comment.
What happens if a file has acesContainerFlag and Chromaticities set to ACES, but the colorInteropID set to something else? Should the input side error, or change the colorInteropID on reading? Arguably, SMPTE 2065-4 would say that correct behavior is to ignore the colorInteropID, so it "doesn't exist" in ACES files
| // ColorInteropID -- leave a part's existing "data" tag alone, since | ||
| // it marks image data that is intentionally not color managed. | ||
| // | ||
| if (!hasColorInteropID (dst) || colorInteropID (dst) != "data") |
There was a problem hiding this comment.
Does this enforce that if the first part is data, then all parts must be data, but not the other way round? Is that intentional? (or should the clause also be skipped if src has a colorInteropID set to data, and the checkSharedAttributesvalues function have a similar clause?)
In any case, if parts are written with different colorinteropIDs, this function will delete that information from other parts, causing the reader to treat them as being in the wrong space. I would prefer either that the library always checked for colorInteropID consistency on MultiPartOutputFile with no option to bypass test or automatically "fix" attribute, or else all the colorInteropID logic was dropped from the SharedAttribute code, making the multipart rules of the Recommendation less strict.
|
What are your thoughts about adding support for colorInteropID names to the Chromaticities? Perhaps the spaces listed in the recommendation (lin_rec709_scene, lin_ap0_scene, lin_ap1_scene, lin_p3d65_scene, lin_rec2020_scene, lin_adobergb_scene) could be added as static Chromaticities variables, and a function added to turn those strings into chromaticities? For lightweight utilities that aren't intended to be part of a VFX pipeline so don't need OpenColorIO, some kind of built-in support to help convert images to and from known space could encourage adoption of the attribute. |
2 participants
Now that the ASWF Color Interop Forum has published the Recommendations for the Color Interop ID and for identifying the color space of OpenEXR files, I've made an attempt to build on Cary's earlier PR and integrate the standard colorInteropID attribute more fully into the library.
This PR was assisted by Claude Code Sonnet 5.