CLF Spec Review Period

Discussions - ACES Development VWG – Common LUT Format (CLF)
49

Hello Zach.
I agree with you that ACEStransformID is not really enforceable the way it is written here
Again, I’d favor its attribute name to be namespaced like something:transformID. When TransformID uses the ACES naming convention in S-2014-002, then it makes completely sense having something = amf or something = aces, since that is its ontology.

Going back to the generic id attribute comment. That may be formatted as either:

  1. a UUID-style identifier… urn:uuid:.....
  2. an ACES Transform ID according to syntax in S-2014-002
  3. an hash of the transform or the CLF itself
  4. any other identifier string

So, without any further and “stronger” XML typing, how is an implementation supposed to parse this attribute value? Try to match a reg.exp. against #1, otherwise against #2, then vs #3, and fallback to #4 if anything else fails?
I think there are more streamlined ways to implement this in an XML schema.
Proposal: Instead than having just id attribute, use of either:

  1. a uuid attribute (in case of #1), and/or
  2. an ACEStransformID attribute (in case of #2), and/or
  3. a hashalg and digest attributes couple (in case of #3)
  4. a generic id attribute (in case of #4).

As a last comment, I find ACES Transform IDs utility in CLF for three usecases:

  • when a CLF implements an ACES standard transform, but even more so
  • when a CLF is some creative or technical LUT made up of several components, some of which are exactly ACES standard transforms.
  • to improve the capability of LUT managers to address and aggregate and catalog large collections of LUTs by segmenting into and acknowledging by common components/nodes.

While the first usescase is trivial, the second and third are outstanding (and the second the most subtle of all):

Just think of a show LUT from Log.C to P3 which internally uses a creative LUT baked in ACEScg.
Such a LUT is probably a concatenation of at least:

  • an IDT 3d LUT from Log.C to ACES2065-1,
  • a 3d LUT from ACES2065-1 to ACEScg,
  • the creative 3D LUT itself (in an ACES workflow, this node would be an LMT),
  • a 3d LUT from ACEScg to ACES2065-1
  • the RRT 3d LUT
  • the ODT 3d LUT from ACES2065-1 into DCI P3

Please not this may but, in fact, is not AMF. Such a CLF concatenates 5 out of 6 nodes which implement standard transforms that can be addressed by Transform ID. The CLF is a non-ACES monolithic LUT, so it may not make sense to have it represented as an AMF.

If the CLF standard is capable of flagging one of the passages of the LUT with the proper ACES transform ID, an application parsing the CLF may acknowledge what the passage is and, possibly, replacing the LUT mechanics with its own ACES implementation, which may be either more performing and more accurate than an interpolation baked in one LUT.

If one needs the exact mathematical implementation of the LUT, instead, this may even be counterproductive. Yet, id-like attributes are still useful for the last of the three usecases… so utilities can factor in “common parts” in a series of LUTs that do similar things.

Of course, nothing prevents applications to honour other IDs and UUIDs to trigger internal operations for non-ACES color transforms as well – if they have means to do so.

Hope my post is clear and explanatory.

1 Like