Cusp finding algorithm choice needed

[KevinJW]

Nick mentioned the DCTL version of the cusp finding is different to the blink implementation and Pekka mentioned that he believes a functional version should be possible.

DCTL uses h based on even spacing in JMh
Blink uses a spacing based on the display/mastering gamut

We should select one

[KevinJW]

My thought is we should base it on JMh as this is independent on the display gamut if possible.

[nick-shaw]

The cusp is of course the cusp of the display (or limit) gamut, so it is not independent of that. But an evenly spaced LUT in JMh (as my DCTL uses) makes for an easier look-up than an unevenly spaced one. The uneven spacing requires an iteration to find the two table entries to lerp between.

[KevinJW]

So if we find the actual spacing of the blink approach and then sample at the highest resolution needed to match we should have a better fit and no iteration, the only issue would be if that makes a huge shift in the LUT size ?

[alexfry]

Perhaps we use the inverse method to create a high resolution temp 1D LUT, maybe 4096 entries in the target gamut's H (HSV) space, then resample that down to a smaller 1D LUT in the h (JMh) space. That makes the per pixel lookup nice and fast, and keeps the preparation simple and accurate.

[nick-shaw]

Adding a note that we (so far) kept the uneven JMh spacing for cusp lookups because that means there are entries at precisely the hues of the primary and secondary 'points' of the gamut. While a single, evenly spaced lookup for all cusps and gamma values might be faster (at the expense of a longer oversample and then down-sample init() process) a table with more than 360 entries would be needed to be sure we had values at least close to the 'points'.

Note: The start of this thread said the DCTL used a different approach. This is no longer the case, and the DCTL now uses the same tables as the Blink, but pre-calculated in Python.