darktable
darktable copied to clipboard
darktable-org
Feathered mask glitchy for color balance rgb with heavy edits
Describe the bug
When using the color balance rgb module with high brilliance settings in combination with a feathered mask (drawn or parametric) the effect bleeds outside of the masked region in a glitchy way. The bug is invariant to the module order.
The effect also shows up sporadically when changing the mask opacity. E.g. for a mask opacity of +79% and +81% the image looks as expected, for an opacity of +80% it does not. Similar for mask constrast: +9% and +11% look fine but +10% does not.
The glitches show up in an exported image.
When a instance of the exposure module+mask is used in a analogous way to increase brightness the effect does appear.
Steps to reproduce
- Open bright image.
- Strongly incrase brightness with color balance rgb module (e.g. global brilliance + highlights)
- Add drawn mask.
- Feather mask.
Expected behavior
No response
Logfile | Screenshot | Screencast
Commit
fcbe7dd5b10d86cd20e7a56afe7ec6357814d350
Where did you obtain darktable from?
self compiled
darktable version
4.7.0+97~gfcbe7dd5b1
What OS are you using?
Linux
What is the version of your OS?
Ubuntu 23.04
Describe your system?
No response
Are you using OpenCL GPU in darktable?
Yes
If yes, what is the GPU card and driver?
Nvidia GTX 970
Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip
No response
High brilliance values can produce extremely large pixel values (e.g. in the billions, where 1.0 is pure white) -- see #12442. If you have highlight reconstruction turned on in FilmicRGB, this results in artifacts as the reconstruction blends those extreme highlights with the surrounding.
Does the glitch appear with filmic's reconstruction completely disabled? (check-box unticked)
Filmic's highlight reconstruction was disabled. The anomaly also appears with a disabled filmic rgb module. Module order does not seem to play a role, besides the effect's strength.
Minimal example from the first post: gradient.png & gradient.png.xmp (zipped as .xmp uploads are not allowed) gradient.zip
I can reproduce, Fedora 39 KDE, 4.7.0~git98.bce83d51
Set the Color RGB Global Brilliance and highlights to 100%. Place a round circle drawn mask, increase feathering to 1px. snd it bleeds over horizontal or vertical or both.
If I rotate the image, the lines remain horizontal/vertical from the display screen and not to the image.
It's the same underlying issue as in filmic's reconstruction - both that and the guided filter work by blurring the input, which means the supernova-bright pixels generated by overuse of the brilliance slider get spread around and cause artifacts.
Don't push the highlights brilliance past +20% or so (sum of global and highlights sliders), as the math breaks down.
Don't push the highlights brilliance past +20% or so (sum of global and highlights sliders), as the math breaks down.
Complaints about this appear so often that it is worth somehow making it difficult for users to shoot themselves in the foot. I'll make a PR that adds soft limit of ±20% for all brilliance sliders.
I expected the image to break for high values. I found it strange how it effects the masked out areas and doing so in a seemingly unpredictable way.
I expected the image to break for high values.
At least darktable works as expected :)
I found it strange how it effects the masked out areas and doing so in a seemingly unpredictable way.
So you're essentially pushing dt algos to where they could not operate meaningfully and want them to produce broken images in predictable ways? I'd say that failure to do so should not be considered as darktable bug.
I'll make a PR that adds soft limit of ±20% for all brilliance sliders.
Really only of use for the global and highlights sliders, as the pixel must be pretty bright to begin with. OTOH, consistency is also desireable.
Worth adding a note to the tooltips that (global+highlights>20%) can cause artifacts with any subsequent wavelets, guided filter, or blurring operations?
A note would indeed be useful. As of now I did not find a hint in the doc or tooltip that too high values can lead to problems.
As a sidenote the same phenomenon also occurs when using an instance of the exposure module with a ludicrous setting (like +18 EV) and the same mask+feathering setting. Admittedly, this scenario is even more far fetched.
I'll make a PR that adds soft limit of ±20% for all brilliance sliders.
Really only of use for the global and highlights sliders, as the pixel must be pretty bright to begin with. OTOH, consistency is also desireable.
Yes, the other two sliders are soft-limited for consistency. My approach here is exactly the same as @SoupyGit's comment to the PR: inconsistent values for the soft limits of the brilliance slider pack would be confusing.
Worth adding a note to the tooltips that (global+highlights>20%) can cause artifacts with any subsequent wavelets, guided filter, or blurring operations?
Indeed, it is worth it. I'll borrow your wording for the tooltips. :)
A note would indeed be useful. As of now I did not find a hint in the doc or tooltip that too high values can lead to problems.
Done. I think this is the optimal solution for a situation with possible problems due to an excessive value of the sum of two sliders. Controlling this sum and issuing a warning in the module looks too invasive.
As a sidenote the same phenomenon also occurs when using an instance of the exposure module with a ludicrous setting (like +18 EV) and the same mask+feathering setting. Admittedly, this scenario is even more far fetched.
Yes, it's the same phenomenon: we create values so wildly huge that their diffusion (and blurring/feathering is, in a sense, diffusion) creates noticeable artifacts.
