Proposed changes to AMF

[CClark (Chris Clark)]

Hello,

Following meeting #1, we would like to farm for feedback on the group’s proposed changes to AMF.
We are also open to any other ideas or feedback on AMF, if they are not listed here.

Please see page 2 and 3 of following google doc and comment as you wish:
AMF Revisions Group (google doc)

They are also pasted here if you have trouble viewing or commenting on the Google Doc:

Specification changes

1. Look Transforms:

• Working Space for CDL: When defining a CDL as an LMT, the specs mandate the use of “From working color space”, but it seems that the “to working color space” isn’t mandatory?
  • Is that intentional? Is it an error in the specs? Should we not mandate both transforms? or make both optionals?
• ColorCorrectionRef: there is an issue with the way AMF works with the ColorCorrectionRef connection within the current specs.
  • There is not a way to connect to an external CCC file and to identify and link the file to the AMF and the CDL ID within it. There are a bunch of different ways we can tackle this issue down with minor specs changes.

2. Applied Tag:

• “Applied” tag name: The “applied=False” has been confusing to every implementer, because it suggests that it “shouldn’t be applied”, rather than “it has not been applied to the image data”.
• “Applied” tag on RRT+ODT: In the current specs, it seems that the “applied” tag can be used for everything but the ODT and RRT transforms.
  • It might just be a typo: in the UML diagram under 6.1.8 for outputTransform, there is no applied attribute. However, under the Types section 6.2.2.13 for aces:outputTransformType, there is an applied attribute.

3. Output Transforms:

• Mandatory RRT/ODT: In the current specs, ODT and RRT are always required.
  • This satisfies the original scope of AMF “how do I view this image?” However, I believe that in these last three years and after some real implementations, new use cases have arisen which require to create AMFs that do not require RRT ODTs (eg AMFs to automate VFX pulls - output EXRs without RRT/ODT applied).

4. “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. This could work in one or two ways:

• New element: add a (name is TBD) element
• New attribute for each transform: a <location=pre> and <location=post> attribute to determine the middle point.

Another item to review is an idea for a “constrained” AMF which we think will help with implementations and cover most use cases of AMF:

Our next meeting will likely be June 22nd so please try to review before then!

Thanks,
Chris

[Alexander_Forsythe (Alex Forsythe)]

Below are my thoughts on the points raised by @CClark

@CClark

Working Space for CDL: When defining a CDL as an LMT, the specs mandate the use of “From working color space”, but it seems that the “to working color space” isn’t mandatory?

• Is that intentional? Is it an error in the specs? Should we not mandate both transforms? or make both optionals?

This was a deliberate choice discussed and made during the original AMF specification group, which I think still makes sense.

The choice was made to specify the CDL working space transform in one direction only to avoid the possibility of a forward / inverse mismatch between the “to cdl working color space” and "“from cdl working color space” transforms.

The “to working color space” transform should be calculated as the inverse of the “from working color space.” transform. If the “to” and “from” were both specified, this could lead to the round trip not matching.

@CClark

ColorCorrectionRef: there is an issue with the way AMF works with the ColorCorrectionRef connection within the current specs.

• There is not a way to connect to an external CCC file and to identify and link the file to the AMF and the CDL ID within it. There are a bunch of different ways we can tackle this issue down with minor specs changes.

I believe this is a bug and should be rectified.

@CClark

“Applied” tag name: The “applied=False” has been confusing to every implementer, because it suggests that it “shouldn’t be applied”, rather than “it has not been applied to the image data”.

I’m for whatever makes the intention of the attribute clear. If changing the name is the best way to accomplish this, so be it. However, I think it would be preferable to provide guidance and avoid a spec change if at all possible.

@CClark

Applied” tag on RRT+ODT: In the current specs, it seems that the “applied” tag can be used for everything but the ODT and RRT transforms.

• It might just be a typo: in the UML diagram under 6.1.8 for outputTransform, there is no applied attribute. However, under the Types section 6.2.2.13 for aces:outputTransformType, there is an applied attribute.

This was not a typo. The expectation was that the media used with the AMF would always be scene-referred, hence it would never have an output transform applied. Adding an applied attribute to output transform related tags is easy enough to do, but this is a new, perhaps valid, use case not originally supported.

@CClark

Mandatory RRT/ODT: In the current specs, ODT and RRT are always required.

• This satisfies the original scope of AMF “how do I view this image?” However, I believe that in these last three years and after some real implementations, new use cases have arisen which require to create AMFs that do not require RRT ODTs (eg AMFs to automate VFX pulls - output EXRs without RRT/ODT applied).

Could this cause confusion if there’s no viewing path specified? Does it make sense to allow this in the XML, but specify a profile for when an AMF is used for this purpose?

@CClark

4. “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. This could work in one or two ways:

• New element: add a (name is TBD) element
• New attribute for each transform: a <location=pre> and <location=post> attribute to determine the middle point.

Based on our last conversation where it was made clear that this is to allow for handshaking with OCIO, I’m in favor of this. I think we should use OCIO nomenclature to clarify the intent of any attributes.

@CClark

Another item to review is an idea for a “constrained” AMF which we think will help with implementations and cover most use cases of AMF:

For CLF we are using the term “Profile”. I think it makes sense to use the term / concept here as well.
The profiles / profile names should indicate use cases. For example, we can specify a vfx-pull profile per the use case discussed above where no output transform is specified.