Hi !
First post on aces central, i hope i’m in the right section and sorry for my terrible english .
For the past few years, I’ve been implementing the plugin-based architecture described in Animal Logic’s paper for building component-oriented Qt applications.
i’ve built several applications to test this framework and one of them is an AMF toolkit / AMF pipeline tool
It’s still a work in progress , but I’d greatly appreciate feedback(advice, error, any pointers) from people with production experience. and i’ll be happy to share more detail .
-
Reads & writes AMF v2.0, validated against the official aces-aswf/aces-amf XSD (bundled + lxml), with structural + schema verify (GUI command + headless CLI, plus a post-export conformance check).
-
Round-trips an AMF into an editable node graph and back: CDL written natively (SOP/Sat + cdlWorkingSpace transform IDs); parametric grades (Primary/Tone/Exposure/Curves) baked to CLF sidecars (LUT3D sampled in an ACEScct log domain to stay bounded).
-
transformId resolution is config-driven, no hardcoded tables: it reads interchange.amf_transform_ids (OCIO 2.5+) or the embedded ACEStransformID: in descriptions (ACES 1.x), for IDT / LMT / ODT / CSC. The output transform is resolved as the forward URN common to the view-transform ∩ display-colorspace advertised ids. A small canonical-URN registry covers the spaces ACES 2.0 strips from descriptions.
-
IDT-first pipeline: looks are applied after converting the source to the reference space, so non-ACES camera sources (LogC/S-Log3/REDLog) bake correctly rather than being treated as ACES2065-1.
-
Pipeline templates (IDT + ODT + base LMT) as JSON presets you can author in-app and inject in CLI/GUI.
Interop & batch
-
AMF ↔ ASC CDL (.cc/.ccc/.cdl), AMF → 3D LUT (.cube/.3dl/.csp via OCIO Baker, single LUT or the legacy Input-LUT + CDL + Output-LUT split), and legacy 3D LUT → ACES look → AMF (wraps a non-ACES LUT with declared input/output spaces into a self-contained CLF + a new AMF). Baked-LUT vs direct-pipeline error measured at ~4e-4.
-
A unified batch engine drives both a dockable GUI panel (drag-drop queue, per-file status, threaded run) and a headless CLI (python -m atom_review.amf …, CI-friendly exit codes) — full parity, same core.
Still on the bench: AMF → OCIO config generation, and ALE/EDL → AMF ingestion.
**
What I’d loe feedback on:**
-
Is the interchange.amf_transform_ids → view display intersection the right way to resolv the output transform across config versions, or am I missing something?
-
For wrapping a legacy camera->display LUT as an ACES look (inverse-ODT technique: bake to ACES2065-1<->ACES2065-1 via declared in/out spaces) — is that an acceptable interpretation, or should these always be ingested as output transforms?
-
The CLF-bake-in-ACEScct strategy for non-CDL grades for AMF interop — any gotchas you’ve hit (gamut clamping, precision) versus how Resolve/Baselight do it?
