I would love to help with that. This can be done for the compression algorithms that are currently published as standards, but this would practically help only if they match with the algorithms that the VFX/post community is using when dealing with production EXR shots.
Andy, we had the same problem when drafting ST2067-50 (IMF Application #5: ACES). Since there doesn’t seem to be a complete (and standardized) registry of (output-referred) color spaces, color gamuts, color encodings, it was not possible to refer to mastering color-spaces in the IMF packages by just mentioning them as metadata in the XML, so an ACES Output Transform’s CTL name (TransformID) is all that could be used in the Standard document.
There is some SMPTE UL used for a very narrow set of color-spaces to be used in certain MXF specs, but this is largely insufficient compared to today’s increasing color-jungle, These ULs should be constantly expanding along with mastering colorimetry – which inflates today at a faster rate than standardization can keep up with.
I think it would also be beneficial, as I said many times in past occasions, that the Academy puts up a public registry about ACES names/values, TransformIDs for ACES core components, and that is standardized somehow so that it can be referenced by other documents (like SMPTE families ST2065 and ST2067). Things to put up in the gesitry would ideally be:
- ACES color-gamut ULs (AP0 and AP1)
- ACES color space ULs (ACES2065-1, ACEScg, ACEScc, ACEScct, ACESproxy10, ACESproxy12, APD, ADX)
- ACES version name strings / ULs (as per AMPAS Standard
- hashing system for Academy-official CTLs so that it is possible to retreive and validate a CTL in automatic, persistent way (the
.ctl files may just be linked, in this registry, back from the GitHub CTL repository).
As regards CTL hashes and other UUID proposals I will come up in a different topic.