Academy Digital Source Master Draft Specification

Discussions - ACESNext
,
1

ACES Community,

Attached is the public draft of the Academy Digital Source Master Specification. This specification is built upon the recently published SMPTE IMF Application #5 spec (ST 2067-50:2018) to establish a package that will serve as an archival, future-proof digital source master for motion picture mastering. This work was based on industry requirements of all the major studios who are the proponents for the spec. We look forward to additional review and comments by the ACES community.

ACES Leadership

S-2018-001.pdf (134.1 KB)

2 Likes
2

Hi Alex,

Thanks for sharing.
Is the strong presence of the LMT a way of producing compliant ACES DSMs even if an alternative Display Rendering was used during grading(assuming that the ACES Output Transform will be one day analytically invertible).
Also is the LMT only LUT based? There is very strong evidence that a per pixel process is not enough to transform between new emerging display technologies?

Thanks
Daniele

2 Likes
3

Hi Alex.
Thanks for sharing: the ADSM is a much needed feature. I have a few proposals for it - and one question ― since S-2008-1 extends Standard ST2067-50 IMF Application #5: ACES, do you think there will be a possibility to update this SMPTE Standard in the future so to include definition of ADSM and the clarification on it?

Would it make sense if, with ACESNext, comes an update of the whole SMPTE Standards family ST2065 and from there kept current with Academy standards on ACES?
I ask because when IMF App#5 standard was drafted there was no room for including many things that are now a reality and getting shape with this much needed extension.

4

And now on with my proposals (one post for each).

FIRST

In the thread Output Transform Naming from last May, I had proposed to homogenize the naming convention of Output Transforms, (as well as other Academy-provided color transforms) and to label each with a UID. It seems that these ideas are now getting momentum. For LMTs, there’s now the definition of a “LMTid” referenced in the IMP with the <adsm:LMTId>.

Good― but this is still incomplete to me: why not adding UIDs for the associated Output Transforms as well?
On a generic side, I proposed to add UIDs in every CTL or CLF that defines a color transform (at least in the official Academy-provided ones) in the form of a hash, via a TransformHash keyword.

As pertains the ADSM here, my suggestion is to have this referencing feature more “consistent” among the LMT and the Output Transform and, above all, with the whole ST2067-50 standard.

In App#5: ACES §8.2.4, in fact, zero or more “ACES workflows” may be defined by describing a reference/mastering device (i.e. functionally, an output transform) via the <ACESPictureSubDescriptor> element in the CPL file. It seems that may reference using Output Transforms only (by their TransformID, plus additional color-metadata, which may, alone, be potentially insufficient or inconsidted with the ODT).

Instead, in the ADSM draft above (§5.4), my understanding is that output profiles are defined in the SCM file (rather than in the CPL); each “workflow” is associated to an LMT (referenced via a UUID) and an OutputTransform (referenced by Academy name, i.e. the TransformID).

To sum it up, I believe both optional features solve the same purpose (i.e. providing a complete, stable description of possibly-multiple viewing/mastering environments for the IMP) but propose two radically different implementations. This is due to the two proposals coming at different times.
I have a few ideas on how to homogenize them, but I feel keeping both (the feature in ST2067-50 §8.2.4, and the one in S-2008-001 §5.4) is redundant, inelegant and even possibly ambiguous: what if both features are present in an IMP but refer to different declinations of the same output-referred profile?

Please let me know if some one else also feels this should be adjusted.

5

SECOND

If LMTs are allowed in an ADSM, there are color transforms that may be potentially described externally and need to be referenced in the IMP. In my opinion, it would be beneficial if the used color transform(s) can optionally be included in the IMP as whole assets (either as an optional or a mandatory feature).
Such transforms may be stored in either CTL (application/ctl MediaType) or CLF (application/xml MediaType) file formats*, as much as Target Frames are as individual PNG/TIFF files within a IMP.

In such a case the color transforms are referenced directly, within the SCM file, as IMF assets rather than, loosely, by LMTId or TransformID (cfr. post above).

  • In such a case, no need for an additional TransformHash UUID, as the color transforms’ integrity becomes part of the IMF itself (via the ASSETMAP.xml file).
6

Hi Walter,
Per ST 2067-50, the Output Transform metadata can be carried in the <ACESAuthoringInformation> item of the ACESPictureSubDescriptor, which in turn is contained in the RGBA Picture Essence Descriptor of a 2065-5 ACES MXF file.
The <ACESAuthoringInformation> item is defined in ST 2067-50, and is being constrained in the new ADSM spec in the sense that the <ACESAuthoringInformation> field becomes mandatory for an ADSM package (whereas it is optional in ST 2067-50) and shall carry an Academy ODT Transform ID.
So no change here, just a constraint in the ADSM spec vs. ST 2067-50.
(Remark: The XML-formatted Essence Descriptor of a MXF Track File is replicated in CPLs that reference that particular Track File. So the ODT is not actually defined in the CPL, but in the MXF file.)

The option to add an LMT file (no obligation to add an LMT!) associated with a particular Output Transform reference is indeed new in the ADSM specification. The aforementioned <LMTId> is a Type 5 UUID calculated over the contents of the LMT file. This <LMTId> is used as reference within an ADSM package only, and to my understanding currently not intended for external referencing of an LMT.

7

Hi Wolfgang.
Thanks for your clarifications. I know about what is in the MXF file. My point is that, to make it really really short:

  • the OutputTransform is specified within CPL in the <ACESAuthoringInformation> element as a TransformID (optional in ST2067-50, mandatory in S-2008-001).
  • the LMT is specified within the SCP in the <LMTid> element as a UUID (optional in S-2008-001), but the latter may also reference an Output Transform that goes with the LMT. The latter ODT is referenced as a TransformID.

So in my opinion the possibility for two differnet positions where an Output Transofmr can be specified can create ambiguities. Also, the fact that the TransformID is not a “hard” link makes me again point towards UUID/hashes to reference colour transform.

As a side note, I’d like the possibility to include color transforms themselves (e.g. LMTs or Output Transforms) within the ADSM. Maybe it’s possible to embed them as CLF (XML), directly in the contnents of the SCM.

1 Like
9

I would lean towards agreement with Walter on the issue of hashing the color transform information - there is always a margin for error during data transfer, and given the long-term preservation potential of the assets, it would seem that a way of verifying the integrity of the data (potentially decades in the future) would be useful - especially if the color transform is integral to the initial creative intent of the master.

edit:

To clarify the above - implementations would also flag any modifications to the color transform information, and UUID/hashes would also clearly deliminate the use of an non-standard or ‘homebrew’ output transforms vs those with an Academy ODT Transform ID

10

Thanks Peter.
As already mentioned, the Output Transform and/or the LMT may be even completely embedded into the SCM (Sidecar Compostion Map) XML, especially for those cases where they can be handled like a color-transformation already described in CommonLUT format, which is also XML.

This would easily bring in any LMT and/or Output Transform that can be accurately described as [potential combination of] 1D/3D LUT(s), RGB matrices, power/gamma curve(s), etc.
The full CommonLUT’s XML namespace can be embedded into the SCM. This would help in future-proffing, portability, interoperability (only systems acknowledging the CommonLUT namespace would honour it) and integrity.
In the latter case, as the LUTs are completely emebedded into the SCM component of the IMP, there’s not even need for hashin/UUID, or externally referencing the color transform.

14

Regarding Appendix B., workflow B2.

This might be a stretch but instead of having only a fixed LMT associated with an ODT, is there plan or reflexions around some kind of dynamic “LMT” track ? Eg. in case of an ADSM graded for Cinema exhibition, we want to derivate a home television BT.709 file, a single LMT for the whole show might (and probably) will not be enough ?