I was giving some thought to this, following the point Rod raised during the TAC meeting today, and I’d like to make a suggestion regarding the lmtWorkingSpace element.
This element is intended to specify the conversion between ACES2065-1 and the color space that an LMT is to be applied in. According to the draft spec, the element is allowed to contain acesToLMTWorkingSpace and lmtWorkingSpaceToAces elements.
My suggestion is that we delete the lmtWorkingSpaceToAces element. In other words, it would be better for AMF to only specify the conversion from ACES2065-1 to the LMT space. The spec should simply state that the conversion from the LMT space back to ACES2065-1 is implied to be the inverse of the specified transform.
If the spec allows both directions to be specified, it opens the door to a number of implementation problems (e.g., what if someone specifies a transform pair that are not inverses). Furthermore, it potentially caps the maximum possible quality of the inverse due to LUT limitations. An implementation should be allowed to apply an exact inverse. Also, an implementation should be allowed to skip unnecessary conversions, e.g., if a stack of LMTs all use the same working space.
Also, I’d like to get a clarification on what the acesToLMTWorkingSpace element is allowed to contain. In some places in the draft spec it seems to imply that it is a string containing an ACES transform ID (i.e., the ones contained in the CTL code in the ACES GitHub repo). Hence the proposal that additional CSC transforms be added to ACES 1.2 that would supply the necessary ACES IDs. However in section 6.2.18 the draft spec says it contains the “transformID of the color space transform that shall be used to convert from ACES to the LMT Working Space.” And the spec elsewhere seems to allow a “transformID” to be an externally referenced file (e.g. a CLF file). So which is it, must the contents of the string be defined in the ACES 1.2 transform collection, or may it be a file name of an arbitrary user LUT?