On the first call it was stated that the specification should not contain optional parts. A “common LUT format” where implementations are not required to implement support for all parts of the format loses its commonality.
I can only find one instance where something is specifically labeled as an extension and is not required. Appendix D, bullet point #1 says, "IndexMaps with dim > 2 are an extension and are not required".
Are there other features that are specifically called out as being optional?
InputDescriptor (optional)
Comment field describing the intended source code values of the ProcessList.
OutputDescriptor (optional)
Comment field describing the intended output target of the ProcessList (e.g., target display).
Not a “feature” in the same way, but I would like these two to be required as well. Any LUT needs correctly formatted input to work correctly, and for the output to be appropriately handled. The number of times I see people say “I like the look of the ALEXA LUT, so I use it with my camera X”.
And if rather than being free text comment fields, there were defined strings to at least specify the ACES colour spaces, that would open up the possibility of automatic pipeline configuration, and reduce the chance of errors.
Good point, currently the interpolation attribute is optional. The spec currently says:
interpolation
Name or description of the preferred calculation used to interpolate values in the 1DLUT/3DLUT. This attribute is optional with a default of “linear” if the attribute is not present. Systems that utilize LUTs may use different types of interpolation; therefore, this attribute is intended as a guide to an application if it wants to attempt recreating the exact outputs of the originating application. Typical values for this attribute would be “trilinear/linear” or “cubic/tetrahedral”.
Is this current wording sufficient for interoperability? Or is it detrimental? How do we allow for other interpolation methods without requiring it? Do we require cubic/tetrahedral interpolation? Do we require more?
I would be fine with tetrahedral and trilinear for 3D LUTs and linear for 1D LUTs. Cubic interpolation is prone to overshoot - I’m not sure if that’s an interpolation method we should even allow. Can anyone provide a use case for it?
To reaffirm what I said a lots of times already, here and there on ACEScentral and in various emails, I’m completely in favor of requiring InputDescriptor and OutputDescriptor as mandatory: that would really contribute in creating a “new” LUT format that can be really interoperated without flawing color science.
Otherwise, CLF is just going to be another generic lookup table format, rather than being a really interoperableColorLUT format.
I’d go just one step further and require some color-space encoding… e.g. CLF standard also including some way of using a fixed table of SMPTE ULs, or UUIDs, even pre-formatted strings to refer to color spaces.
I’m thinking of a LUT expecting a DCI X’Y’Z’ @D60 as source and BT.1886 as output, with several applications, DITs and color scientists free-writing variations of it like:
As regards interpolation, I am also in favor of making it mandatory, but only as long as:
Clear 1-to-1 correspondence with algorithms and their referring string in CLF is tabled down in the spec (again: defining UUIDs or SMPTE Unified Labels for rach algorithm).
All allowed algorithms are mathematically detailed and, in case a product doesn’t implement the same algorithm, clear rules on how this needs be handled be also included. This may also include a “default” interpolation that is “free” for anyone to implement? (I am thinking at some HW and SW products’ “secret” LUTtting sauces)
I agree. I have yet to see a software/hardware implementing (at least publicly) an interpolation scheme other than ‘Trilinear’ or ‘Tetrahedral’ (for 3D-LUTs). I explored and tested ‘prism’ and ‘pyramidal’, but they don’t offer real benefits. ‘Spline’ could be an interesting one but there is (far) more than one way of doing it.
Also, each interpolation scheme can be implemented in many different ways, but there is only one right way (the slicing of the sub-cube must always have an edge aligned in the (0,0,0) to (1,1,1) direction).
Finally, because of the different types of math processor a hardware/software solution uses, specifying the interpolation algorithm doesn’t guarantee a 1:1 correspondence between each hardware/software.