AMF and transformIds for "special" IDTs and ODTs

Discussions - ACESNext VWG – ACES Metadata File (AMF)
1

The AMF spec includes detailed restrictions for the transformIds that can be used as IDTs and ODTs. During the implementation of AMF we ran into a few questions with that.

IDT for ACESproxy

In previous versions of our software we have been using the following transform as an IDT for ACESproxy input: ACEScsc.Academy.ACESproxy10i_to_ACES.a1.0.3.

As of the current spec of AMF that transform would not be able to be used as an IDT (the AMF would fail validation, as the transformId for instance doesn’t start with “IDT”).

With the current state of the specification we see the following solutions:

    1. We drop ACESproxy support (or at least AMF export for that) for ACES 1.2 in our software.
    1. We duplicate this transforms and give it a transformId such as IDT.Pomfort.ACEScsc-Academy-ACESproxy10i_to_ACES.a1.0.3, then AMF export would be possible again, but interoperability with other vendors’ systems would be doubtful.

The following cases are additional use cases with basically the same questions:

ODT for ACESproxy

The same question is for the following transform, that’s used as an “ACESproxy ODT”: ´ACEScsc.Academy.ACES_to_ACESproxy10i.a1.0.3?` and that would not be allowed as an ODT.

inverse ODTs as IDTs

Similar situation is for using inverse ODTs as IDTs: For some use scenarios we have been providing the following inverse ODTs to be used in the role of an IDT transform and would like to do so for ACES 1.2 as well:

  • InvODT.Academy.Rec709_100nits_dim.a1.0.3
  • InvODT.Academy.RGBmonitor_100nits_dim.a1.0.3
  • …

Again the current spec of AMF would not allow these transforms to be used as IDTs.

Solutions are similar to above: Either dropping support, or duplicating the transforms with custom transformIds.

These topics boil down to:

  • Did we miss something and there is an easy answer?
  • Are the use of the mentioned transforms as IDTs and ODTs not recommended anyways, and we’re trying to cover use cases that are purposely ruled out?
  • In case we want to cover these use cases, we might need to come up with transformIds for these transforms that qualify as IDT and ODT transformIds.

Any opinions?

Best,
Patrick (Pomfort)

1 Like
2

Yes, sounds like a very valid point.
Nonetheless because these limitations could stop the use of AMF on set when:

  1. a camera is capable of generating a ACES complaint SDI feed (ACESproxy, ACEScct, ACEScc), therefore a input ACEScc/cct/proxy to ACES might be necessary if the chain requires the first LMT step to be in a different space (for instance, in AP0 or in a different log encoding -even just from Proxy to CCT).
  2. The use of invODT as “IDT” is very much possible when generic -not documented- sources are involved on set, or when using broadcast cameras that output video feed in REC 709 or 2020. Not really by the book, but honestly I have ended up using a inv709 for GoPros or video broadcast cameras many times as out of jail solution.

More on point 1. Technically, let’s pretend that one has a camera that produces an ACESproxy output but the working color space for the project is ACEScct, one could make a AMF that assumes that the IDT and the first transform to ACESproxy is already APPLIED in the chain and the first step of the LMT yet to be applied is a transform to ACES 2065 and then to ACEScct. Makes sense? I don’t like it but could be a workaround.

Not solution for the invODT though.

FLG