ACESclip implementation proposal

[walter.arrighetti]

What folllows is my ACESclip implementation proposal. The implementation has an “ACESclip Core” with minimum mandatory syntax, and a few optional components (like history) to suit more compicated workflows. It was propsoed to the ACESclip Requriements VWG back in March 2019. It comes with:

• G-Drive link to slides deck showing XML sample codes in a visual and user-friendly way (hope it’s self-explanatory enough). It also covers IMF and ISXD. (710.9 KB)

• S-2019-009__ACESclip_W.Arrighetti_v1.pdf - a PDF document with a “word” description of the implementation

• ACESclip Core sample XML file (sample_00.ACESclip.xml)

• Nine ACESclip samples with additional features, mimicking a production workflow toy-model. They follow the 9 examples in the slides’ deck:
  sample_01.ACESclip.xml (on-set grade)
  sample_02.ACESclip.xml (camera-magazine backup)
  sample_03.ACESclip.xml (near-set/pre-DI rough grade)
  sample_04.ACESclip.xml (rushes editorial)
  sample_05.ACESclip.xml (VFX plates)
  sample_06.ACESclip.xml (color-grading/finishing)
  sample_07.ACESclip.xml (IMF App.#5 for archival)
  sample_08.ACESclip.xml (IMF App.#4 for D-Cinema distrib.)
  sample_09.ACESclip.xml (multiple color-pipline HDR master)

As you can see there are lots of features implemented, like:

• referencing footage directly on a filesystem (via one or multiple single-file name, file-sequence names, IMF <Id>, TimeCode, other format-specific file-header meatadata, etc.), or
• footage-less, “manifest ACESclip” for pre-batched color pipelines (like on set)
• referring external color-transforms by either filename, signature/hash/digest, or UUID
• history to keep track of past image states for forensics/security/color science
• referencing external LUT (many file formats), CDLs or ever CTL files
• supporting multiple color pipelines in an ACESclip
• support reframing metadata

Please pay particular attention, browsing the 9 example XMLs, on how the optional history feature is carried along from one version to the next, keeping a long trail of “past” image states, thus allowing to rebuild the color-pedigree of the whole clip. Of course the above example is ideal and doesn’t have any pretention to be followed step by step during a real production workflow.

[walter.arrighetti]

An additional feature in complex AMFs (ex ACESclip’s) is implementing an optional, smarter way of re-using transforms that may be overly present within the same AMF.

My proposal is, again, mutuated from W3C’s XML Signature standard (XAdES), introducing a top-level, optional <Transforms> element that contains single elements, each with their own UUID, that may be reference elsewhere within the same AMF as placeholder for the same transform.

For example, AMFs containing multiple pipelines re-using the same ODT, LMT or referencing the same external LUT file – or an AMF with a long history where the same clip is processed with multiply recurring Input/Outut Transforms and LMTs, it may be beneficial to define the transforms once only in the AMF payload (within the <Transforms> element), and referencing them. via a UUID, with the element