ACES Metadata File (AMF)

What it is

An ACES Metadata File is a small XML sidecar that describes the complete ACES colour pipeline for a clip - which input transform was used, which output transform, the display's peak and minimum luminance - in the standardised Academy format (TB-2014-009 / S-2019-001). Downstream tools like Resolve and Baselight read it and can reconstruct the identical transforms automatically, which is the whole point: the shot arrives with its colour intent attached instead of in someone's notes.

This node writes and reads those files, and nothing else. No pixels.

Write mode

You describe the pipeline in the widgets and it produces the AMF XML, optionally saving it to disk.

clip_name is the identifier written into the file - default Untitled, so set it. input_transform and output_transform are ACES URNs, and the defaults show you the format: urn:ampas:aces:transformId:v1.5:IDT.Academy.ADX10.a1.0.3 for input, urn:ampas:aces:transformId:v2.0:ODT.Academy.Rec709-100nits.a2.0.0 for output. A URN is not a friendly name - if you typo one, Resolve will refuse to apply the file, and typically without much explanation. Copy them from the ACES transform registry rather than typing from memory.

peak_nits and min_nits go into the file as the output transform's peak and minimum luminance. The defaults (100 nits peak, 0.005 nits black) are standard SDR. description is free text stored in the AMF's info block - it's XML-escaped, so quotes, ampersands and angle brackets are safe. save_path is where the .amf lands; leave it blank and the node builds the XML and skips the write, which is how you preview the output before committing a path.

Read mode

Flip mode to read, paste AMF XML into amf_xml_in, or point save_path at a file. The node parses it and returns the XML plus amf_summary.

One implementation detail that's worth mentioning because it's the kind of thing this pack does consistently: parsing goes through defusedxml, not the standard library's ElementTree. XML is a format with a long history of parser exploits - entity expansion and the like - and a node that happily ingests XML pasted in from outside is exactly the wrong place to use the default parser. Small decision, right call.

Outputs

amf_xml (the full XML string, in both modes) and amf_summary (a readable digest - clip name, transforms, luminance). Both are strings, so they're for logging, notes, or handing to something else that writes files.

Who this is for

If you're handing shots between Radiance and Resolve, or archiving a show so the colour decisions survive longer than the project file, this is the correct container and it's a five-minute addition to a workflow. If you're generating images for the internet, you will never touch it, and that's fine - the KB's read on colour management in this ecosystem is that it's a specialist corner where the moment you need it you need all of it.

The realistic beginner use is narrower and more useful: reading an AMF someone else sent you to find out what transforms they used. That works, and it beats asking.

Install

ComfyUI Manager → search Radiance → install → restart → refresh the browser. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/fxtd-studios/radiance.git
cd radiance
python -m pip install -r requirements.txt

On Windows portable, run pip with ComfyUI's bundled python_embeded\python.exe. The XML parsing here is handled by defusedxml, which is a declared requirement, so a fresh install via the README's steps covers it.

Gotchas

• URN typos. The most common failure, and it fails at the other end - Resolve silently declines to apply the file rather than shouting at you.
• save_path left blank in write mode. That's the "build it, don't save it" behaviour, not a bug. If nothing appears in the folder, check this first.
• Paths. Absolute paths are used as given; there's no output-folder-relative convenience here like the CDL nodes have. If you want it in a project folder, type the full path.
• Expecting it to change your image. It never touches pixels. It's documentation that happens to be machine-readable.
• Version mismatch between the URN's ACES version and the transforms actually applied. The file records what you told it. Nothing validates that against your graph.