Proposed AMF spec update to support linking custom transforms

It has been brought up in multiple AMF implementation meetings that in order to support linking to non-ACES transforms, which is common for unpublished IDTs and user-generated looks as LMTs, the current spec of only using <transformID> is insufficient.

ACES Transform ID’s (<transformID>) are important for core ACES transforms and version control, but for anything outside of that it seems to be unclear how this ID is intended to be used.

For example, if a transform is generated and assigned a custom transform ID (example: IDT.Acme.NewCameraX.a1.v2 or LMT.ShownameX.bleachbypass.a1.v2) how will another product know what that means and where to find it? Would it just be the filename of the transform (with or without file extension)?

Examples from implementers have been that in these scenarios, it might be easiest to use filename - since most software has a folder where all the LUTs live - and maybe more robust to use a filename + UUID.

The following proposal would be a small addition to the current spec released with ACES v1.2.

The following would be added under <inputTransform> and <lookTransform>.

<inputTransform>

  • <file> - this can be duplicated from <clipID>
  • <uuid> - this can be duplicated from where UUID already exists

<lookTransform>

  • <file> - this can be duplicated from <clipID>
  • <uuid> already exists here

While we are updating the spec, should <transformID> be changed to <ACEStransformID> in order to be in line with the CLF element? This would also make it clear that this refers to the ACES Transform ID as specified in S-2014-002 and not some other generic ID.

Here is how this might look with a CLF as the external transform (thank you @Giardiello and @walter.arrighetti for helping with this proposal):

How does everyone feel about this? We think it would be a useful addition to the AMF spec which should help implementation and for people to use custom transforms.

Thanks,
Chris

Hi Chris,

About your last proposal for the name of the TransformID tag, I agree in principle, but an ACES’ XML namespace is in place in AMF, therefore the real tag is already <aces:transformID>.

Instead than modifying this in AMF, I suggest to allow ACES XML namespace in CLF (at least optionally), which harmonizes CLF and AMF name tags, currently existing with different names for similar or identical purposes (like the acesTransformId / TransformID discrepancy that you correctly spotted).

Hi Chris,
regarding the core proposal of the thread now.

I’d like to add that the same method for linking external transforms in IDT and LMTalso holds for ODT, therefore the proposal that we designed is extensible, as is, to ODT.

I think it is useful to extend to the group at large the presentation deck
Advanced workflows interoperating AMF, CLF and CDL
, by myself and @Giardiello.

It has are some workflow diagrams and, above all, code examples showing the details of all alternatives for linking AMF with CLF and CDL, line by line.

In fact, with the same strategy, we get for free the automatic linking of external CDL from the LMT, thus opening up other “advanced workflows” that we designed exploiting AMF’s current spec (with only minor addition proposal).

The advanced workdlows are shown in the same slides’ deck above.