Add the OpenEXR recommendation

[doug-walker]

This is the proposed recommendation for reading and writing OpenEXR files, based on many conversations during the Color Interop Forum meetings.

Please note that this will not be merged until after the Interop ID recommendation, but I would like to get it approved and ready to go while it is fresh in people's minds from recent meeting discussions.

Implements issue #4.

Based on this Google doc:
https://docs.google.com/document/d/1MTH1bq2L67ifvdDf64Amhzg4AbkIM5LG6yPHrB96Vwo/edit?usp=sharing

And Sean's initiative to create Mermaid diagrams:
#9 (comment)

[peterhillman]

That seems all very sensible and clear.

I agree with the restriction that all genuine color channels within the same file be in the same space. It could more explicitly state that if a file contains both data channels and color channels, then the data channels should be in different parts to the color channels, and those parts have an colorInteropID attribute set to "data". That way, if you have no choice but to encode non-color data in R,G,B channels, there's a way to indicate that.

Similarly, if a file contains a mixture of color channels in known and unknown spaces, the unknown channels should be in parts with an "unknown" colorInteropID attribute.

You could interpret this as recommending that data channels and unknown color channels be explicitly tagged as being in the same colorspace as the color channels. It should be permitted to have different values for colorInteropID across a multipart file, but all parts which are not set to "data" or "unknown" should have the same value. Code reading images should anticipate that, too.

[zachlewis]

Similarly, if a file contains a mixture of color channels in known and unknown spaces, the unknown channels should be in parts with an "unknown" colorInteropID attribute.

tl;dr --this makes me uneasy. It's not clear to me what "unknown" intends to communicate here, or what to make of the reliability and validity of metadata indicative of an EXR that is explicitly partially color managed.

What does it mean for a file to contain a mixture of color channels in known and unknown spaces? How is the writer able to distinguish known color channel layers from unknown color channel layers, and unknown color channel layers from data channel layers? Is the writer working in a color-unmanaged environment or not? And if not, should the writer be actively tagging channel layers without colorInteropID as explicitly "unknown" in the first place? What level of "certainty" does "unknown" suggest? Does the writer actively want downstream applications to treat channel layers differently because it knows something about the difference between known and unknown color layers that it isn't able to better articulate? Or is the writer working in a color-unmanaged environment, drawing from multiple sources authored under different conditions, and just persisting whatever colorInteropID metadata happens to already exist? If some channels are known, and others are unknown, should downstream processes attempt to resolve all unknown layers to the same color space? If a writer indicates that the main R,G,B channels are known, but others are explicitly "unknown", what should downstream processes do if they must reconcile known and unknown color layers to a single working space? Does it still make sense for downstream readers to parse the filename for hints toward resolving "unknown" channels? Does it make any more or less sense to fail over to a general default color space for EXRs, compared to a known color space as indicated by one of the other channel layers?