New IOP Color Equalizer

[TurboGit]

The Color Equalizer module started for darktable and updated in Ansel (not yet merged on master).

This has been adapted to darktable due to some API incompatibilities. I did a quick test and it seems to be working.

Please test and report issues.

To be done:

• [ ] do some testing to ensure this is working as expected
• [x] add it in module group : use it by default instead of color zone for the scene-referred group preset
• [x] add new module in POTFILES.in

[TurboGit]

I just found out that the sliders purple, turquoise and lime seems to be reversed for all tabs (saturation, hue and brightness).

[TurboGit]

@flannelhead : This is certainly an IOP you want to check. TIA.

[TurboGit]

I just found out that the sliders purple, turquoise and lime seems to be reversed for all tabs (saturation, hue and brightness).

No, my bad that's just that the color close gets slightly changed in the opposite direction and this can be seen in the curve.

Increasing Lime do decrease slightly the Orange and that's what I had in my test image (lot of Orange).

So all good on this side.

[jenshannoschwalm]

I tested today and indeed works nicely - both i am not a color maths guy at all. Also tested for performance and yes, using the highly optimized boxing filter gives a ~30% perf gain. No NaN problems so far.

[MStraeten]

several diffusion presets results in black areas if use guided filters is activated

[TurboGit]

several diffusion presets

Can you be more precise about the setting of the module? There is no preset in Color EQ 2.

[MStraeten]

e.g. use sharpen preset in diffuse or sharpen module mire1.cr2.xmp.txt

[TurboGit]

@MStraeten : Indeed, using "sharpness strong" in diffuse&sharpen module and ColorEQ2 can display big black square depending on the zoom level. Here a screen shot with only guide filter in ColorEQ2 activated:

[ralfbrown]

@jenshannoschwalm Note that the new box-filter code in this PR only does one iteration of box mean, while the calls to dt_box_mean which were replaced each did eight iterations....

[jenshannoschwalm]

ote that the new box-filter code in this PR only does one iteration of box mean, while the calls to dt_box_mean which were replaced each did eight iterations....

Yes. If there is no follow-up work in ansel we might look deeper into existing problems & performance. The walking box filter would definitely be faster ...

[jenshannoschwalm]

One interesting point for the guiding errors - it doesn't happen in darkroom with "high quality processing toggled on" - that's why i missed it while first testing. pinpoints to some roi misusage maybe.

[ralfbrown]

The walking box filter would definitely be faster ...

If you mean the new blur_2D_bspline in this PR, it's unlikely to be faster than dt_box_mean with one iteration (the number of iterations is a parameter). It does compute somewhat different values at the edges.

[Mark-64]

There's not supposed to be GUI interaction with the curve and the nodes, but only through the sliders, right? This is different from Tone Equalizer and Color Zones, maybe something to consider.

[TurboGit]

Exactly, no interaction with the graph. Note that this PR is not ready at the moment

[zisoft]

The slider handles look different (hollow triangles):

[jenshannoschwalm]

I have some significant progress here; two - i think so - major flaws in the current implementation are mostly due to the guiding artefacts. 1) the blurring radius must be depending on roi scale and b) the box blurring definitely requires the Kahan variants for stability.

Besides having to implement a 2ch kahan version there seems to be "something else wrong" in the box filter codes. Still investigating.

[ralfbrown]

Besides having to implement a 2ch kahan version there seems to be "something else wrong" in the box filter codes. Still investigating.

It occurred to me (independently, a few days ago) that if we made box_filters.c into a C++ file, we can use templates to clean up the code -- the "Nwide" functions become templates and eliminate the need for the "4wide" and "16wide" implementations. The public API can keep using C calling conventions, so none of the rest of the codebase would need changes.

[jenshannoschwalm]

that if we made box_filters.c into a C++ file, we can use templates

I hope by "we" you mean "you" :-)

[MStraeten]

build issue wit current master after merging cacheline improvements - fcbe7dd5b10d86cd20e7a56afe7ec6357814d350:

[ 81%] Building C object lib/darktable/plugins/CMakeFiles/colorequal.dir/introspection_colorequal.c.o
In file included from /Users/ms/src/darktable/build/lib/darktable/plugins/introspection_colorequal.c:209:
/Users/ms/src/darktable/src/iop/colorequal.c:843:17: fatal error: call to undeclared function 'dt_calloc_align'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  piece->data = dt_calloc_align(64, sizeof(dt_iop_colorequal_data_t));
                ^
/Users/ms/src/darktable/src/iop/colorequal.c:843:17: note: did you mean 'dt_calloc_aligned'?
/Users/ms/src/darktable/src/common/darktable.h:464:21: note: 'dt_calloc_aligned' declared here
static inline void* dt_calloc_aligned(const size_t size)
                    ^
1 error generated.

[ralfbrown]

For that one, I would suggest piece->data = dt_calloc1_align_type(dt_iop_colorequal_data_t);

[difrkaguilar]

The slider handles look different (hollow triangles):

I think it's a reminder of untouched sliders (defaults).

Similar to the hue in the color balance rgb module.

Ps: AP changed the triangles to circles in Ansel modules sliders similar to Lightroom mobile.

[jenshannoschwalm]

One more comment here, somehow the lens distortion contributes to guiding errors.

[KarlMagnusLarsson]

Hello all,

Thank you for the PR.

I have tested the PR merged with latest git master with the piece->data = dt_calloc1_align_type(dt_iop_colorequal_data_t); patch. I have also tried this PR as is without merging and got the same result, so I think it is related to PR code.

Issue: I get grey artifacts in darkroom main view, when color equalizer is active, if a certain set of preconditions are fulfilled:

• Color equalizer module is active, ON, default state (no equalizer curve changes = flat).
• Preferences -> processing -> always use littleCMS 2 = ticked, ON
• Diffuse & Sharpen ON, activated using sharpen demosaicing AA filter preset.
• Sharpening module is ON, active using default values.
• Filmic rgb module is OFF, deactivated.

It is quite a complex set, but I can trigger issue on and off with Filmic rgb as long as the other conditions are present. One can do the same thing with other conditions like Preferences -> processing -> always use littleCMS 2. If I turn littleCMS2 OFF and restart darktable, then the issue is NOT present (when Filmic RGB is on or off).

Example of issue (click on picture and zoom in on marked areas):

Steps to reproduce:

1. Build PR. Start from a clean cache and config
2. Preferences -> processing -> always use littleCMS 2 = ticked, ON
3. Import 0Y8A7917.CR2 (link below)
4. Go to darkroom
5. Activate color equalizer module, ON, (no equalizer curve changes = flat)
6. Activate Diffuse and Sharpen module, ON, with demosaicing AA filter preset
7. Activate sharpening module, ON, defaults
8. Deactivate filmic rgb module, OFF
9. Notice the grey artifacts in darkroom main view when filmic rgb is OFF, inactive. Picture above at 100% in darkroom.

Expected result: No grey artifacts in darkroom main view.

Counterexample, i.e., no issues: If I do not use color equalizer module (deactivated, OFF) or if I use git master without PR, then I can disable filmic rgb without issues for the same file and the same preconditions listed here.

RAW file example: Canon 5D mk IV, CR2: 0Y8A7917.CR2 https://drive.google.com/drive/folders/18o-BrOp6fnk7zTHa2y6U3z2bl5NQ4LWz?usp=sharing

My system is here:

• OS : Linux debian 6.1.0-17-amd64 1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux
• Linux - Distro : Debian 12.4
• Memory : 16 GB
• Graphics card : NVIDIA Corporation TU104GL [Quadro RTX 4000]
• Graphics driver : NVIDIA 525.147.05-4~deb12u1
• OpenCL installed : Yes, OpenCL 3.0 CUDA 12.0.151
• OpenCL activated : Yes (EDIT: but --disable-opencl does not help, same issue)
• Xorg : X11
• Desktop : Gnome 43.9
• GTK: 4.8.3+ds-2+deb12u1, 3.24.38-2~deb12u1
• gcc : (Debian 12.2.0-14) 12.2.0
• cflags :
• CMAKE_BUILD_TYPE : Release
• Intel® Core™ i7-3770K × 8
• motherboard: ASUSTeK COMPUTER INC. P8Z77-V

[jenshannoschwalm]

Did a lot of work on debugging the guiding errors. Problems in descending relevance order

1. interpolator feeding NaNs - can be avoided by disabling lens module - fixed via #16021
2. box filter - 2float kahan variant available after #16024
3. effect too much depending on roi scale

[jenshannoschwalm]

Just wanted to confirm that the guiding issues are gone after merged interpolator fixes.

[TurboGit]

On master:

colorequal.c:843:17: error: implicit declaration of function ‘dt_calloc_align’; did you mean ‘dt_calloc_aligned’? [-Werror=implicit-function-declaration]
  843 |   piece->data = dt_calloc_align(64, sizeof(dt_iop_colorequal_data_t));
      |                 ^~~~~~~~~~~~~~~
      |                 dt_calloc_aligned

[TurboGit]

I'll fix.

[TurboGit]

Just wanted to confirm that the guiding issues are gone after merged interpolator fixes.

I still see issue, less but when zooming I can still get big black squares.

[TurboGit]

Rebased on master with alloc fix to use new API.

[jenshannoschwalm]

colorequal.zip

Could you give this one a try? And if you have these artifacts - could you share an image/xmp?