Rethinking working spaces for AMF

Hi all,

We are proposing some changes to the schema that could use another round of review and comments before the release of ACES v1.2. The goal with these changes was to help simplify implementation and address interoperability concerns raised about custom working spaces.

The changes can be found here and summarized below:

  1. LMTs must apply in ACES (2065-1). This keeps LMTs more ‘universal’ and increases the chances of interoperability across software. It also keeps them in line with the LMT spec. We believe there is more work to be done here: to educate the industry on LMTs, refresh the 2014 spec, and create tools for users to make them (LMT working group?). What we wanted to avoid was a wild west of LMTs floating around with unknown input/output spaces, which is not much better than what happens today in a non-ACES workflow. With this change, advanced users could still make LMTs that internally go from ACES to another working space to perform an operation and go back to ACES.

  2. CDLs can still apply in a custom working space. This means that more advanced workflows can still utilize CDL in a non-ACES working space for ‘knob turning’ such as those included as ACEScsc color spaces included here.

We felt this was a good compromise for the current AMF spec and the release of ACES v1.2. It is possible that new working spaces are introduced (or deprecated) by the time ACES v2.0 is released, and AMF could be revised at that time if necessary.

Please let us know your thoughts!

Thanks,
Chris

cc: @Alexander_Forsythe

Hi Chris,

TLDR: I’m somewhat worried by the proposal but not opposed to it.

Thanks for posting about this potential change as I think it could have a significant impact on how widely AMF gets adopted. My impression of current ACES workflows is that it is not uncommon to have a look LUT that does not expect / produce ACES2065-1 on input / output. So the decision to not support those use-cases should be validated as widely as possible.

On the plus side, it may encourage people to standardize on a common processing space for look transforms. On the other hand, it may cause some people to simply not adopt AMF.

I agree that allowing custom working spaces implies that there would be LMT transforms that would be expecting a wide variety of color spaces. But is that a problem? In other words, the AMF file is documenting what the input and output color spaces are.

As I posted earlier, while I do think there are a number of implementation challenges and things that do not seem to be adequately defined, disallowing custom working spaces for LMT LUTs does not seem to make things significantly better.

From an implementation point of view, once the mechanism is in place to allow custom working spaces for CDLs, I would think that supporting it for LUTs too requires very little additional work. I do suspect that there will be interop problems getting the custom working space to work, but once it works for CDLs, it should work equally well for LUTs, right?

All of that said, I am not opposed to your proposal. I do worry it may hurt AMF adoption, but then again there has been no flurry of postings from people objecting, so I may be wrong!

Looking at Alex’s recent commit however, it looks like lookTransformWorkingSpace was changed to cdlWorkingSpace. Given that the CDL lives under an element called lookTransform anyway, I think it would be better to stay with the earlier, more generic term. This would make the implementation easier if we later decide to allow it for LUTs too.

Doug

Hi Chris.
I read just now.

I just have a comment on CDLs, as I saw that CDL referencing an external collection of CDLs (CCC) is allowed in the proposed sample. This would endanger the AMF as it may describe a CDL that is actually not contained internally, so ambiguities may arise.

I have two implementation proposals to solve this problem and detailed in the post, as long as with other impressions here:

Hi Chris.
So, as I understand, with this lates proposal the CSC passages have been moved out of the generic LMT and reintroduced only for CDL (because CDLs don’t make much sense in ACES2065-1), with the fromCdlWorkingSpace element, right?

As others commented already: I need to digest this hard bit, but I agree as it feels cleaner now. As @ptr pointed out… this works as long as the CSC is managed, for input and output, completely in the LUT that references the LMT. That is something CLF can do, but other LUT formats don’t do as well.

In my opinion it is paramount to stress the XML extensibility and allow, explicitly with ACES 1.2, that AMF files may include a CLF inside.