lut3d: separate input and output profile

[kmilos]

Addresses the first part of https://github.com/darktable-org/darktable/issues/12261

No idea how to handle all the introspection code and the switching to external ICC file list though.

Also, removed any remaining mention of the "gamma Rec709" misnomer.

[aurelienpierre]

This is a mess.

I don't understand what problem you are trying to solve. I will therefore assume that you try to account for the case where the LUT contains the color space transform, instead of the usual matrix transform typically used in ICC profiles.

In that case, what you do here is wrong because you convert twice to output color space : once in the LUT, once again in your code. What should be done is to simply change the tag of the color space, not apply the transform.

[kmilos]

what you do here is wrong because you convert twice to output color space : once in the LUT, once again in your code.

That's certainly not the idea.

Today we already have two transforms:

working->foo, then apply lut, then back foo->working

This is just assuming you can have foo and bar color spaces in the middle, the same two transforms are kept, one always outputs in the working one from the module.

So if there is any "mess", it seems it was there to begin with.

[aurelienpierre]

Today we already have two transforms:

working->foo, then apply lut, then back foo->working

Which is correct. The rest of the pipeline expects the output of the LUT module to be in working RGB space. Change that and you mess up the whole pipeline. Modules output either Lab or working RGB.

[kmilos]

Agreed. I have not changed this behaviour.

[aurelienpierre]

So what did you do here then, and more importantly, what problem does it solve ?

[kmilos]

I simply extended the module from "working->foo->lut->foo->working" to "working->foo->lut->bar->working".

This is to support off the shelf or custom LUTs (not in ICC format) that contain some creative color space space conversion/gamut remapping.

Yes, you could argue this is beyond the intent/scope of dt and this module, but could potentially open up dt for some new creative uses IMHO. However, the fixed list of color spaces currently offered is holding this back even further.

[wilecoyote2015]

Just for my understanding: You refer to an LUT that represents some color grading operation in the lut application space AND a transformation into another color space (bar)? So lut = (look -> bar)

What exactly is the benefit over a canonical look lut that only performs the look operation in lut application space without the transformation, given that the lut module's output will be backtransformed into the pipeline working space anyway? The only effect of the transformation into bar would be problems with gamut clipping if bar is smaller than the the working space?

[kmilos]

That's the idea, yes, with the exception

The only effect of the transformation into bar would be problems with gamut clipping if bar is smaller than the the working space?

...if bar is smaller than foo (the LUT input color space)

In that case, someone might have baked some secret, hand-crafted, non-parametric gamut compression into such a LUT. Ideally this is already and better addressed by the output ICC profile w/ a LUT, but sometimes all you have is a .cube file...

(It is almost guaranteed that both foo and bar are smaller than the internal pipeline working space, that's the whole point of it.)

[kmilos]

Btw, happy to leave this hanging/open until someone shows a compelling demo.

[aurelienpierre]

Ideally this is already and better addressed by the output ICC profile w/ a LUT

Actually, very few ICC profiles provide the A-to-B and B-to-A LUTs supposed to handle the perceptual colorimetric intent, so the ICC workflows "gamut maps" by simply clipping RGB to [0;1].

The only LUTs I know that will connect 2 spaces are the ACES IDT (from camera RGB to ACES P1), and we are not using these for obvious reasons. Even if we were to, that would go into input color profile module.

[kmilos]

The only LUTs I know that will connect 2 spaces are the ACES IDT

There are non-ACES related examples for e.g. HDR to SDR down-conversion, camera log to rec709, etc.:

https://xtremestuff.net/store/hdr-to-sdr-lut-pack/ https://www.bbc.co.uk/rd/blog/2020-06-lut-format-conversion-hdr-video-production https://fujifilm-x.com/en-gb/support/download/lut/

Some are probably not applicable for dt as they output the "narrow/legal" video signal range for e.g. rec709, but you get the gist... You could go from dt's scene-referred linear working space to an output space through some wider gamut proxy space using a 3rd party LUT that has some look baked in (to address precisely the lack of such ICC profiles), not just limit the module to "apply LUT in space foo".

There is of course an unnecessary conversion back to working and then again from working to output in colorout that could be addressed differently, but this is good enough to test if there is any benefit at all.

[github-actions[bot]]

This pull request has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[github-actions[bot]]

This pull reguest was closed because it has been inactive for 300 days since being marked as stale.