IndexMaps with dim > 2 and the GPU

[sdyer (Scott Dyer)]

The issue of IndexMaps came up again during last weeks call. Many have already shared thoughts on this issue, but we need to finalize what this group’s recommendation for changing the spec (if any) will be.

In a different thread, a few pros/cons of IndexMaps were already discussed:

Best of existing LUT formats

It would be ideal if CLF was able to encapsulate a LUT from any other LUT format without modification. But I think that is unfortunately not possible. The issue that springs immediately to mind is .csp , with its ability to have arbitrarily spaced input entries in its preLUTs. This can be represented as an IndexMap in the current CLF format, but since IndexMaps with length >2 are not required under the current spec (and therefore not supported in either the Resolve or Autodesk implementations) .…

Key points (according to my interpretation of the discussion):

• We do not want to leave the spec as is - either require IndexMap or remove it entirely.
• There are cases where arbitrarily spaced input entries can be useful.
• There is also some value in being able to directly encapsulate features of any other LUT format (in this case, .csp).
  However, there are serious performance issues with arbitrarily spaced LUTs - so in practice they get cast into a suitably large equally spaced LUT.
• An IndexMap could be converted to a halfDomain LUT, which is effectively a preset IndexMap with samples at every possible half-float code value. If the precision of half-float is acceptable, then by definition its code values will be closely enough spaced samples. For higher precision inputs, values can be interpolated between the halfDomain samples.
• Use cases for IndexMap > 2 are even less now that we are planning to add a dedicated element for lin-to-log and log-to-lin conversions.

It feels to me like the group is leaning toward removing IndexMap from the specification, because halfDomain allows for an arbitrarily spaced LUT to be practically applied (“automated” conversion/compatibility from one to the other is the only thing lost).

Yet I get the feeling there still seems to be hesitation from some about whether obliterating it for the sake of ensuring compatibility is worth the tradeoff of losing the potentially useful feature of arbitrarily spaced LUTs.