LMT color space tags

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?

Doug

2 Likes

Has there been any further resolution to this topic?

I would side with Doug on the first point, however it does rely on the answer to the second question.

I too am a bit confused, are the working space transform IDs exclusive to the ACES CTL-based transforms?

Hi Sean!

We actually just discussed it on this morning’s call. There will be a recording and transcript posted soon, but here is my attempt at summarizing the two options we discussed:

Option 1:

  • <acesToLMTWorkingSpace> will be used to reference the transform to the LMT working space.
  • <lmtWorkingSpaceToAces> will be removed, and the spec will include language that it must convert back to ACES 2065-1 based on the inverse of the above transform.
  • New ACEScsc transforms for the color spaces that have invertible IDTs (i.e. LogC, SLog, etc.) will be included in the ACES v1.2 transform collection.
  • Transform ID must refer to one of these ACEScsc transforms.

Option 2:

  • Keep both <acesToLMTWorkingSpace> and <lmtWorkingSpaceToAces>
  • New ACEScsc transforms for the color spaces that have invertible IDTs (i.e. LogC, SLog, etc.) will be included in the ACES v1.2 transform collection.
  • Support custom working space transforms (i.e. CLF) as long as it follows the ACEScsc naming convention (to be added to ACES versioning spec, @Alexander_Forsythe to link )

We kind of ran out of time at the end of the call so I would love for others to chime in who had thoughts on this. I tend to lean towards option #1 to keep things cleaner, but the argument for #2 was that new color spaces tend to pop up in real-world productions, and would need custom transforms without waiting for it to become an official ACES transform (as we see all the time with IDTs).

Thanks,
Chris

After today’s call and thinking about this some more, I’d like to modify my original proposal. I think that <lmtWorkingSpaceToAces> would be the better of the two elements to keep. This is because the LMT working spaces tend to be more perceptually uniform and hence more amenable to representation as LUTs. Even if we don’t allow custom LUTs now, a future revision may add that feature (and I agree with Josh that it could be useful, although it does add complexity).

So my updated proposal is to keep <lmtWorkingSpaceToAces> and delete <acesToLMTWorkingSpace>.

Also I would argue that this proposal is actually even more important if we allow custom LUTs (so maybe there is the possibility for an option 3?).

Doug

I’m a little late here and missed the meeting last week, but wanted to put my thoughts out before too long.

I tend towards liking option 1 for initial implementation (though could go either way on which tag is kept, as long as there’s only one and it’s clear that the exact inverse is expected). Mostly because I think this option is cleanest and simplest for this initial implementation, and gets the common LMT working spaces added and released for 1.2, which is a huge win.

I feel like custom options could be added as a new version later, and that initially, the simple option will support easier implementation and clarity for users. My two cents!

Thanks Doug and Carol.

Is it too much to expect implementers to convert back to ACES 2065-1 automagically without explicitly providing that ‘back-to-ACES’ transform? Would it only be feasible if it is limited to the provided ACEScsc transforms?

For example, what if a custom transform is provided that is not mathematically invertible? What should happen?