Remaining ColorEq issues

[s7habo]

Describe the bug

I don't know if it's because of the recent changes in the module, or I've found a specific example, but the brightness again seems to be very much dependent on the saturation.

In this example I want to darken the green:

If I do this with the guided filter turned on, I get this result:

Note that a very large area was simply not taken into account. It is not much better if you switch off the guided filter:

The mask also clearly shows that saturation (and brightness?) oriented selection:

The result looks much better if you correct the saturation beforehand with the color balance RGB module. Note that I have adjusted the saturation here so that I have saturated the highlights the most, the midtones much less and I even had to reduce the saturation for shadows. Then you get the result as I would expect:

In this way, the result comes pretty close to the result if you mask the green with the exposure module and darken it:

EDIT: Just as a thought, could it be that the brightness function depends on the saturation (purity) and on the original brightness of the area? This means that not only the saturated areas, but also the darker areas are affected much more than the brighter ones?

Steps to reproduce

1. Lighten or darken a color range with different saturation/brightness in color equalizer. Depending on the saturation/brightness, the range is lightened/darkened differently, depending on the original brightness and/or saturation. The darker and more saturated areas are affected more than lighter and less saturated areas.

Expected behavior

The affected area should be lightened/darkened evenly regardless of the original brightness/saturation of the area.

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

self compiled

darktable version

4.7.0+611~g76e4f8a6c

What OS are you using?

Linux

What is the version of your OS?

Ubuntu Studio 22.04

Describe your system?

KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.19.0-1028-lowlatency (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz Memory: 31.3 GiB of RAM

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2 Driver: 535.154.05

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[jenshannoschwalm]

I guess you are aware of the analyse radius button? You will have false colors for parts that can be changed in bright read and that wont be changed in dark blue ...

The color maths including the guided filter have not changed for "some time" - still looking for examples where it fails as in this image...

[s7habo]

I guess you are aware of the analyse radius button? You will have false colors for parts that can be changed in bright read and that wont be changed in dark blue ...

Yes, I am aware of that. For the example above, it looks like this:

Moving the slider does not cause any change and has no effect on the result, regardless of whether the guided filter is switched on or off.

[jenshannoschwalm]

Moving the slider does not cause any change and has no effect on the result, regardless of whether the guided filter is switched on or off.

Right. Right now it just displays the weighing mask. We still have not found a "perfect" solution as we clearly see here, often in the green tones ...

[s7habo]

It works well for saturation. However, there is a big difference between switching the guided filter on and off.

GF off:

GF on:

[s7habo]

By the way, the raw file above is from https://www.signatureedits.com/free-raw-photos/

Simply scroll down until it appears or enter "DSC02363" in the search field and then it will be selected and can be downloaded

[SoupyGit]

Yes while recent changes improved the result a lot it is still not perfect, with light colours and in particular green.

Saturation:

Brightness:

[jenshannoschwalm]

@s7habo i certainly have the described problem "on radar".

Atm we have

1. dark areas being favoured over bright parts regarding "guided correction". (The earlier issue was "dark areas not corrected :-) The reason for that is known - not sure yet how to handle that "the best way"
2. greens being more problematic than other hues. That issue is still not understood.

I would love to collect all known issues with this module before starting a new iteration of work on module maths. Are you - or is anybody else - aware of other issues?

[s7habo]

Are you - or is anybody else - aware of other issues?

Yes, there is one that immediately comes to mind.

With smooth transitions, guided filter with brightness and saturation function produces banding:

With GF:

Without GF:

Hue function works correctly:

I am currently testing the module in more detail. If I notice anything, I'll let you know straight away.

[jenshannoschwalm]

Hi, #16363 will fix most issues as far as I can oversee it - tested on many images you provided and others. Let's keep track of problems here after that gets merged. It should work much better for all colorful areas, dark and bright.

[jenshannoschwalm]

Beside whatever issues you'll report, I am working on suppression of halos and increased chroma noise.

[s7habo]

Weighing function is now super!

The problems with bending are also gone. :clap: :+1:

The only thing that is still weak is the problem with green:

But what works very well now is the analysis radius and the guided filter. :rocket:

[s7habo]

I have now tried a lot of photos, and now I'm not sure if it's because of green.

When I compare the masks between the saturation and brightness functions, two things stand out:

1. brightness is much weaker than saturation.
2. saturation seemed to work more linear (flatter) and brightness logarithmic (more contrasty)

Here are a few examples for comparison.

Saturation mask:

Brightness mask:

Org:

Saturation mask:

Org:

Saturation mask:

Brightness mask:

[jenshannoschwalm]

I would like to emphasize, the 'mask" you see is not a mask, it's the result of what the module has been doing.

About the stronger effect on brightness, that could be changed without problems. There are some remaining halos and minor problems with chroma noise, I would like to sort that out before extending brightness correction range.

[s7habo]

In any case, thank you very much for your efforts!

Once this little rest of the problems are cleaned up, this will be a new milestone in image processing with darktable.

[SoupyGit]

Saturation is now perfect!

And brightness has improved:

now I'm not sure if it's because of green.

Yes it seems to me now that lightness is the main determining factor. The colours that go to black quickest are those that appear darkest to begin with (red > blue). Of course I am of no help in determining the cause. Great work again @jenshannoschwalm!

[jenshannoschwalm]

@s7habo i have renamed the title of this issue to keep attention on this, ok?

@s7habo @SoupyGit i think i don't get "what exactly is the brightness issue" :-)

The module works in UC22-HSB space so the brightness - and also it's correction - is not linear, the visualizing mask shows changes in linear space though. Do you/we want more range for brightness correction? Or elaborate please ...

[s7habo]

i have renamed the title of this issue to keep attention on this, ok?

Yes, thanks!

Or elaborate please ...

Brightness function seems to follow a kind of "s" curve. This means that in an area with the same color but different brightness, the contrast is increased.

To illustrate, the brightness function follows...

... a curve like this:

If this were a linear function, you would have something like this:

And that's what you would have expected as a user.

And because that's not the case...

Do you/we want more range for brightness correction?

...the answer is definitely yes, but how much depends on how/if this relates to increasing the contrast.

[jenshannoschwalm]

Aah, got it. Indeed the brightness correction follows the s-shaped weighing curve in a slightly different way atm, you need more saturation to have any change in brightness. Knowing that and working on it.

[s7habo]

Indeed the brightness correction follows the s-shaped weighing curve in a slightly different way atm, you need more saturation to have any change in brightness. Knowing that and working on it.

By the way, what just came to my mind, if you are already working on the solution, this kind of contrast that we now have as a "problem" could be very useful in some situations. How would it be - if it turns out to be possible in your investigation - to control this dynamically?

Like a kind of additional slider for brightness function with which you can go from "brightness with strong dependence on saturation" to "brightness with low dependence on saturation", with which the contrast becomes stronger or weaker accordingly?

Just as an idea. :grinning:

[jenshannoschwalm]

Yes that could be done. I take your word about usability VS user interface here. So make up your mind, yes or no :-)

[s7habo]

So make up your mind, yes or no :-)

I say yes and am immediately on the hunt for a good example. :point_up:

[s7habo]

Here is one:

Before:

After:

Visualization:

And now I know why I thought of that. We had the discussion here about Fuji color chrome effect:

https://discuss.pixls.us/t/what-is-color-chrome-effect-and-how-to-achieve-it/18760/6?u=s7habo

Roughly speaking, this effect darkens the intense color areas to create an additional contrast that is lost with strong saturation.

[s7habo]

Here are two more examples:

Note how the texture of the leaves is enhanced here:

Before:

After:

Here the car gets nice contrasts:

Before:

After:

[s7habo]

I have one more idea that I would like to get rid of and then I'll stop because it belongs in the feature request section:

If you can have the same weight slider by saturation also for the saturation function itself (stronger saturation for already saturated colors vs. even saturation) you would also have what "vibrance" function does in color balance rgb module.

This would give both saturation and brightness functions an additional - let's call it - "vibrance" slider. I can imagine a lot of possible uses for this. But we can talk about that later.

[s7habo]

Excellent work @jenshannoschwalm ! With your latest contribution, the color equalizer is slowly becoming the Swiss army knife for dealing with colors. :)

Here's an example right away:

In this photo...

...we wanted to darken the skin. With a very low effect radius, however, the skin looks very rough:

To counter this, we now increase the effect radius. The skin now looks nice, but the fur on the hat has lost its local contrast:

If we now also increase saturation threshold to increase saturation restriction, the fur of the cap regains its local contrast because it is excluded from the darkening. Face has more contrast and the neck is cleanly separated from the environment, which also prevents haloing of guided filter. This is really a very nice additional control:

The new saturation threshold function is a huge improvement in my opinion!

I have two questions in this regard.

1. The slider is limited to -/+ 10% Can the radius of action be increased to -/+30% or more? Or one leave it as it is, but offer the possibility to enter higher (or lower) values via keyboard if necessary.
2. The transitions between saturated and non-saturated areas are a bit harsh. Could this also be controlled somehow with the guided filter?

[TurboGit]

The new saturation threshold function is a huge improvement in my opinion!

In this specific example I suppose that one could have been used a parametric mask on saturation.

[s7habo]

In this specific example I suppose that one could have been used a parametric mask on saturation.

Unfortunately not. That was the first thing I tried to compare. This is the best I could achieve with the parametric mask based on saturation:

If you want to exclude the fur, you lose the area around the neck:

And this is what the visualization of the saturation threshold in color equalizer looks like (red is what is affected):

And this is the visualization of the effect radius. This gives the result a natural contrast:

Of course, you could also achieve this with additional masking. But if you have immediate control with a slider, that's actually great.

But I have to test it more intensively to see how it behaves with other examples.

[jenshannoschwalm]

I have two questions in this regard.

1. The slider is limited to -/+ 10% Can the radius of action be increased to -/+30% or more? Or one leave it as it is, but offer the possibility to enter higher (or lower) values via keyboard if necessary.

2. The transitions between saturated and non-saturated areas are a bit harsh. Could this also be controlled somehow with the guided filter?

Ad 1. Yes, although the percent value is not technically correct. With current code we can set the saturation threshold to values between 0 and ~25% (at 0 we have the default) I just thought this range would be sufficient :-) Let me know after further testing if this should be expanded, i wouldn't expect any problems from changing this.

Ad 2. Principally yes. The current weighing function is pretty steep around the threshold giving a good on/off effect. We could do that smoother of course but we reduce control of "colors should not bleed into achromatic areas" which was pretty bad in the original code. That would require an additional slider again ... something i would not like too much.

So, yes - both things could be done without big problems. As you compile yourself you might try this:

Ad 1: See line 102, change this to

  float threshold;          // $MIN: -0.1 $MAX: 0.2 $DEFAULT: 0.0 $DESCRIPTION: "saturation threshold"

Ad 2: Line 356, change the -60.0 to -30.0 for a smoother transition.

    satweights[i+SATSIZE] = (float)(1.0 / (1.0 + exp(-60.0 * val)));

[s7habo]

So, yes - both things could be done without big problems. As you compile yourself you might try this:

Unfortunately, I'm not that good. I only compile master version according to idiot-proof instructions for Ubuntu which I just blindly follow. :)

As for the first point, I'm already pretty sure that the range can be extended.

As for the second point, if it requires a new slider, I will also say that we don't need to overdo it. It makes sense to wait and see.

[s7habo]

And now, after the https://github.com/darktable-org/darktable/pull/16415 :

"Barbie doll" (saturation threshold -10%) vs. natural saturation gradient in the face (saturation threshold + 18%):

Uniform (saturation threshold -10%) vs. "Kodachrome 64" saturation distribution (saturation threshold + 18%):

I can well imagine that analog film fanatics will now be very happy and a lot of presets will be circulating in the forums when the new darktable version comes out. :)

And for me it's now time for extensive testing.

Thank you @jenshannoschwalm !