DT 4.3.0 Hierarchically higher modules ignore/disable rastermask if created with detail treshold mask.

[s7habo]

Describe the bug

If you have created detail threshold mask in one module (let's say for example exposure module) and reuse it in hierarchically higher module as raster mask (for example in contrast equalizer) in next hierarchically higher module (for example color balance rgb) it will be ignored/disabled.

If you then switch off the raster mask in the module where the raster mask was used (in this case contrast equalizer) and switch it on again, it will also be taken into account by the higher module (color balance rgb).

Steps to reproduce

1. Create a mask with the help of detail threshold slider and apply it (exposure module here):

2. Make a change in hierarchically higher module (contrast equalizer) and apply the raster mask based on detail threshold mask made by exposure module :

3. Go to a hierarchically higher module (color balance rgb) and make a change there. The raster mask applied to the hierarchically lower module is ignored/disabled.

4. Go back to the module that used the raster mask (contrast equalizer) . Although it is shown as applied in the menu, it is not active:

5. Deactivate it and activate it again. Now it is applied again.

6. This time it will be active also in hierarchically higher module:

7. It can be - but this is not always the case - if you then make another change in this module (color balance rgb), that again the raster mask is switched off. Then you have to repeat steps 4 to 6. In the following video that was the case:

https://user-images.githubusercontent.com/38165484/233368904-3291e672-eece-4739-a722-3b53e6c9c505.mp4

Here is also the output of the terminal with "darktable -d all" when this video was made:

darktable_raster_mask.txt

Important note:

This behavior does not always happen. However, I could not determine under what circumstances this happened.

Raw file I used for the demonstration is from this post https://discuss.pixls.us/t/gamut-issues-should-i-be-worried/36719/1

Expected behavior

When raster mask is used by one module, it should not be affected by other modules that are used after it.

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you install darktable from?

darktable.org

darktable version

4.3.0+1872~gd2c7145fd

What OS are you using?

Linux

What is the version of your OS?

Ubuntu Studio 22.04

Describe your system?

Operating System: Ubuntu Studio 22.04 KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-70-lowlatency (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

NVIDIA GeForce GTX 1070/PCIe/SSE2

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

No response

[s7habo]

Here is also sidecar file:

ER6_2855.CR3.xmp.zip

[jenshannoschwalm]

Thanks :-) Before getting into this:

1. Are you sure this worked correctly with 4.0 / 4.2?
2. Can you reproduce with --disable-pipecache ?
3. BTW, in most cases -d common will be far enough :-)

[s7habo]

Are you sure this worked correctly with 4.0 / 4.2?`

I think I experienced this at times with 4.0 / 4.2

Can you reproduce with --disable-pipecache ?

No. I just tried 4-5 times and the problem does not seem to appear.

Here is the terminal output: darktable_raster_mask_d_common_disable_pipecache.txt

After that I tried it again without "--disable-pipecache" and had the problem again: Output:

darktable_raster_mask_d_common.txt

What I also noticed - but this is not necessarily related to this problem - is that the results are not always displayed in the thumbnails in ligttable when the thumbnails have a certain size. With smaller thumbnails you don't see the results (from size 5 and above):

From size 4 it looks then like in the darkroom:

In this case it does not matter if with or without -disable pipecache.

[jenshannoschwalm]

No. I just tried 4-5 times and the problem does not seem to appear.

Good to hear. So likely still some cache issue.

[jenshannoschwalm]

What I also noticed - but this is not necessarily related to this problem

Not related but - an issue :-)

[s7habo]

Thank you! The second issue is solved, but the first is still there. I have now tested it with 4.3.0+1917~gba44a8d60 The same raw file as above

darktable_raster_mask_d_common2.txt

[jenshannoschwalm]

@s7habo i think i simply don't get the issue exactly. Have not used raster masks much so likely i don't look at it "the right way". Maybe you could explain again in more detail?

[s7habo]

First of all, thank you @jenshannoschwalm for your effort!

To better explain what the problem is, I made a short video :

https://youtu.be/wEChTZ9HAKc

[jenshannoschwalm]

Whow. Understood what you mean, not understood what happens. The rastermask code is something I haven't worked on, so it might take a bit more time.

[s7habo]

What I have just noticed is that this problem only affects the display of the result on the screen, not the internal processing.

When this phenomenon occurs and I zoom out and zoom in, the display is "corrected". See the end of the video:

https://user-images.githubusercontent.com/38165484/233797743-fdae363a-3382-4621-b054-45329571d37b.mp4

[jenshannoschwalm]

Can you reproduce: After going to lighttable and back again to darkroom, here the issue is also not persisting, seems to be the same as "is ok" in your late video ???

[s7habo]

After going to lighttable and back again to darkroom, here the issue is also not persisting, seems to be the same as "is ok" in your late video ???

Yes, the effect is the same as when I zoom in and out.

So in summary, effect is gone when I either go into lighttable and then back into darkroom, or when I zoom in and out in darkroom - when I practically "refresh" the display on the canvas in darkroom after the problem appeared.

But if I go back into color balance module and move any slider, the problem reappears (raster mask is turned off again). Then I have to repeat the steps above to get the correct display again.

[s7habo]

I just realized, it gets weirder. :laughing:

In this video below, I zoom in and out to see if the problem reappears. And indeed, it does:

https://user-images.githubusercontent.com/38165484/234074734-8008198f-2bc6-4a02-b099-96eefd4a46ba.mp4

[jenshannoschwalm]

@s7habo i will track this down - promised! It will likely need some more days, this part of the pixelpipe is not trivial :-) Plus - there are no debugging tools for this (yet) - But: fixing other issues while checking this :-)

[s7habo]

Thanks! I'll keep experimenting and let you know if I find anything.

[s7habo]

I have just installed master and the problem I still there :confused:

[s7habo]

DT 4.3.0+2027~g2b3d5ec05:

lighttable:

darkroom:

[jenshannoschwalm]

I see :-( Good thing here is: we see that on some reason the raster mask is lost. I think i did a slightly different test setting, i didn't duplicate the exposure module and for me that made the difference.

[s7habo]

i didn't duplicate the exposure module and for me that made the difference.

I tried that too, using only the first instance for mask. Unfortunately it does not matter. I also tried to use different modules both for creating the mask and then for raster mask later in the pixelpipe. The problem appears again and again. This is a very tricky bug.

In any case, one thing is for sure - it is not bound to a specific module.

The scheme is always the same - create the mask, use it later as a raster mask and higher in the pixelpipe it is ignored. But also not always. I have not noticed any regularity under which circumstances it is ignored/switched off. :confused:

[s7habo]

By the way, it is also not tied to detail treshold. No matter on which way the mask is created (detail/parametric/drawn), if it is later used as a raster mask these problems appear.

The rats from the pixelpipe seem to prefer it.

[jenshannoschwalm]

I tried that too, using only the first instance for mask.

1. So just one exposure module ? For me this seems to make the difference. Couldn't reproduce if the mask was generated in that single module.
2. the -d pipe logs show the raster mask is lost in the reproducer

[s7habo]

So just one exposure module ?

yes

the -d pipe logs show the raster mask is lost in the reproducer

I have started darktable with this option (-d pipe) and there seems to be dropouts regarding rastermask. I made a short video about this...

https://youtu.be/2VX2QJmx820

...and here is also the log file that was created during the processing that can be seen in the video:

darktable_raster_mask_minus_d_pipe.txt

I emphasize again, this does not always happen. I had to make one or two attempts before the problem appeared.

[jenshannoschwalm]

@s7habo There has been another PR #14432 that should fix all remaining (not easy to trigger) issue related to detail, raster masks and history selecting.

I would appreciate it a lot, if you could test in depth after that got merged.

[s7habo]

@jenshannoschwalm , I was able to reproduce the bugs that were mentioned in https://github.com/darktable-org/darktable/issues/14393 and https://github.com/darktable-org/darktable/pull/14432.

The issues only affect the raster mask regardless of which mask was used as the basis for creating the raster mask. Please see the details in the video:

https://youtu.be/ijHPIvluXws

Here is the output of the terminal with -d common option accompanying the video:

darktable_raster_mask_two_issues.txt

[jenshannoschwalm]

Yes. I also spent some time on this, at least some issues due to incorrectly calculated masks should be gone. One question, how are opencl settings? "Very fast or default"?

[s7habo]

One question, how are opencl settings? "Very fast or default"?

Very fast GPU

[jenshannoschwalm]

Ok some issues fixed in the latest pr. But i have found an extremely easy to reproduce situation showing something really wrong with blending and raster masks. BTW this is not related to pixelpipe cache or opencl on/off, can be reproduced whatever you are using here.

Is a simple shape mask to control the first exposure module, fine.

Second exposure uses raster mask from first exposure, fine as long as no polarity is in use. If you toggle raster mask polarity-> whow. Log file shows raster mask is taken in both cases but only applied if not inversed.

DSCF2164.RAF.xmp.txt

It seems to be even more simple, have you tried a simple shape mask on exposure and invert it?

[s7habo]

have you tried a simple shape mask on exposure and invert it?

I forgot to demonstrate this in video but yes, I tried it and no problems. Everything works as expected.

[jenshannoschwalm]

Hmm. I'm absolutely not the video guy ...

Bildschirmaufzeichnung vom 2023-05-07, 19-20-22.webm

[s7habo]

Just so that we don't misunderstand each other - if I use simple (drawn) mask and for second instance of the module I use inverted version of the same mask - not rastermark!- there are no problems.

Problems arise when in the second instance you do not use the inverted drawn mask itself, but the inverted raster mask, which is based on this drawn mask. Exactly as you have shown in your example.

[jenshannoschwalm]

Yes i understand what you say. But what i am really surprised about is what happens if you simply just have a shape mask and invert it. I would expect to only have any effect on pixels-not-inside-the-shape... EDIT: so the problem seems to be for any mask being inverted ?

[s7habo]

I would expect to only have any effect on pixels-not-inside-the-shape.

This is indeed the case.

The problem with the mask - the circle - that you used in your example is the transparency of the mask. It has only 44% opacity:

If you invert it, then the part inside the shape will be affected accordingly (it has only 56% opacity there):

[s7habo]

If opacity is 100%, then the inner area will be completely transparent when the mask is inverted:

[jenshannoschwalm]

Arrrrgh!

Btw i think i have found the inverted raster mask issue. Pascal will have a look but it seems to be a very old one ...

[jenshannoschwalm]

May i ask you again to check current master? (You have much more use for any mask than me so i would likely not run into issues but we want all remaining issues getting fixed in 4.4 :-)

[s7habo]

Have done just now.

With darktable 4.3.0+2236~g46414573f.

Nothing new. The same issues as described in the video above:

[s7habo]

-d common

darktable_raster_mask_issues_continued.txt

[s7habo]

[TurboGit]

@s7habo : Can you check if you are using down-sampling?

preferences -> darkroom -> reduce resolution of preview image

If so, try again with "original" (no down-sampling).

[s7habo]

If so, try again with "original" (no down-sampling).

I use that option. I don't use down-sampling.

[s7habo]

Raw file with Bird.

@jenshannoschwalm , @TurboGit Have you tried to reproduce it?

It is enough to go to the lighttable and back to the darkroom.

The raw file is from:

https://discuss.pixls.us/t/gamut-issues-should-i-be-worried/36719

The sidecar file:

ER6_2855.CR3.xmp.txt

[jenshannoschwalm]

I will check tomorrow. You comment about go to Lightroom and back to dr might be a hint as we keep cachelines ...

[jenshannoschwalm]

I am not quite sure what the exact status of "remaining issues" is.

I can reproduce issue related to color picker for sure and would concentrate on that first. Unfortunately i have never looked & touched color_picker code yet. @TurboGit @dtorop @dterrahe what would be the place to look here? (Where is color_picker data taken and where is is written? )

[dterrahe]

Haven't in depth read this whole issue so not sure what color picker you are referring to. The parametric masks ones? So first a very high level overview (which you probably figured out already).

Colorpicker data gets calculated, if requested for a module, in the pipe in pixelpipe_process_on_CPU or dt_dev_pixelpipe_process_rec and when available a signal DT_SIGNAL_CONTROL_PICKERDATA_READY is sent to the UI thread. This gets picked up in _iop_color_picker_pickerdata_ready_callback which sets

  piece->pipe->changed |= DT_DEV_PIPE_REMOVE;
  piece->pipe->cache_obsolete = 1;

and propagates the signal to the blending code first (blend_color_picker_apply) and then to the per module method color_picker_apply. If a module has multiple pickers, it needs to check there first which one is active.

Last time I looked at this, without much understanding; I was just refactoring :-) was a while back. Please let me know if I can help figuring it out.

[dtorop]

And this comment

https://github.com/darktable-org/darktable/blob/09d99ce81f139ee9c7dd60f8c73ad6f35503861d/src/gui/color_picker_proxy.c#L28-L57

gives a rundown of some of how the pixelpipe picker interacts with the GUI. Likewise, I've done some refactoring in the last couple years, but don't understand this ongoing debugging work enough to know how the colorpicker interacts. But happy to try to elucidate anything I know about colorpicker code.

[jenshannoschwalm]

@s7habo may i ask you again? I can not reproduce the demonstrated issues any more with #14533 applied.

If there are still issues for you -d pipe logs would be perfect.

[s7habo]

I have just tested it and the first issue https://github.com/darktable-org/darktable/issues/14393 is solved. I can't reproduce it anymore.

Problem in this bug report still exists in part. The navigator, color picker and histogram still lose the data when you switch to the lighttable and then come back to the darkroom:

Watch the short video:

https://youtu.be/UYDPrYCOMT4

Here is the output of the terminal with -d pipe option:

darktable_raster_mask_issues_after_14533.txt

[jenshannoschwalm]

1. Thanks for testing
2. Strange i did not observe this, do you have any presets for the involved modules by chance?

Will keep on tracks!

[s7habo]

do you have any presets for the involved modules by chance?

No, I do not use presets. Everything is default.

[s7habo]

By the way, the data loss in the navigator, color picker and histogram is the only problem now. On the canvas in darkroom and as thumbnail in ligthtable the raster mask is displayed correctly. There are no more problems.