A glorious patch submitted in June to make the masking and blending fully scene-referred-compliant (and unbounded) is currently being reviewed for merging in darktable 3.4.
We would like to take this opportunity to declutter and remove the output masking parameter, which nobody seems to use. Here:
Does anyone has a case to make against this ?
The input masking takes the image before the current module is applied, creates an opacity (alpha) mask parametrically from the input, and blends the output of the module on top of its input.
The output masking does the same, but the opacity masks is built parametrically from the output of the current module, which depends on the other settings in the current module, such that if you change the parameters in the current module, it might invalidate your mask and you might need to redo it.
I find this design leading to circular edits and bad worflow. But I have seen before users developing creative solutions I never thought of, so⦠here is your chance to say something.
@Bruce_Williams once explained the output parameters in one of his videos in such a professional way that I wonder, he has a use case. Hence I ping him here.
I had to look at my Darktable mentorās video on parametric masks to find something relevant. He starts explaining the top sliders at 19:30 into the video. Granted, this is pretty out of date.
Honestly i never had a use case for the output slider.
Just rewatched Bruceās episode about it on YouTube. But i believe all the mask ārefinementsā achieved in this presentation would have been possible on the input stage as well.
Anyway: i feel like thereās a certain use case for it.
Note:
Using āinputā only we get more highlights in the bush, around the door buzzers, and less darkness on the vertical line at edge of doorframe. These may or may not be desirable pending the image, but I think the differences are distinct enough to warrant keeping both for sharpening modules at least. Donāt think Iād miss them for other modules.
I donāt use the output often, but when I do I use it as a āblend ifā function to modify how the adjustment is applied.
So, my workflow is use the input filter to select what I want to modify, then make my adjustment, then use the output filter to adjust how itās applied, if I need to.
Honestly, the only time I have ever used the output sliders was when I was making that video!
I, for one, would not miss them if they were removed.
It certainly seemed to me that any mask you could build with the output sliders could also be achieved with the input sliders if done correctly. Just my 2 cents.
What did catch me sometimes was having used one of the channels, and then forgetting about it later. Using a different channel gave unexpected effects. Figuring out why has cost me a few hairsā¦
Would it be possible to add a visual marker when a channel has one of the sliders off itās default value?
Yes it hurts. The masking options are very crowded now, and having a buffer reading at input and at output is twice the I/O penalty, so it degrades performance a bit.
Argh, this is a very hacky way of working around the flaws of the sharpening module, which, as usual, should be addressed in the module itself. Masks should not be used to circumvent pixels operations flaws, flaws should be fixed where they are.
@anon41087856: I never used it so I donāt care if it is removed. Anyway, @danny idea is good: maybe just hide it and let a button (or preferences setting) to show it if some wants it. Many users will donāt see this thread.
To be clear, the PR mentionned above adds a new option blending option on top of the old ones. Output masking will be kept for old blendings, the point is to remove it if possible for the new option.
Adding a new button to hide/show it defeats the purpose. Better keep it than making it optional.