I could also run the testsuite has we have many tests with masks. Probably not a complete testing but a good starting point. Let me know if you want me to do that.
Thanks!
If you mean the integration tests, I am running those already and they are all good. Is there a separate suite for masks somewhere?
I’m not sure I’m understanding you. I don’t like the yellow wall, either. Are you proposing no yellow could represent full mask application due to no masking elements? How would you differentiate that from a very slightly masked operation that had maybe some yellow pixels, or a 1% opaque mask?
Very simple approach:
- If something (anything, even just one pixel) is masked, show the mask.
- If nothing is masked, or the mask is a no-op, assume that everything is masked and show an empty overlay.
The only difference with Classic is that in classic for (2) you get a YELLOW WALL, what I am proposing is to let you see through so that you can use a picker or decide where to draw a shape.
We can also refine (1), e.g.:
- We already have low opacity indicators in Flexi
- We can add warning messages such as “only XXX pixels (less than XX% of the image) are masked”, or something along those lines.
- Also, warn if mask is not empty but there are no masked pixels (i.e., no op). BTW, we already show a black overlay in that case, so the image is dimmed and there is no yellow to be seen, so that should be enough.
Those warnings would help differentiate between a mask that’s grey because there’s no mask and a mask that’s grey because nothing passes the parametric mask.
What about when a drawn shape is off screen? In that case, grey would mean no-pass. But realistically, I feel that won’t confuse people.
I’ve gotta sign off and get some rest. It’s possible I’m being too strict, imagining things will cause confusion that won’t.
Actually, there is no confusion, I made it more complicated than it needs to be.
If mask overlay is enabled and:
-
Nothing is masked, then mask overlay should be a no-op. You should be able to see the image beneath, unaltered, and you can use it with the parametric pickers or shapes. As soon as you draw something, the mask overlay kicks in and you see what you masked (2)
-
There is at least one mask element. The mask overlay is visible. You see what is masked as yellow, and everything else is desaturated. This is already darktable behavior.
There is no new1 case in which “nothing is masked” and “mask is no-op” can be confused.
1 It is already the case at master that if you enable the mask overlay on a B&W image and the mask is a no-op you may not see a difference.
No.
The funny thing about this is I feel like this is a selection and not a mask in DT…if you mask in photographic sense you cover the image from the light or some alteration.
No mask in DT, ie nothing covered means the module is fully applied…drawing a selection and calling it a mask but having that be the area that is going to display the effect has always seemed a bit backwards… we are actually masking what darktable would define as the inverse mask by drawing a selection in the normal mode and alpplying the effect to the selection… but this likely outside the scope of this… I get the black conceals white reveals way of thinking but black is the mask or area not affected…or am I obtuse… ![]()
Yes, true. But I wouldn’t change that at this point ![]()
Its part I think of that nuance of the inclusive vs exclusive modes and how they dont’ align with the pixel math because of how the display has to be shown…though to me and again I’m that last one that is qualified…at times there have been some very long discussions about terminology and to me its a selection, local edit, local selection combined to make a mask but not really a mask, the masked is the area not selected by these elements and the combination of the selection and the area outside those make the mask, ie the one layer that defines the “mask” over the image, but I must admit its a bit late to and likely nothing anyone would consider important…
If it makes you feel better, in flexi you can mask what you would actually “mask” (as opposed to select) and then invert the whole mask at once to achieve the desired effect ![]()
Hi Daniele … you pushing this really forward , I am impressed !!
I am not getting my grips to all these new features … so far … but try hard .
Might take a while …
Love the overall approach .
Not sure if I have missed something so far … when a subject is selected via AI , can I shrink or grow the selection ?
When I shift/click nothing is happening … in the module . When I use the path tool , then I can shift/click and submenu opens .
Regards Andreas
I did notice that… but really I am not bothered…just having a bit of fun thinking about how it sounds to me when people say they have masked the sky or whatever …and I think well you masked the foreground and left the sky exposed for your effect
Awesome work by the way…so much talk about something updated and new over the years and you are moving the needle…
Hi Andreas,
This is unrelated to the masking panel. When you create an AI mask, the shape is only created after you right click on it. Then you can shrink/grow it like any other shape.
THX for your reply Daniele …
I know how to create a subject mask … but I can´t shrink /grow it via slider menu !!! As the submenu is not appearing in latest build
The submenu does appear … when I shift/click on a created path tool selection.
MacOS ARM 64 latest Tahoe
Mask manager is " gone " as well ?!
I may be wrong, but isn’t that the “industry standard” in tools like Lr and Ps?
I totally get what you mean, but to me it has always made more sense to me that you select what you want to alter, rather than “mask off” the area you want unaffected.
As I said I was just having a bit of fun but the mask to me is the final product in my mind once the “cut outs” or selections are made and those elements themselves are not the “mask” but selections made to determine what part of the image is exposed to the adjustment and what part of it is masked from the adjustment…any way it nuance… and it shouldn’t take away or distract from the topic or good work by @Masterpiga
I’m trying today’s github main master branch build; the whisker boxes are different. They’ve always followed the mouse and updated the value without clicking, but not any more. I assume that’s a bug.
Also my mouse cursor is always in the ‘drag up/down’ animation no matter where I am in the UI.
Huh I had that as well but assumed it was a KDE bug.
May be related to the GTK4 migration. My answer above was based on me not having used the whisker controls extensively and not knowing exactly what to expect.