Proposal for a linear + highlight roll-off tonemapping

Software darktable
6

too much desaturation in the shadows and midtones, this is how rgb-ratio works, it preserve the saturation in the highlights but I think it shouldn’t be used with a sigmoid/filmic/s-curve tone mapping.

image
image1440×720 20.6 KB

Gee… I wonder why the desaturation is so aggressive in mid-tones and highlights ? Maybe because there is no room for chroma left ? As in “pointy gamut”, whatever space you pick…

Notice the desaturation has nothing to do with the RGB ratios, it’s an additional processing step. The core algo is only meant to preserve those ratios.

It’s not easy to use color balance before filmic because the highlights recovery slider in filmic will change too much brightness and contrast of the image

Then learn. It’s easy, I don’t know what you are doing, but you must be doing it wrong.

for example it should be applied before or after the tone mapping?

It should be applied through the tone mapping, tone and gamut mapping are the 2 sides of the same problem. Ideally, the tone mapping would probe the export space to see where the color would end, and remap them to the closest in-gamut point using chroma and saturation strategies using the chromaticity before tone mapping.

Unfortunately, since darktable pipeline allows shit between filmic and output color profile for display-referred compatibility, that’s not possible yet, so the #1 priority for now is to finish re-writting all the display-referred modules that cloag the [filmic ; output profile] part of the pipe.

Focusing on what filmic does or doesn’t is counter-productive. It’s full of bad trade-offs that are made necessary by the mandatory support of legacy display-referred. You need to think the pipeline as a whole.

Wanna do something productive ? Rewrite local contrast, contrast equalizer, color zones, etc. in Ych. Until that is done, filmic is stale. I don’t put polish on broken car.

4 Likes
7

BTW @age, I liked your older PlayRaws more than your recent ones. Something changed; i.e., they feel too saturated. Admitted, my screen is definitely off, but it is the same one I used to view your other images.

1 Like
8

I wonder if people not familiar with filmic get confused with the whites slider expecting it to act as a highlights recovery slider. It behaves very differently, affecting the dynamic range and all tones. I wonder if this could be made clearer in the labelling if there is space. I tend to do most of these adjustments in tone equaliser and leave filmic alone unless the picture has extreme dynamic range.

1 Like
9

at OP. ‘filmic highlight recovery’… Do you mean the ‘recovery’ tab? Because AFAIK that is only for when stuff is clipped. As long as you can put the white-slider low to bring the highlights ‘in range’ you don’t need that. It’s only if you’re trying to find a balance.

Turn the ‘latitude’ slider to make that ‘highlight’ and ‘shadow’ part shorter, that means that less is desaturated.

I’d like to play with the pictures, but you didn’t post any RAW files to try.

Having said that: I think everybody would agree that filmic is not always the answer for everything, and it can have ‘a look’ to its down which you might not like. So if you get your result a different way, that’s always OK.

10

I think the two photos above come from playraw posts…I am sure I have seen both before…

11

Nothing wrong, moving the white relative exposure slider will change the values under middle gray.

Could you define in-gamut point?

There are negative rgb values that are really out of gamut colors, filmic push colors to be OOG with the midtone saturation slider.

There are rgb values > 1 , these are in-gamut but just too bright to be displayed.

We could decide how much saturation vs luminance preserve keeping the hue constant

This is a good paper about recover information above 1 after tone mapping

https://www.researchgate.net/publication/254311640_A_Simple_Algorithm_for_Managing_Color_in_Global_Tone_Reproduction

This could be easily extended to implement chroma clipping , basically detect the rgb pixels where at least one value is negative and desaturate it until it becomes 0.
original
original

original + saturation
original-sat

chroma clipping
original-sat-gamutclipping

chroma clipping + lch hue blend
original-sat-gamutclipping-hue

original.pfi (15.0 KB)

This is the g’mic code for the chroma clipping, it’s really fast
-fill i=i;lum=(i0+i1+i2)/3;min=min(i0,i1,i2);f=(0.00001-lum)/(min-lum);f=if(f<0,0,f);f=if(f>1,1,f);i=if(min<0,(i-lum)*f+lum,i);

For the values above 1.0 (not really OOG) the film_like clip is another good option because it reduces and preserve some saturation

before

DSCF9668clipped
DSCF9668clipped1082×720 145 KB

after
DSCF9668gamut-clipped
DSCF9668gamut-clipped1082×720 142 KB

DSCF9668.pfi (21.3 KB)

13

yes, 50 code value in lab color space is middle gray, values below middle gray are increased when the white relative exposure slidere is moved to the right

14

Right, I now understand what you say.

15

Moving the white relative exposure moves the right bound of the dynamic range which encompasses the wole luminance range. Who said “white” was anything like an highlights compression ? White, black, those are 2 bounds. You set them. Between them is the dynamic range. We handle it as a whole, because it is.

Don’t use that shit, it’s easy. You have better ways to increase saturation sooner in the pipe.

Whatever coordinate inside the gamut boundaries that minimizes the distance with the original color.

Using which color model ?

This is not hue-linear.

1 Like
16

The trouble is that that ‘shit’ is the default. When someone starts using a software as complex as darktable, a useful piece of advice is ‘go with the defaults, only tweak stuff you understand’. So, users will either leave that slider alone, or, even worse, will think they can yank it around. Shipping an application with a default setting that the principal developer of a module considers ‘shit’ is quite weird.

And a question: is it possible to set mid-tone saturation boost to 0, and save a preset, without that also saving the current black & white levels, which are, if I understand correctly, normally automatically set based on exposure (e.g. exposure compensation set in the camera) when the module is initialised?

6 Likes
17

Very counter-intuitive, in fact

18

You have to thank the worshippers of the OOC JPEG look for that. That default is to make them shut up. If I set the default to 0, I will get all the “filmic desaturates images” all over again. If I put a notice about needing to tweak saturation manually somewhere else in the soft, I will get other messages in tune with “why do I need to manually adjust saturation” ? (Answer : changing luminance at same chromaticity might not produce the result you expect).

There is no solution except sending some range of the user base to hell and stopping to listen.

Wanna go the manual way ? Set midtones saturation to 0 and carry on editing.
Wanna OOC JPEG-ish look ? Defaults should cover it fairly.
Wanna both ? Go annoy someone else. I’m tired of that shit.

Apparently, OOC JPEG is the Truth®, so what do I know…

That’s because you are the ones sitting on your arse, commenting and having opinions, and not the one taking shit from the internet after 8h of coding.

4 Likes
19

Oh you will love this one then… Scene referred, display referred, and the Colour Science of Canon/Fujitsu/Nikon/etc. in Darktable (filmic-rgb module in particular) - #6 by OK1

You thought “intuitive” was bad now you can have “photo intelligence”

2 Likes
20

I understand your irritation. How about Set filmicrgb default mid-tones saturation level in preferences · Issue #9183 · darktable-org/darktable · GitHub ?

7 Likes
21

Why do you need a preference when you can create a simple automated filmic preset that applies to all your images ?
With a bunch of custom presets, you can get a nice default look tweaked to your own style and taste.

22

Please could we have a list of such defaults so that the non-ooc-worshippers can set up alternative presets, and I’ll update the manual.

3 Likes
23

Because

That is, if you create a preset, then the filmic initialisation step, which would normally set the black and white levels based on the in-camera exposure compensation, is skipped. This is also described in the alternatives section of the feature request.

2 Likes
24

The other down-side to presets is that they can freeze other module parameters in place, that might be improved/enhanced in future releases. For example, if I created a filmic preset now in v3.4.1 that preset would hard-code the color science to v4 (2020). If I then use the same preset after v3.6 is released, it wouldn’t get automatically updated to v5 (2021).

The ability to override individual parameters in presets but leave the others unchanged would be very useful (though I don’t know an easy way to go about such a thing).

Right now the alternative, if you compile your own darktable, is to manually change the defaults before you compile it :slight_smile:

3 Likes
25

Indeed those are limitations of presets, it’s an exercise to have those updated with each release, but at least they can be used to do quick developments.
As you say, the best between current presets and defaults, would be to be able to change default values based on some EXIF infos like current presets.
Doing this would probably require a lot of changes in module default logic and in the ui.
But that could be worth the effort, instead of adding specific preferences for all modules.

26

Yes, for each module, in the presets menu, I would love to see the options ‘system defaults’, ‘user defaults’ and ‘save current as user defaults’

System defaults would be as shipped by Devs, user defaults would be as saved by users. The only way to really do this now is to save preset for every module, then save that as a style. If you happen to change your presets, you must overwrite the style all over again. Not the end of the world, but would be simpler to save user defaults that are there automatically, and not need to apply a style. As ever, I do not know the complexity or viability of coding such a task. But if others think thi sis a good idea I can always open it as an issue in Github. You never know…