docs: clarify exr2aces output format #1963
Conversation
Inspired by discussion in AcademySoftwareFoundation#1962. Adds additional background to the ACES Image Container format produced by exr2aces. Signed-off-by: Patrick Hulce <[email protected]>
The committers listed above are authorized under a signed CLA. |
| (e.g. the use of PIZ compression in exr2aces is technically off-spec), | ||
| but the file generated here is generally suitable for broadly | ||
| compatible archival. | ||
|
|
There was a problem hiding this comment.
I don't think the OpenEXR documentation should attempt to be the authority on what off-spec features are acceptable in ACES files. I believe that support for compression is the only way that the exr2aces output doesn't meet the strict definition of SMPTE ST 2065-4, so perhaps it would be better to be explicit about that. Then the user can make an informed decision about how to use the tool. Essentially exr2aces requires reading software to support the OpenEXR compression types which are not described in the ST 2065-4 standard.
Perhaps there should be a --strict flag that forces NO_COMPRESSION, to make it easier to guarantee compatibility.
All this does assume the user wants to generate a SMPTE ST 2065-4 ACES container file, not just an OpenEXR encoded with the ACES Chromaticities, which is the more usual approach and doesn't require use of exr2aces.
There was a problem hiding this comment.
Sure, is there specific language you had in mind that you feel would be more faithful to your comments?
I don't think the OpenEXR documentation should attempt to be the authority on what off-spec features are acceptable in ACES files.
I agree, and that's not my intent. My goal with this edit is to at least make it the authority on the behavior and rationale for its own tool's behavior (especially when deviating from any formally documented specification it may otherwise be confused with).
There was a problem hiding this comment.
I wasn't involved with the creating the ACES standard. It would be helpful for somebody with more experience of that effort could suggest a solution to this.
I notice that the original version of exr2aces was committed in 2007 (4568596) many years before the ACES standards became official. That may explain the discrepancies between exr2aces and the final published standard.
There was a problem hiding this comment.
I still think some incremental improvement here would be valuable. Would you be more comfortable if this line were replaced by some caveat that this implementation predates the specification and may not have perfect alignment, citing compression as an example?
Inspired by discussion in #1962. (many thanks to @peterhillman and @lgritz)
Adds additional background to the ACES Image Container format produced by exr2aces.