In the AMF Revisions group, it was decided that it would be beneficial to have a “working location” tag or indicator in an AMF in order to distinguish where to split the pipeline in terms of “input” transforms and “output” transforms. Right now, there is no way to know where software should split a pipeline for VFX or color work to happen, especially if there are multiple LMTs (gamut compress, looks, CDLs).
“Working Location” tag addition: In the current specs, there is no way to determine at which point of the pipeline the grading or VFX “work” is meant to be done, this is crucial for VFX work, as it’s hard to define the split line between pre/post compositing. This would also help with OCIO integration to distinguish the ‘reference space’ location.
To that end, we have come up with four proposals using github psuedo-code, here:
We would love for AMF implementors or users to review and vote on which of these methods would be preferred:
POLL: Which “working location” method would you prefer for AMF?
1 - attribute of transform (workAfterTransform=True)
2 - insert new tag (<workHere>)
3 - insert new tag with use case (<workHere useCase="vfx">)
4 - id’s + pipelineInfo method (e.g. UUIDs)
none / prefer no “working location” tag
0voters
Our next meeting will likely be Tuesday Sep 26th at 10AM PT where we will go over these and gather consensus.
But in any case the complexity increase with any of those options is immense.
How should a software “add” those tags. What does the UI look like?
Is it mandatory for a software to be able to add those tags, to be AMF complient?
Is it a list of predefined tags, or just a string?
How do we match up the tags when decoding?
Are those tags optional or mandatory?
How are those tags propagated?
For example a DIT might not know where the VFX tag should be applied. A VFX supervisor could hand over a template with the tag defined. The DIT could than “somehow” copy over the structure and the tag position of the template AMF?
These are just a few question that come to my mind when discussing this.
So to me it is a bit misleading to ask “how” it should be implemented if many workflow implications are not discussed before hand.
These are all great questions, and I share your concern about the added complexity and questions this brings up.
I will spend some time discussing with @Alexander_Forsythe and folks in the group, as well as during my time at IBC next week. To me it’s a question of whether this is a ‘nice to have’ or a ‘must have’ for AMF to achieve its original goals. My current understanding is that for AMF <> OCIO config conversion, it is a ‘must have’ in order to denote the ‘reference space’ point, but for all other use cases, maybe just a ‘nice to have’.
More to come … and thanks again for sharing your thoughts.
We had our follow up meeting yesterday on Sep 26th and agreed to go with Option #2 (new tag). We felt this is the simplest way, for workflows that want it, to delineate a “split point” without the added complexity of multiple use cases, attributes or IDs (and also does not affect the rest of the AMF structure).
In the short term, this will enable workflows and tools that want to utilize it (most likely in VFX pull / ingest systems) and hopefully enable better AMF > OCIO interop.
In the long term, we know there are potential workflow implications as Daniele raised, but we wanted to at least get a mechanism in the spec, and see how it is used in practice, since the next AMF revision cycle could be many months or versions from now.
Note: this will be an optional tag, and is NOT expected to be supported in every implementation to be considered “AMF compliant”.
In the coming weeks, @Alexander_Forsythe and I will be working on collecting all the revisions / changes into a separate post here, but please reach out if you have any questions in the meantime.