ACES Metadata File (AMF) Specification¶

Scope¶

This document specifies the ACES Metadata File (“AMF”), a ‘sidecar’ XML file intended to exchange themetadata required to recreate ACES viewing pipelines.This specification supersedes TB-2014-009 – Academy Color Encoding System (ACES) Clip-level MetadataFile Format Definition and Usage (“ACESclip”). TB-2014-009 is now considered obsolete.

References¶

The following standards, specifications, articles, presentations, and texts are referenced in this text:

Introduction¶

Why is metadata needed for ACES?¶

ACES defines a standard color encoding (SMPTE ST 2065-1) for exchange of images, along with InputTransforms to convert from different image sources to ACES, and Output Transforms in order to view ACESimages on different types of displays.

However, when exchanging ACES images during production, there is often missing information required tofully describe the viewing pipeline or “creative intent” of that particular image.

Examples of such information:

ACES Version – which version of ACES was used?
Look Transform – is there a creative look?
Output Transform – how was this viewed on a display?

To maintain consistent color appearance, transporting this information is crucial. Additionally, this information serves as an unambiguous archive of the creative intent.

What is AMF¶

The ACES Metadata File (“AMF”) is a sidecar XML file intended to exchange the metadata required to recreate ACES viewing pipelines. It describes the transforms necessary to configure an ACES viewing pipelinefor a collection of related image files.

An AMF may have a specified association with a single frame or clip. Alternatively, it may exist without anyassociation to an image, and one may apply it to an image. An application of an AMF to an image wouldtranslate its viewing pipeline to the target image.

Images are formed at several stages of production and post-production, including:

Digital cameras
Film scanners
Animation and VFX production
Virtual production
Editorial and color correction systems

AMF can be compatible with any digital image, and is not restricted to those encoded in the ACES (SMPTE ST 2065-1). They may be camera native file formats or other encodings if they have associated Input DeviceTransforms (IDTs) (using the <inputTransform> element) so they may be displayed using an ACESviewing pipeline.

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, suchas a CLF (Common LUT Format). Multiple <lookTransform> elements are allowed, and the order ofoperations in which they are applied shall be the order in which they appear in the AMF.

AMFs can also serve as effective archival elements. When paired with finished ACES image files, theyform a complete archival record of how image content is intended to be viewed (for example, using the <outputTransform> and <systemVersion> elements).

AMFs do not contain “timeline” metadata such as edit points. Timeline management files such as EditDecision Lists (EDLs) or Avid Log Exchange files (ALEs) may reference AMFs, attaching them to editingevents and thus enable standardized color management throughout all stages of production.

amfDiagram — **Figure1 1.**Overall structure of an AMF in simplified form.

Use Case¶

ACES Metadata Files (AMFs) are intended to contain the minimum required metadata for transferring information about ACES viewing pipelines during production, post-production, and archival.

Typical use cases for AMF files are the application of “show LUT” LMTs in cameras and on-set systems,the capture of shot-to-shot looks generated on-set using ASC-CDL, and communication of both to dailies,editorial, VFX, and post-production mastering facilities.

AMF supports the transfer of looks by embedding ASC-CDL values within the AMF file or by referencingsidecar look files containing LMTs, such as CLF (Common LUT Format) files.

Look Development¶

The development of a creative look before the commencement of production is common. Production uses this look to produce a pre-adjusted reference for on-set monitoring. The creative look may be a package of files containing a viewing transform (also known as a “Show LUT”), CDL grades, or more. There are no consistent standards specifying how to produce them, and exchanging them is complex due to a lack of metadata.

AMF contains the ability to completely specify the application of a creative look. This automates the exchange of these files and the recreation of the look when applying the AMF. In an ACES workflow, one specifies the creative look as one or more Look Modification Transforms (LMT). AMF can include references to any number of these transforms, and maintains their order of operations.

The input and output of an LMT is always a triplet of ACES RGB relative exposure values, as defined in SMPTE ST 2065-1. This will likely need a robust transform, such as CLF, that can handle linear input data and output data.

AMF offers an unambiguous description of the full ACES viewing pipeline for on-set look management software to load and display images as intended.

On Set¶

Before production begins, an AMF may be created and shared with production as a "look template" for use during on-set monitoring or look management.

Cameras with AMF support can load or generate AMFs to configure or communicate the viewing pipeline of images viewed out of the camera's live video signal.

On-set color grading software can load or generate AMFs, allowing the communication of the color adjustments created on set.

Dailies¶

Dailies can apply AMFs from production to the camera files to reproduce the same images seen on set. There is no single method of exchange between production and dailies. AMFs should be agnostic to the given exchange method.

It is possible, or even likely, that one will update AMFs in the dailies stage. For example, a dailies colorist may choose to balance shots at this stage and update the look. Another example could be that dailies uses a different ODT than the one used in on-set monitoring.

This specification does not define how one should transport AMFs between stages. Existing exchange formats may reference them, or image files themselves may embed them. One may also transport AMFs independently of any other files.

VFX¶

The exchange of shots for VFX work requires perfect translation of each shot’s viewing pipeline, or ‘color recipe’. If the images cannot be accurately reproduced from VFX plates, effects will be created with an incorrect reference.

AMF provides a complete and unambiguous translation of ACES viewing pipelines. If they travel with VFX plates, they can describe how to view each plate along with any associated looks.

VFX software should have the ability to read AMF to configure its internal viewing pipeline. Or, AMF will inform the configuration of third party color management software, such as OpenColorIO.

Finishing¶

In finishing, the on-set or dailies viewing reference can be automatically recreated upon reading an AMF. This stage typically uses a higher quality display, which may warrant the use of a different ODT than one specified in an ingested AMF.

AMF can seamlessly provide the colorist a starting point that is consistent with the creative intent of the filmmakers on-set. This removes any necessity to recreate a starting look from scratch.

Archival¶

AMF enables the ability to establish a complete ACES archive, and effectively serves as a snapshot of creative intent for preservation and remastering purposes. All components required to recreate the look of an ACES archive are meaningfully described and preserved within the AMF.

One possible method for this could be the utilization of SMPTE standards such as ST.2067-50 (IMF App #5) -- commonly referred to as "ACES IMF" -- and SMPTE RDD 47 (ISXD) -- a virtual track file containing XML data -- in order to form a complete and flexible ACES archival package.

Another method could be to use SMPTE ST.2067-9 (Sidecar Composition Map) which would allow linking of a single AMF to a CPL (Composition Playlist) in the case where there is a single AMF for an entire playlist.

Data Model¶

This section describes the data intended for use within the ACES Metadata file.

All top level structures shall be tagged as being within the \texttt{aces} namespace with urn urn:acesMetadata:acesMetadataFile:v1.0

UML Diagram¶

The following UML diagrams are segments of the complete UML diagram which is not included in this document due to space constraints. To view the entire UML diagram in SVG format visit \url{https://aces.mp/amf_uml}.

acesMetadataFile¶

amfInfo¶

clipId¶

pipeline¶

pipelineInfo¶

inputTransform¶

lookTransform¶

outputTransform¶

Types¶

The following types are defined for use within the AMF XML file and are validated with the XSD schema included in Appendix A. The types are used as the basis to form the elements listed in section X in the schema.

\input{sec-types.tex}

Elements (by type)¶

The following elements are defined for use with the AMF XML file and are validated with the XSD schema included in Appendix A.