Cross-referencing footage with ACESclip, CTL, etc'

Discussions - ACESNext
1

Hello. This discussion was on another thread about Archiving and future-proofing, but I decided to split it because I hope that things discussed here may have a broader scope, as they embrace:

  • use of ACESclip and other ACES components (LUTs, LMT, CLF/CTL files, etc.) in production environments;
  • improvement of the ACES workflow, for fostering better automation and integration of the above components.

First of all, TB-2014-009 mentions that the metadata link between some footage (either a frame-based file-sequence, or an individual video-clip file) and its ACESclip is carried by the <aces:ClipID> element (which contains 0-1 <ClipName>, 0-1 <Source_MediaID> and 0-1 <ClipDate> elements). More than one ClipID element can be present, especially if the footage can be referenced by several logical labeling schemes at the same time (e.g. either filename, tape-name, file UUID and timestamp).
It’s important to stress that different clips should always be referenced by different ACESclip XML files, even if the metadata contained therein (apart from the ClipIDs) are the same).

For many reasons (including vendor-neutrality), no naming conventions are even suggested in the AMPAS documentation for the sub-element types ClipName and Source_MediaID. I feel that ACESclip effficacy is significantly hindered because of this: Vendors can (and will) implement it differently so that interoperability may be compromised. Therefore I am drafting here a “supplemental” use case.

As per TB-2014-009, §3:

  • ClipName is attached to clip (or segment of a clip): often used in conform-files (EDL, ALE, Premiere/FCP XML, Avid bins, 
) to describe the version of images used within the edited sequence.
  • Source_MediaID is the general term for identifying the source-name of clips (or frame-per-file sequences) at their creation’s time (often referenced in EDLs as well). This can also be called “Tape Name” (CMX EDLs) and “ReelName”; an example of it is A004B003, which locates the footage as clip the clip “B003”, stored in the 4th magazine, shot by camera ‘A’.

As per §5.1:

  • The link between a clip (single video file or frame-per-file sequence) and its ACESclip is loosely based on similarities between the two filesystem objects’ filenames. This will be clarified here (below).

In addition to that:

  • The link between ACESclip and the color transformations is carried over by directly describing them in the ACESclip (e.g. “inline CDL” as shown in §A of the above document), referencing them in a separate CLF (CommonLUT) file, or by the TransformID of either the ACES transform; transforms can also be indirectly referenced by storing them in a separate section of an ACESclip XML file (within the <aces:TransformLibrary> element), indexed by ProcessList id, and cross-referencing them from the color-pedigree part of the ACESclip (<aces:Config> element) by means of the above ids.
  • Color transformations in CTL language can and ‒for as much as possible for Academy-provided CTLs‒ should be validated by means of their TransformID tag (more on that later).

Most professional image/video file formats have a UUID or UUID-like metadata field that uniquely identifies the asset. Some formats also contain specific metadata field to address logical labelling like tape/reel/clip names. In order to create an interoperable representation of footage-ACESclip association, particularly for those footage that is not (yet) entered ACES color-managed pipeline (e.g. raw files straight from the cameras), I would like to suggest a unique association between the two metadata above, for each non-ACES production file formats, and the ClipName/Source_MediaID elements of the corresponding ClipID element in the referencing ACESclip.

My proposal is therefore:

  • MXF ― ClipName = UUID; Source_MediaID = UMID (of the underlying video essence, not of the MXF container).
  • ARRIRAW ― ClipName = 8-chars ‘Reel ID’; Source_MediaID = ‘UUID’ or ‘SMPTE UMID’ (both from Camera Device Information header).
  • R3DCODE ― ClipName = 8-chars ‘Reel ID’; Source_MediaID = ‘Reel ID Full’.
  • OpenEXR ― both ClipName and Source_MediaID reference custom, same-name metadata (of string type) in the EXR header; Source_MediaID is a UUID or UMID.
  • DPX ― ClipName = tape/clip name from DPX header; Source_MediaID = film reel’s first-frame KeyKode (if present, and laid out as string, e.g. “KN728-0000-0000”), otherwise unused.

As regards the naming convention to link an ACESclip XML file to its asset, the above cross-referral scheme, ignoring filename similarities and using file-header metadata referenced as ClipIDs, is a stronger link because it’s more persistent in case the footage is:

  • separated from its ACESclip sidecar at filesystem level (e.g XML files are ignored or archived on other media/paths, while “ingestion” applications only take care of specific image file formats);
  • bulk-renamed as part of an automated software, scripts, and/or rendering pipeline;
  • converted to a different file format (which may include filename/extension changes as well), e.g. camera-originals or film-scans becoming graded, composited plates or finished footage;
  • processed along the timeline, possibly blending/compositing frames from several sources (with different creative and technical color decisions).

This scheme is valid for either ACES-color-managed footage (e.g. encoded as ST2065-4 OpenEXRs or ST2065-5 MXFs), and for generic footage in production file-formats, like camera-native (“raw”) or film scans.

However, in order to encourage ACES Product Partners towards an interoperable naming convention for reading/writing ACESclip sidecar files, I would suggest for all vendors and in-house tools to use the following rules.
First of all ACESclip sidecar file should be created and ‒at least as first try‒ searched for in the same directory path where the associated clip is stored. Its file extension is always .ACESclip.xml. Then:

  • For file-per-frame formats, they are usually {basename_12345.ext, basename_12346.ext, 
, basename_98765.ext}, where _ is an optional, non-alphanumeric separator-character between the basename and the frame-number of the file-sequence (5 digits in this example).
    In this case, the ACESclip name shall be basename.ACESclip.xml (ignoring separator _, if any).
  • For single-file video clips, whose name is generically FileName.EXT, the associated ACESclip name shall be FileName.ACESclip.xml.
  • Additional naming conventions restrictions may apply; they will be enforced before creating ACESclip sidecar file, and shall not be part of the ACESclip filename’s generation algorithm. Examples of such conventions may be, for example, restricting the use of characters outsize A-Za-z0-9.-_ ASCII characters and prohibiting starting and ending symbols.
1 Like
2

I will now concentrate on a second additional feature request for CTL. (the first one was adding TransformID).
As the CTL specifications seem to be “frozen” for some reason, it’s not possible to add official elements to it, therefore the previous one mentioned above was added as a pre-formatted comment line at the beginning of .ctl files.
The comment-line reports XML syntax within, despite CTL grammar is more like that of C language. Therefore for now, I will attain to this syntax.

I think it might be very beneficial to the adoption of Academy-provided (“original”) CTLs, if there is a mechanism to validate them apart from checking their TransformID or CTL filename against ACES naming convention, as specified in S-2014-002. This way, at least for ACES Product Partners that internally implement those transforms, this is an additional tool to easily check whether the CTL is the original one and does not need to provide LUTs representing them.

I suggest adding a <aces:TransformDigest> XML element, enclosed within a C+±style comment-line for now, following <ACEStransformID> element and containing the canonical string representation of a SHA-1 digest (lowercase hexadecimal characters). The digest is computed following this algorithm.

  • The CTL is added the following, fixed, commented-line (as either first non-empty line or as the line immediately following the TransformID commented-line):
    // <aces:TransformHash>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</aces:TransformHash>
    (there’s a 40-times repetition of X character and a whitespace 0x20 character between the comment tag '//'and opening XML tag).
  • The SHA-1 of the CTL file (with the above line added) is computed now, and its lower-case, 40-characters representation replaces the content of the TransformHash element; for example:
    // <aces:TransformHash>e5f08d98bf18385e2f26b904cad23c734d530ffb</aces:TransformHash>

The validation procedure consists in searching for a TransformHash element, replacing the 40-character digest with a 40-character string of X's and then computng the SHA-1 on such altered message.

It’s important to note that, among Academy-provided CTLs, there are also the IDTs and ODTs provided by camera as well as by monitor manufacturers in the Logo program. The above digests can be used, on larger color-management applications with ten-thousands of color recorded transformations, as a possible database index to them.

At a later stage, when the CTL format will likely be updated, I think it makes sens to have it a uniform C-style syntax, therefore I think TransformID and TransformHash metadata can be provided, off-comments, at the beginning of CTL files, like:

TransformID "InvODT.Academy.P3DCI_48nits.a1.0.1";
TransformHash "e5f08d98bf18385e2f26b904cad23c734d530ffb";

1 Like
3

I just wanted to discuss this sub-point for a second. CTL is open source (GitHub - ampas/CTL: The Color Transformation Language (CTL)) and like other projects, the specification could be improved with new pull requests. That being said, it is somewhat of an ‘orphan’ as the original developers (Florian et. al.) have moved on. It largely achieves its purpose for prototyping color transforms and has been very helpful in the development of ACES. But there is also a functional wall that we should maintain between the functions of the CTL interpreter in general and specific requirements for ACES usage of CTL which is more of a recommended practice. (as are the proposed naming conventions for ACESClip)

I read the suggestions above as being about a practical issue in release, and agree that if people were
changing the CTL sources before use that there might be an issue in divergence of the ACES current release and the vendors ‘version’ of the same CTL. However, I am not aware of this happening. Please fill in any details if this is happening.

4

Hi Jim, I completely agree with you that an upgrade of the CTL source code, if ever, must be tackled with proper cautions not to break any backwards compatibility.

For this reason the TransformID part in the current ACES recommendation for CTL is an XML syntax enclosed within a “C+±style” commented line that the current CTL interpreter ignores completely:

// <TransformID>name_of_the_original_CTL</TransformID>

Effectively, the proposed hash-validation feature within CTL spec doesn’t refer to anything ACES in particular, as it may be used for validation of any CTLs. Therefore better to remove the aces: XML namespace from the TransformHash tag (and the functional wall you were correctly referring to would be preserved).

I propose to temporarily adopt the hashing keepin it within a commented line – at least until CTL code is reviewed, therefore:

// <TransformHash>.....SHA-1-digest...</TransformHash>

5

Under the lights of the Academy Digital Source Master spec S-2008-1 being drafted I believe having a UUID referencing within CTL maybe beneficial especially for those ADSM that employ one or more (optional) LMT indications. These LMTs may very well be of either a creative nature, or a technical nature at a point which current Academy-provided LMTs do not provide for.

  • In case of a technical LMT that is not yet released, there woule be potential uses with the capability to either link back back from the ADSM to a LUT (by using a UUID), or including the LMT itself in the IMP (and checking its integrity with an original LUT or CTL via a hash).
  • In case of a creative LMT that may be more or less show-specific, this LMT will not exist, a priori, in any particular ACES relrease. This is not really expected out of an ADSM (LMTs in ADSM are expected to carry out other reference purposes), but the need may happen – especially for ADSMs to be used internally.

Under such consideration I’d propose to introduce some sort of MIC (hash) into UUIDs used in CTL, as referencing them by just the naming-convention in the TransformID and the .ctl filename may easily be broken – especially in the context of LMTs that may be due to one or several of below specs:

  • specific to a show
  • linked to a particular viewing pipeline
  • used by technologies that are still under NDA
  • the customised LMT needs to be transported on a separate (confidential?) channal than the IMP’s

There is already an indication on LMT UUID, called LMTid, in the ADSM specification draft, and referenced in the <adsm:LMTId> element within the SCM file of an IMP. I’d rather go with an integrity message (MIC) like a hash, for the reasons explained above.

6

I’d rather go with an integrity message (MIC) like a hash

Hi Walter,

How would you compute said hash? It is quite easy to create two LMT files that have the exact same effect but produce a different hash.

Cheers,

Thomas

7

Has anybody developed any kind of image processing hash, that is based not on the code that creates the transform, but rather on the result of the actual transform? Clearly it would need to use some kind of tolerance threshold, as two different implementations of the same transform cannot be guaranteed to produce a bit identical result.

1 Like
8

Hi Thomas and Nick.
The purpose of the proposed hash used as UID for a CTL is not really check the integrity of a color transformation when it is in the form of a LUT, but rather make sure that references to a certain ACES transfrorm (be it either functionally a Input Transform, a Output Transform or a LMT), as long as there is a CTL or a CLF representing that transform, can be integrity-checked by comparing the hash vs the original CTL or CLF. This holds for Academy-provided transforms as well as for custom transforms: if you have a hash you can retrieve the original file referenced by it and validate the hash – even if the object referencing it is not (or no longer) in the form of CTL or CLF.

In case of Academy-provided CTLs you can just check the UID/hash vs the official repository of the specified ACES version.
In case of a non-standard CTL/CLF, you have to retrieve the CTL/CLF file itself but, when you do, you can still check that what is referenced matches with the original CTL/CLF’s original hash.

Otherwise it would be easy to take the wrong CTL (unwillingly) replacing with one that “just has a similar name” or (purposedly) in case of non-hash UIDs are used, by pasting a given UID on a different CTL.