move lut 3d above filmic rgb

[blitzgneisserin]

Hi,

I would like to suggest an "enhancement" and create a pull request:

I used the module lut 3d a lot recently with film simulations and I find it works best if it is applied AFTER filmic. If it is before filmic, it creates undesired color artifacts and/or destroys the highlights.

I have already created an own version of darktable where this is changed. You can check it out here:
https://github.com/blitzgneisserin/darktable

This is what I changed in the code:

blitzgneisserin@22e7cdd

It seems to be functional.

Here are 2 screenshots - in the first lut 3d before filmic and in the second lut 3d after filmic.

Since I have not yet contributed to the darktable code, I thought I ask here first.

Best

Anna

[MStraeten]

this depends on the used LUT - as frequently discussed for a long time. (#2128
Your case is just one usecase - changing the look of an image in a low dynamic range. The placement before filmic is the more generic solution - valid also for LUTs dealing with a high dynamic range input.

BTW: latest request to change module order: #9844

[johnny-bit]

One thing I might add is I think that the suggestion to move LUT3D module should be mentioned in usermanual so that users using LDR LUTs could use them after filmic and those with HDR LUTs could use them instead of filmic.

[blitzgneisserin]

well then, shouldn't an own module order for ldr resp hdr be created?
Which use case is more common in practice? The placement before filmic is certainly not valid (also) for LDR.
Edit: nevermind, ldr order= legacy order I guess.

[MStraeten]

Up to filmic we are in a hdr pipe since raw files usually uses more then 8bit to encode image information. So it make sense to have LUTs in the scene referred part of the pipe as well as in the display referred part. This doesn’t depend on the image, this depends in the prerequisite of the LUT.
For a low dynamic range image (e.g. s/c-log encoded stuff) a lut „recovering“ the whole dynamic range needs to be in the scene referred part of the pipe.

[blitzgneisserin]

I know it's the LUT, I expressed myself incorrectly.

[blitzgneisserin]

Well, I am not the greatest expert here but my opinion is that in most cases there is no logic behind placing lut 3 before filmic, no matter if it's a scene referred or a display referred workflow. One usually applies an effect to a photo where contrast, white balance exposure etc are fixed. But I am just expressing an opinion.

I mean I believe you if you say that there are no artifacts if the lut is different, but I see no logic.

[phweyland]

Some thoughts.
color grading
If the LUT has been built on a gamma RGB like rec709, it seems obvious that filmic placed after lut3d will break the intended look flattening the highlights (at least).
I've not checked again for while, but I think that gamma RGB LUTs are still the most common ones.
If the LUT colorspace is linear, it's probable that the filmic compression has been taken in account (but which filmic curve?). Of course depending on filmic settings the result may not be the expected one.
log to linear
That's a technical LUT. I've never found (maybe I should search again) such raw file to make some test. Not sure that dt is ready for that but in that case lut3d should be just after demosaic or something like that (before input color profile).
log to gamma RGB
I think they may not be used with dt. Normally the goal of these LUTs is to view raw footage giving a quick view of the final result.

As Anna, I think the more natural default place is just after filmic (and before output color space).

EDIT: other detail: unlike the scene referred modules, lut3d clips everything to [0,1].

[johnny-bit]

@phweyland - you're the one who made the module, aren't you? If so - @blitzgneisserin i think you have "blessing" to open up a PR to "fix" this FR :)

[blitzgneisserin]

@phweyland - you're the one who made the module, aren't you? If so - @blitzgneisserin i think you have "blessing" to open up a PR to "fix" this FR :)

oh wow, really guys? green light fora PR?

[johnny-bit]

Certainly nobody's stopping you. I bet there will be discussion on the pr before it gets merged though.

[blitzgneisserin]

yea well, I think the question is still: where is the optimal place of this module? Is it right after filmic, or right before output color profile, or somewhere inbetween? Although, from my practical experience: it does not really matter. In theory, for most practical use cases, it should be right before output color profile?

[johnny-bit]

It's more of a question of what's between filmic and colorout. In an ideal world there would be nothing between filmic and colorout since filmic gamut mapping highly depends on output color space and then luts do depend on input color space...

[aurelienpierre]

I used the module lut 3d a lot recently with film simulations and I find it works best if it is applied AFTER filmic. If it is before filmic, it creates undesired color artifacts and/or destroys the highlights.

No, it doesn't.

LUTs work in bounded RGB, between 0 and 1. But they still expect vanilla RGB with no contrast tone curve, possibly with a gamma on. What happens if you work in the scene-referred workflow is the exposure module pushes RGB outside of [0; 1], for which the LUT is undefined, and you later apply the LUT on top of that.

What you need to do is push the exposure module after the LUT, and leave filmic at the end where it should go.

The pipeline is :

RAW -> white balance -> input profile -> color calibration -> LUT -> exposure -> filmic -> output profile.

If your image is really underexposed, you may do :

RAW -> white balance -> exposure 1 -> input profile -> color calibration -> LUT -> exposure 2 -> filmic -> output profile.

Exposure 1 will aim at using most of the [ 0 ; 1 ] range, while Exposure 2 will set the overall brightness.

[phweyland]

. But they still expect vanilla RGB with no contrast tone curve, possibly with a gamma on.

This is not sure. And surely depends on the LUT.

What happens if you work in the scene-referred workflow is the exposure module pushes RGB outside of [0; 1], for which the LUT is undefined, and you later apply the LUT on top of that.

Agreed. To use LUT on on RGB values outside [0,1] cannot work properly.

RAW -> white balance -> input profile -> color calibration -> LUT -> exposure -> filmic -> output profile.

And filmic still applies a tone curve on top of the LUT, which is not expected.

[blitzgneisserin]

The photo is more colorful if I do it the way Aurélien suggested. Is that how it is supposed to be?

[aurelienpierre]

The photo is more colorful if I do it the way Aurélien suggested. Is that how it is supposed to be?

I don't know what your LUT does in the first place, so I can't comment.

RAW -> white balance -> input profile -> color calibration -> LUT -> exposure -> filmic -> output profile.

And filmic still applies a tone curve on top of the LUT, which is not expected.

It all depends if your LUT is meant as a setting/grading shortcut, or as an output profile to simulate printing on film (which is only a concern for movies that will be printed and displayed in theaters on positive film). So far, I see mostly LUT aimed at color grading, in which case they should expect neutral RGB (linear or log or gamma encoded, but nothing contrasty). My main concern is the LUT may contain color shift + contrast curve built-in at once.

[blitzgneisserin]

As you can see, it's one of Pat David's LUTs from the RT Film Simulation Collection.
I think it expects a neutral, moderately low contrast/chroma photo with correct exposure, correct (lower) contrast and correct white balance, probably non-linear.

I made several tests with the LUTs from this collection and the result does not seem to look correct: if lut is under exposure, there is a problem with the blacks/darks (they are too dark). So it's kind of the opposite of lut between filmic and exposure.

One should test this with other LUTs as well.

Well, I don't know. Aurélien's idea is certainly interesting. Maybe the darks are supposed to look that way.

LUT under exposure:

LUT after filmic:

no LUT:

[johnny-bit]

Seems like it's highly LUT-dependend and needs in-depth explaination in manual ;) or in deep dwelling article explaining various lutcases ;)

[phweyland]

I see mostly LUT aimed at color grading, in which case they should expect neutral RGB (linear or log or gamma encoded, but nothing contrasty

It's all a question of appreciation. But there is nothing here which explains or tell the LUT should be applied before filmic.
A color grading LUT is intended to provide a given look. This happen at the end of dev process, not in the middle.
In any case the creator of the LUT cannot know which tone curve will be applied by filmic.
Of course you can still get pleasant image with the LUT applied before filmic, but it will unlikely give exactly the intend of his creator.
Without talking about the LUT constraints about clipping, especially inside the scene referred portion of the pipe.

RAW -> white balance -> input profile -> color calibration -> LUT -> exposure -> filmic -> output profile.
RAW -> white balance -> exposure 1 -> input profile -> color calibration -> LUT -> exposure 2 -> filmic -> output profile.

It's a bit like how to make complicated when it can be simple.

For me it's clear that the right default order should be filmic -> LUT, just because any strong transform afterwards just break the intended look (in case of color grading).
If I'm wrong, I would be curious to see a color grading LUT which expects a filmic tone curve applied afterwards. But which curve exactly ?
Would you have any example ?

My main concern is the LUT may contain color shift + contrast curve built-in at once.

I think this is common. In that case filmic should still deal with the dynamic compression if necessary (which should be done before applying the LUT).

[grubernd]

3D LUT is definitely in the wrong place of the pipeline.

The LUTs I know of can never exceed any input or output limits.
Which is the total opposite of how scene referred is meant to work.

No matter how you put it, you need filmic to make sense of the data that you can feed through a LUT.

Or you can tweak the "raw" sensor behaviour with it, but then any subsequent tool will pick up those changes.

[jakubfi]

Also proposed in #3108

[johnny-bit]

Welp, #9914 got merged so I think it's only fair to close this one...