ACES Metadata Spec Draft

Tags: #<Tag:0x00007f0e6e2e0f80>

Hi Patrick,

You raise a good point! Please also see this thread, which is related to the GitHub commit you cited:

My understanding of the current spec is that it does allow your use-case (in your example, applying 3DLUT in WCS Y). But the proposal in that thread is to remove the ability to apply transforms other than a CDL in a working color space (other than ACES2065-1). This is why I wrote in that thread that I was worried that it would remove the ability of AMF to easily support certain use-cases.

The reason that I was not entirely opposed to the proposal is that CLF does support packaging more typical log-space based LUTs into a container that expects and produces ACES2065-1. So that would be one work-around that would allow implementation of the use-case you describe, even with the latest proposed change.

In other words, the working space conversion gets moved from within the AMF implementation into a step of packaging the original LUT from the production into an appropriate ACES2065-1 based LMT as a CLF. We could potentially add something to OCIO to provide that service, if people would find it useful (e.g. using any of the existing ACES CSC transforms and any of the 20+ LUT formats supported by OCIO).

This is an extra step, but as Chris wrote in the proposal, the benefit is that there is no uncertainty about what color space an LMT expects as input and output – it is always ACES2065-1, and thus follows the existing LMT spec from ACES 1.0.


@ptr @doug_walker @CClark

I think Doug hits the nail on the head here. For a LUT that currently assumes ACEScct (or any other working space) in, there’d need to be a repackaging step that makes the LUT compatible with ACES 2065-1 in/out.

1 Like

Thanks for clarifying that (sorry that I had not seen that other thread yet).

So to put it differently, the latest proposal of AMF (with the limit of WCS definitions to ASC-CDL) purposely cuts out use cases that use custom 3D-LUTs as look transforms – and relies on the implementation of CLF as a replacement for such 3D LUTs.

I have to admit this is a clean solution, but I agree with Doug Walker that this will have an impact on adoption. While “80%” of use cases (with ASC-CDL only in WCS) might be covered well with AMF then, the “20%” of special cases – where a custom transform is required – cannot be covered with AMF by systems not supporting CLF yet. So the availability of CLF support now becomes a prerequisite for AMF support in systems that want to cover common use cases with AMF comprehensively.

If this becomes the version for ACES 1.2 now, I think these constraints should be clearly communicated as part of the AMF documentation in order to make the requirements clear for implementers.

For instance the ambiguous word “LUT” or vague references to an “external look file” then should be entirely replaced by something like “CLF-based look transform”.

Example (in S_2019_00x_AMF_DRAFT from 2019.12.19):


AMFs may also embed creative look adjustments as one or more LMTs (using the <lookTransform> elements). These looks may be in the form of ASC CDL values, or a reference to an external look file or LUT.


AMFs may also embed creative look adjustments as one or more LMTs (using the <lookTransform> elements). These looks may be in the form of ASC CDL values, or a reference to a CLF-based look transform.


I think our intention is to keep the AMF somewhat implementation neutral. It lays out what the processing steps are to get from camera images or ACES images to a screen. The implementation may or may not decide to use LUTs (CLF or others), GPU code, CTL, or others. They may have specific issues that they need to tackle or may choose the concatenate steps. LMTs being the exception I guess …

Currently TB-2014-010 says they are CLF so I guess existing show LUTs would need to be “rewrapped” as ACES to ACES CLFs. This may be something to revisit in ACES 2.0.

I’ll try rewording but “external look file” may be a CLF or something like an EDL with embedded ASC-CDL values.

I just read the example AMF from the lates draft and I have three points I’d like to discuss – either today or at another date.

One of the CDLs referenced in the AMF sample (approx. line #114) employs the ColorCorrectionRef element:
<cdl:ColorCorrectionRef ref="03345"/>
Actually that is to be used when there is an actual collection of color corrections (in a file with .ccc extension), so that each EDL or ALE file may just reference the name of a specific CDL within those listed in the CCC, without retyping the numeric parameters each time.
Using such CDL feature in AMF means that the AMF is referencing something not within the AMF itself and --ever worse than this-- it is a reference to something that AMF provides no actual mechanism to unambiguously refer to: where could this reference #03345 be ever found externally?
It makes sense to explicitly say in the AMF specs that only individual CDLs may be referenced within AMF.
Or, alternatively, CCC may be allowrd as well in AMF (I suggest under the generic LookTransforms element), so that internal cross-referencing happens, independently in the IDT, LMT, RRT and ODT parts of it.

The XML namespacing in the example (a generic xmlns attribute in the root element and no namespace specification in any of the descendant XML elements ) is good as long as AMF is not to be embedded inside something else.
An even better implementation would be to use a namespace tag (actually any namespace tag), like for example amf, specified in a named xmlns:amf attribute in the root element, and use it consistently in any descendant elements. I would recommend that AMF parsers are capable of at least this latter forms – even if most implementations would use the simpler one. I am attaching the two variations here:

The latter sample is good in case AMF is to be embedded into larger XML files. Using the former sample requires the embedding application to create a namespace and convert the former into the latter before embedding – which embedding application may not be able to do.
This may seema a neglectible problem now, but if you think about it many existing applications already use XML-based project files: Foundry Nuke, Autodesk Flame, FilmLight Baselight, R&S Clipster, Colorfront, Apple FinalCut ProX, etc. They may ultimately benefit from having the opportunity to streamline the embedding of AMF into their products.
This would eventually facilitate adoption of AMF by manufacturers of software that is already XML-based based.

As agreed during one of the recent VWG calls, I am attaching a few variations of the sample AMF, with a few stressing of XML syntax in a ZIP file.
The files are all valid XML files, therefore the any application honoring AMF should be capable of parsing all of them. If not, the parsers may not be complete.
I would strongly suggest adding some soft of reference AMFs so that manufacturers can stress their AMF parsing capability.
Those who are long time in the business know that just saying XML is not good… somethimes XML files from “obscure” implementations need to be post-processed by whitespce / end-of-line / syntax-check tools before they become totally interoperable among different implementations that use incomplete writers to generate data files, and/or incomplete parsers to read them.

In the end:

  • applications writing AMFs should write files in a clean (possibly canonical) XML style;
  • applications reading AMFs must read any file with an XML-vaid syntax

@walter.arrighetti can you provide the link to the file?

@walter.arrighetti I think you’re working off of old files. This is has been reflected in the sample files since November 25, 2019. The examples in the RC1 version of the specification., the aces-dev repo at RC1, and the [latest sample files post-RC1 feedback latest sample files continue to include the explicit name spacing.

I completely agree but I think this an issue for the implementation group to deal with rather than including the spec. I could add a details about required line endings to the spec if people want.

Hi Alex. The file is S_2019_00x_AMF_DRAFT_2019.11.19.amf.xml this one.
It is taken from the 2019.11.19 spec draft sample

But I can see now it was from an old spec: I don’t think the CDL ref exists any longer in the four samples in the GitHub repo.

Thanks Walter,

The latest complete draft spec is posted at the top of this thread. There’s also a link to the working copy on overleaf that is a work in progress but incorporates changes such those to the LMT working spaces that we’ve been discussing.

I think your point about the cdl:ColorCorrectionRef may be valid even though it isn’t in the latest examples. The type for the cdl:ColorCorrectionRef attribute ref is AnyURI. Would it be useful to specify the pattern for the ref URI?

Hi Alex.
The ColorCorrectionRef element should be either avoided in CDLs used inside AMF, or it should be defined how to reference external CDLs (the same way AMF may reference an external LUT, or an external piece of footave gia clipID)… which I’d rather avoid.

In my opinion, CDLs inside AMF should be fully described as Slope/Offeset/Power/Staturation 10-tuples. But if ColorCorrectionRef is to be allowed as well, then the specs shouls clearly state how to reference.

Possible, alternative solutions are:

  1. ref is allowed to be a UUID which is an identifier pointing to another part of the AMF, where that CDL’s slope/offset/power/saturation values are defined. This pars with my earlier (2019) proposal for hosting a repository of transforms inside and AMF file, which the transforms used in the IDT, LMT, RRT, ODT parts of the AMF file all refer to.

  2. ref is allowed to be a UUID to CDL embedded somewhere else by means of default XML extensibility features. For example, it points to the id attribute of an XML element containing both a SOPNode and a SatNode.

  3. ref is allowed to be a filename or an online resource (in this case a AnyURI may stay). In that case AMF may reference external CDLs (like it does with referring to external LUTs or external footage via clipID). In which case, however, it should be stated clearly that applications “validating” AMFs should check whether the externally-referenced CDLs are available as well.

Choice #1 is also good in the case of AMFs with looong pipeline histories. where most of the pipelines in the history share many color transforms: having one “vault” with all the used the transforms helps keeping the size of the AMF file small.


The AMF currently supports CDLs specified inside the AMF itself using <cdl:SOPNode> and <cdl:SATNode> or <cdl:ColorCorrectionRef> as a means to reference a CDL in an external file. See details in the schema.

Hi Alex.
I gues I am being misunderstood here.
I know that SOPNode and SatNode are supported in AMF.

However, ColorCorrectionRef referenes a CDL specified somewhere else.
In ASC CDL, this usually means a CDL specified in another .cdl, or .ccc file.

So my concern here is: how is ColorCorrectionRef referencing mechanism implemented in AMF? (IF it needs be implemented rather than disallowed?)

In that case the either:

  • ColorCorrectionRef still references an external file (so AMF needs a double reference: one to the external CCC file itself, and one to the particular CDL inside that CCC file – only the latter mapping to the ref attribute)
  • ColorCorrectionRef references a SOP/Sat specified CDL embedded within the same AMF file.

Either way, we need to write in the specs how this works, otherwise we risk of having AMFs referencing externally-defined CDLs that aren’t just there.

I agree … this needs to be specified, but given the type is AnyURI is there a way to specify both the external file and the CDL inside that file within a single ref attribute?

I don’t see why one would do this? The schema allows for either SOP/SAT nodes or a ColorCorrectionRef. The intention in AMF is that ColorCorrectionRef be used to reference external CDLs, no CDLs within the AMF. Is this a problem?

Hi Alex.
As Josh and I remarked during last VWG call, having AMF referring other components outside the AMF file itself, by using filenames (and even worse – absolute or even relative pathnames) exposes AMF to severe interoperability issues.

What happens if one application --or human-- moves/copies/transfers either the AMF and/or the referenced LUTs/CDLs without changing the pathnames in the AMF as well?
That would breadk the AMF purpose and break the workflow completely.

As Josh said: we don’t need to solve filesystem consistency issues among the files: applications are there to solve this issue. For make every app happy. the AMF must be either self-consistend (e.g. embed all CDLs and LUT it needs) OR it must refernece external files (LUTs, CDLs, etc.) in a smarted way that is not broken by filesystem operations.

That is why my circle-squaring proposal from the last VWG call comes from: move all CDLs into a CommonLUT file and embed the CLF into the AMF itself, by simply extending the XML namspaces.

If the group wants to, I’m fine removing the internal CDLs and only allowing for external referencing of CDLs. We can promote CLF as a carrier but I don’t think we can require it as the only carrier as there’s so many systems currently supporting CDLs in other carriers.

I’m pretty sure we previously said we didn’t want to embed transforms (CLF or others) in the AMF though.

When I proposed that AMF may embed a CLF which may embed a CDL, I recall that Doug --and maybe Lars too-- liked the idea, especially as that is a may, and not at all a shall or must.
Instead I had completely missed this desire to never embed transforms in the AMF: I’ve been proposing a few times in the past and I don’t recall I ever received such an opinion so far.

That said, I understand the reasoning behind not embedding a color-transform in a color-pipeline file: it depends on the workflow.

If that is the way to go, then unambiguous specifications must be given about “smarter” ways to recall color-transforms from withn AMF, than just relying on filenames or ColorCorrectionRef. If not‒ something bad may definitely happen ‒ like in the below step by step timeline example:

[it’s a bit long timeline – but bear with me for 2 minutes. Also, I’m not implying this is a universal workflow, but some parts of it may be potentially similar to yours]

Company-A (a dailies department?) sets up an AMF with its on-set pipeline. The AMF describes a two-layer LMT made up of a show-LUT from file showLUT.cube, and -say- the twentyfourth CDL from the pre-grades’ collection file of the day, 2020-mar-03.ccc.
The AMF thus references an external file (showLUT.cube) and an external CDL by just containing the line:
<cdl:ColorCorrectionRef ref="0024"/>

Company-A shares the above AMF with Company-B (a DI department?) and Company-C (a VFX lab?).
It may or may not forget to add externally-referenced files showLUT.cube and 2020-mar-03.ccc as well.

Company-B starts grading the movie and imports the AMF. They happen to have another LUT ‒from a totally different show‒ that is also named showLUT.cube. At this point it is irrelevant from where the LUT is taken from ‒ certainly it’s not from the same path it was available at Company-A’s premises.
At this point, in fact, the grading app loads the LUT file with same name, totally breaking the color-pipeline ‒ and no way for the colorist to be advised about it.

Possible solutions to the above problem:

  • AMF should reference external LUTs and CDLs by their hash as well
  • applications parsing AMF must issue a UI warning in case externally referenced files can’t be re-linked
  • AMF may embed everythin inside by means of XML namespacing

Company-C starts pulling the VFX plates. Now, the AMF references a somewhat external CDL tagged as “0024”, but from where does this CDL come from?
Even if 2020-mar-03.ccc file were received from Company-A, there is no technical way for Company-C to acknowledge it comes from that collection, and not from -say- colllection file my-favourite-CDLs.ccc.
End result: artists either won’t see the pre-grades at all, or (even worse) will take the CDL from another file ‒ again breaking the pipeline without a way to be acknowledged about the mistake.

Smarter companies, with a strong color-science department, will always have processes already in place to not fail the workflow whatsoever.
Any other companies instead ‒to whom AMF is even more important‒ will eventually fail.
In either cases, AMF adoption fails to be automatic, and still requires human input to be effective.

All in all ‒as Josh said‒ we don’t need to care how filesystem consistency is maintained: professional software succeeds in achieving that already.
But for that to happen, AMF needs the possibilities to either:

  • unambiguously embed everything within itself (e.g. AMF embedding CLFs, potentially embedding a CDL), or
  • unambiguously reference its external components like LUTs and CDLs.

In the latter case, as per the clipID element, that should not rely (at least not entirely) on filenames, pathnames and/or metadata present only on in external files (like the CDL tag/name pointed to by cdl:ColorCorrectionRef).

Hello Group,
from the implementation point of view I would much prefer embedded CDL values inside the AMF.
About referencing a CLF: the ACES identifier and the checksum in the AMF should be good enough to establish a reliable link.



I’ve attached a new draft of the AMF spec to the above post. This draft will be included with ACES 1.2 RC2 which will be issued imminently.

At this point we are looking for glaring issues (copy/paste bombs, typos, lingering references to tags that have been removed along the way, etc.) We are locking the scope and primary substance of the spec. There may be the possibility to revise the spec in a more fundamental way and/or expand the scope in a later ACES release but please limit any comments prior to the ACES 1.2 release the types of issues noted above.

Thanks Alex.
After yesterday’s call, we’ve decided to wait for some implementors’ feedback on a latest modification that both @Giardiello and myself asked as a last-minute change to the specs. This is about introducing aces:uuid as an additional child to aces:LookTransform with the following usage:

  • in combination with a cdl:ColorCorrectionRef, whereby the latter specifies the identifier of a particular CDL within a Color Corrections Collection (CCC), whereas uuid stores a UUID-type identifier to such CCC (be it either a .ccc file, some object depolyed in a Cloud bucket, an application-neutral database, etc.). In this case, uuid is mandatory.
  • alone, or in combination with other siblings (e.g. hash and transformId), helps to uniquely identify an external resource storing the look transform. In this case, uuid is optional.

Introducing UUIDs helps pinning externally referenced color transforms (e.g. CLFs have a UUID). uuid particularly helps when no transform exists yet when AMF is defined, therefore neither TransormID nor hashes can be used to link with the color transform.

The usecase identified with @Giardiello is when AMF is a template to a well-established color-pipeline; it needs to be associated to a rolling CDL (that changes at every shot), but it still does not exist because footage has not yet been shot or graded.
So, an empty CCC is generated along with the AMF: both are assigned UUIDs at creation time and the AMF points to the CCC by means of the colorTransform >> uuid element. Shot by shot, a link to individual shots’ CDLs will be managed by the colorTransform >> ColorCorrectionRef element.

It’s great to have other implementors’ feebdak as soon as possible (within the next 6 days at the latest).