Add a C++ implementation for ACES Metadata File (AMF) support

[doug-walker]

OCIO has a Python script (pyocioamf) that converts an AMF file into a CTF that implements the parts of the processing pipeline that the AMF file indicates still need to be applied. This has been useful for the community as a fairly complete open source implementation of AMF. However, this script does not fully meet the potential needs of AMF implementers for several reasons, including:

1. It may be difficult to call the Python script from a conventional C++ application program.
2. The script does not give any flexibility in terms of applying arbitrary parts of the AMF pipeline.

The next steps have been a topic of conversation at OCIO TSC meetings in recent months and the group felt that the best and most flexible approach would be to convert the AMF into an OCIO config rather than a CTF. The config would then allow implementers to apply any steps in the pipeline as desired. For example, they could explore advanced use-cases such as inverting steps that had already been applied or omitting steps (e.g. certain looks) that may no longer be desired.

The meeting discussions suggested the following mapping from AMF to OCIO config:

1. Each AMF look should become an OCIO Look, that may be applied independently (or reversed), if desired.
2. The AMF output transform should become the default display and view.
3. The implementation should draw on the latest built-in ACES Studio config in OCIO 2.3 which contains ACES transform IDs.
4. If the input is a digital camera log color space, the corresponding linear space should also be added, for use in VFX.
5. The resulting config should be compatible with config merge workflows (e.g., names should be unique).

I'm attaching to this issue an example AMF file and a corresponding OCIO config that's in line with the discussions. There are a few details worth calling out:

1. A role has been added (amf_clip_a001a020) to indicate the color space of the associated media.
2. The active_display and active_view are configured based on the AMF output transform.
3. A look has been added to the active_view that implements the unapplied looks (in this case, all the looks still need to be applied, but in general that may not be the case).
4. There is an OCIO Look for each AMF look plus another one that has all of the unapplied looks.
5. The design of the looks allows a user to create a DisplayViewTransform that uses the clip color space role as the source and the active display/view as the destination and it will convert the clip into the output color space in accordance with the full AMF pipeline.
6. The search_path in the example is set to '.', which would be fine if the config were written to the same directory as the AMF, but we're looking for input on how to handle file paths from the AMF. Should the search_path be set to the absolute directory of the AMF file?

We have a contributor that has kindly offered to implement this in OCIO, so we would appreciate timely feedback on the proposed approach.
amf-example.zip

[phil-man-git-hub]

Hello Mr. Walker, Please forgive my ignorance but is there a script that converts a CTF to an AMF? I recently requested AMF export compatibility from Flame. From your email it suggests that one half of that equation (AMF to CTF) already exists. Respectfully, Phil MAN

[doug-walker]

Hi Phil, there is no script to convert a CTF to an AMF. In order to write something like that, there would need to be a way to define which operators apply to which steps in the AMF. The XML could contain this extra metadata but it would be a big task to define how it should work.

The script for the AMF to CTF direction is located along with the other tools in the repo here.

[phil-man-git-hub]

Thank you for the explanation Mr. Walker, I will look at the AMF to CTF script this morning. Respectfully, Phil

[remia]

Thanks for the thorough description @doug-walker, just as an illustration I'm attaching an archive showing what I was thinking when mentioning the applied / un-applied looks categorisation might be unneeded. Note that I changed the AMF to apply the IDT and first 2 looks. The AMF CLIP colour space invert those 2 looks then the output transform always apply all looks for the shot using the SHOT_LOOKS environment variable. It is possible I overlooked some workflows / use case that would not work with this scheme, please let me know.

amf-example2.zip