shaders/icc: set icc transfer to closest value

I would prefer not exposing this publicly - it's very specific to ICC, both in its ignorance of how to handle this for HDR, and its general low usability outside the very specific context of needing to measure/estimate the gamma of a look-up table. It also invites using inaccurate approximations.

Wouldn't it be better to measure the MSE of the target curve against the measured curve directly, rather than basing this off the approximation gamma?

You mean to implement all PL_COLOR_TRC in C and compare them with the response from ICC profile? Seems like much code for this silly feature.

True, but it's the price you pay for this feature actually being useful. 9 times out of 10, the most interesting thing about a profile is whether it's BT.1886, gamma 2.2 or sRGB. This methodology cannot even resolve that distinction because both are hard-coded to 2.2, so it'll use the numerically first one. Not good design IMO.

I think I'll just go ahead and make a C implementation of the TRCs, it's useful anyway

That's good point, I was thinking about it, but out of laziness just left it as is.

I think I'll just go ahead and make a C implementation of the TRCs, it's useful anyway

I can help, but give me pointer how would you like the API to look like for those?

Well, if we want it to be able to apply the HLG OOTF, it needs to handle all three channels at the same time:

void pl_color_linearize(const struct pl_color_space *csp, float color[3]);
void pl_color_delinearize(const struct pl_color_space *csp, float color[3]);

That way it can be the natural mirror of pl_shader_(de)linearize, with no unexpected surprises.

Maybe having the *csp be the last parameter will allow this more useful construction:

float color[3] = { 0.5, 0.5, 0.5 };
pl_color_linearize(color, pl_color_space(
    .primaries = FOO,
    .transfer  = BAR,
));

As a side note, you may be interested in this:

https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/fflcms2.c#l302

It might actually be easier to re-use the Little-CMS implementation of these transfer functions for our purposes as well. But I feel like a generic C function would be more interesting/useful long-term.

mentioned in commit haasn/libplacebo@e0515e92

mentioned in commit haasn/libplacebo@e5151770

mentioned in commit haasn/libplacebo@cb228d74

closed

mentioned in commit 2617a3c1