Introduction
With our software products mainly being used on film sets, metadata transfer from set to other activities has always been an essential part of the requirements. Unfortunately, standardizing metadata formats is a slow process, but one new format – the ACES Metadata File (AMF) – currently comes into focus.
In this article, we want to take a closer look at the design and history of AMF and illustrate how it can transfer look information from system to system by the example of Livegrade.
The ACES Transform Framework
When ACES (the Academy Color Encoding System) arrived in 2014, it brought us not only a huge color space and scene-linear encoded pixels, but also a framework for a color pipeline with individually specified transforms. That framework makes explicit what until then had been implicitly baked together in other color processes, such as the log-pipelines of digital intermediate, typical video workflows, or the color pipelines applied in digital film cameras.
If you are familiar with ACES just a little bit, you probably saw block diagrams with boxes labeled “IDT”, “LMT”, “RRT”, “ODT” and so forth. These boxes represent transforms of a specific purpose, and laying them out one by another distinguishes color transforms by function. So, for example, the IDT (input transform) is the transform that (only) converts color values from an input color space (such as log camera color space and encoding) to a common, scene-referred colorspace and encoding (i.e. ACES2065-1). In contrast, an LMT (look manipulation transform) doesn’t transform between color spaces at all but modifies the colors along with a creative look.
If you want, you can map every one of the other mentioned color processes to the conceptual framework that ACES documents. But you will find that during this mapping, the framework’s single-purpose boxes are sometimes either omitted or merged – often simply because in one component, “LUT”, or device implements multiple transforms in practice. This makes comparing color processes complicated, and the exchange of configurations for such color processes becomes almost impossible.
“Clip-level Metadata”
ACES mainly aims to specify the mentioned color framework and the specifics of the used transforms. Still, there was already the strong urge of the Academy’s working groups to also describe how to exchange information about such pipelines between systems.
Documenting the exact color pipeline for each clip from the camera’s source color space to the display’s color space had become much easier due to ACES’s framework approach. Furthermore, this would allow one to reproduce the creative intent of every clip on different systems during production and post-production.
The first attempt was called “ACESclip” – already part of the ACES specification in version 1.0. The reason for ACESclip being (almost) nowhere implemented and not used today is probably two-fold. First, vendors had to implement the color science of ACES in the first place before thinking about exchanging information about it – and that implementation already was a considerable amount of work. The other reason is that ACESclip has been specified when nobody really could imagine how real-world implementations of ACES would look like. So despite its best intentions, it was not “ready for prime time” yet.
ACES Metadata File and Example
After the release of ACES v1.0 the ACES project lead at the Academy realized that in order make ACES more ready for the real world, the organization around the specifications now had to open up and start to include the community of users and vendors that just made their first steps with ACES. After almost ten years of committee activity behind closed (or at least somewhat hidden) doors, the following versions of ACES should include feedback and proposals from the growing community.
One of the first working groups was the “ACES Metadata File” group, tasked with taking a fresh look at the ACESclip specification and developing an updated proposal for that. The result is the AMF format, a modernized version of ACESclip – in its current version available since early 2021.
ACES Metadata File (AMF) is an XML-based file format that describes all the necessary “look metadata” for recreating the same image on different systems.
An AMF file consists of three parts:
- A bit of metadata about the AMF file itself, with information about the creation time and a descriptive text about its purpose,
- an optional reference to a media clip that the AMF file carries look information for, and
- a detailed pipeline description with a list of all transforms that need to be applied to the clip to recreate the “creative intent” set up on another system.
Let’s look at an example. Below you see a basic look in Livegrade’s “ACES CDL” grading mode.
Now let’s look at the pipeline section of the exported AMF file (download of a ZIP file containing the “New Look” AMF file available at the end of this article).
In this example, the pipeline consists of three transforms:
- The input transform (
<aces:inputTransform>): This transform references the IDT selected in the user interface with a so called TransformID. A look transform looks something like this:urn:ampas:aces:transformId:v1.5:IDT.ARRI.Alexa-v3-logC-EI800.a1.v2.[1] - A look transform (
<aces:lookTransform>) with CDL nodes (<cdl:SOPNode>and<cdl:SatNode>): With the color wheel positions, the user manipulates the values of an ASC CDL – and that gets directly embedded in the AMF file. Important to mention here: A CDL transform is usually applied in a “log” grading space, and this means that the CDL’s working color space also needs to be specified in the AMF file (typically ACEScct or ACEScc). The working color space is also referenced with TransformIDs (i.e., the transforms that convert from the linear ACES color space and encoding into the working color space and back). - The output transform (
<aces:outputTransform>): This transform again uses TransformIDs, in our case the TransformID for the “ACES Reference Rendering Transform” (RRT), and for the output device transform – in our case for the selected ODT “Rec.709” (with TransformIDurn:ampas:aces:transformId:v1.5:ODT.Academy.Rec709_100nits_dim.a1.0.3).
There is one more important, general information that’s also part of the pipeline configuration: the ACES version that the pipeline is based on. With that information, the software’s color pipeline settings can be recreated in other software systems without any guessing or additional context information.
[1] The input transforms for all common digital film cameras are published with their TransformIDs in the ACES software repository so that all vendors can adopt them.
Extending the Look Beyond ASC CDL
The example pipeline above can cover a range of use cases already. But while ASC CDL maxes out the power-to-simplicity ratio, it can only go so far to describe a look. More targeted creative transforms such as shifting individual colors, “desaturating the highlights”, or specific highlight controls cannot be expressed by the ten numbers of an ASC CDL. Different vendor’s color grading systems offer a broad range of additional transforms and controls, and no vendor-independent standard is available yet to exchange such parameters. The fallback for all these transforms is “baking” them into a lookup table.
So can you reference a LUT to AMF? Unfortunately, the answer is not straightforward. Let’s go one step back and look where such a LUT would be placed in an AMF. The right place in ACES is the “Look Modification Transform” (LMT), represented by a <aces:lookTransform> node in AMF. But “by the book”, an LMT is always applied in the linear encoding of ACES2065-1. And I guess the typical “cube LUT” that you might have in mind is not – it’s usually created to be applied in a “log” working color space, similar to the ASC CDL transform. Unfortunately, the solution is not as easy as creating a new cube LUT that works in linear. Linear and “log” encodings lead to a totally different distribution of the LUT’s sampling points in the brightness range. So there is a good chance your LUT will not be able to represent the underlying transform properly in linear encoding.
To be applied in the linear encoding of ACES, a new LUT format is required – dedicated to the specific requirements of linear signals and providing the maximum precision needed for use cases from preview to finishing: Please meet the Common LUT Format (CLF).
CLF is not a “lookup table” per se but describes its color transform with one or more operators, where some of them can be lookup tables, but others are mathematical instructions (such as a 3×3 matrix or a log curve). With that, CLF is the “LUT” format suited to the requirements of AMF. And software systems can even pack the mentioned “log-to-log” cube LUT into a CLF file by bracketing it in transforms from linear to log encoding and back so that it becomes a real LMT in terms of ACES.
So far, we saw either concrete values (i.e. the ASC CDL values) or TransformIDs for configuring the transforms in an AMF file. In order to work with CLF files, AMF transforms also allow to reference external files – and the only referenced files that AMF supports are CLF files.
So let’s look at an extended example where the look not only consists of an ASC CDL transform, but also of an additional curve node that desaturates green colors a bit:
That’s a look that cannot be represented with ASC CDL alone. The exported AMF file (download of a ZIP file containing the “More Nodes Look” AMF and CLF file available at the end of this article) looks very similar to the example above, but with one additional <aces:lookTransform> after the look transform with the CDL values. This new look transform references a CLF file that contains only the transform of the “HSL Curve” node in Livegrade. In order to be a proper “LMT”, Livegrade creates that CLF so that it contains the Hue-Saturation to be applied in linear encoding. When another application imports that AMF-plus-CLF-combo, we won’t get the curve UI back (as that system might not have that exact UI)[2]. Still, the resulting transform can be applied so that it results in the exact same image as in the originating software.
[2] Actually, it is already possible today to embed vendor-specific metadata in CLF files. So while other systems may “only” be able to apply the CLF, a round-trip workflow can bring back slider positions and filter settings as long as the CLF file with the vendor-specific metadata stays intact.
The Next Steps
The combination of AMF and CLF[3] provides a great foundation for exchanging looks in the context of ACES. Systems can exchange information about the overall ACES pipeline, any used ASC CDL parameters, and additional LMTs with additional transforms. Such transforms can be fixed (referenced by TransformID), such as the Reference Gamut Compress transform introduced with ACES 1.3, or custom ones with referenced CLF files.
For creative look transforms, AMF doesn’t limit software vendors in how they design their controls but allows for an exact replication of the output of such specific controls in other systems. That allows for more advanced creative work that is reproducible in all stages of film production. And AMF already comes with the possibility to represent even IDTs with CLF files, which will enable interoperability between systems and activities even more once supported by systems.
To be honest, at the publication time of this article there are not many systems implementing AMF and CLF yet. AMF and CLF is simply not “just another LUT format”. But AMF and CLF have been developed by large working groups with members from studios, productions, vendors, facilities, and users. So there is a general consensus that AMF provides a good solution for a real-world problem.
Livegrade, in its current version (as of August 2022), supports ACES 1.3 with AMF import and export – also including full CLF support for reading and writing. Silverstack will inherit these features in the near future. There is also work underway to implement support for AMF in different other ACES-aware systems. For example, Colorfront also added AMF support to their products, and the OpenColorIO project published a huge milestone to include AMF and CLF support for configuring an OCIO pipeline. Once the benefits become tangible with the first few implementations, the awareness of AMF might rise a lot in the coming months.
[3] CLF is a standard independent of ACES and can also be used in other contexts of color management, not related to ACES.
Summary
This article introduces the ideas around the ACES Metadata Format and illustrates what makes it different from other “look formats”. AMF is an open standard developed by a community of vendors and users, and with joint effort, it can become an exciting option to build new look and color management workflows – starting on set and reaching even beyond post-production.
Resources:
- Zipped sample files
Further reading:
Updated 2022-08-09: Edits on last paragraph to reflect current state of implementation in Pomfort products
