From the meeting notes:
Alex Fry: I want to reintroduce the iterative gamut hull solve, to see what effects are coming from the approximation.
@alexfry, the goal hopefully isn’t to bring back the iterative solver, as it’s not really practical for performance reasons. And for the forward direction the difference, if memory serves, wasn’t visible with the approximation.
Worth noting also that another way to deal with those hues where the approximation is smaller than the real boundary (I think yellow might have been one) is to actually use the cusp smoothing. The cusp smoothing will expand the shape a little bit so that the approximation in practice is always going to cover the whole gamut, plus of course the cusp will be smooth.
Here’s a little video that shows the cusp smoothing for yellow, as I adjust the smoothing between 0 and 1. It shows how the line above the cusp that might have been under the real boundary line is more than likely going above that line when smoothing is increased in Rec.709 (I guess we don’t have visualization for the intersection itself?). The cusp smoothing itself has not been optimized yet in any way. But it’s a simple way to adjust the size and shape of the boundary approximation.
For the gamut mapper I have been thinking that maybe we should be looking for much simpler approach as well, one where we don’t perhaps have to calculate the boundary intersection at all. I’m reminded of @bottosson’s gamut approximation for Oklab where the whole gamut hull, I suppose, is approximated. I implemented that, as well as the old ZCAM DRT gamut mapper, in OkishDRT where the mapper was selectable with a checkbox.