Proposal for a more compact and intuitive drawn mask UI in darktable

[elGordo (Gord)]

Copying from another UI-related thread (related to DorS):

@wpferguson

@thumper

We could still do the refinement, as a community.

AP replied to the DorS UI change PR with a link to reference documentation describing DorS. At the end he had a perspectives section which said changing the names of things would only cause confusion and prevent understanding.

After a good nights sleep and lots of thought I realized that if we change the names and reorder the controls we then have

• no useful technical documentation
• no useful user manual for DorS
• no useful DorS how to videos
• no useful edit videos where DorS is used

Modules exist in an ecosystem so changing controls may not be a good idea unless all the supporting items change also.

I think this is worth bearing in mind.

[finestructure]

@martinus

it is not super clear from the ui what the difference is between ‘opacity’ and ‘mask opacity’

This used to be called “mask brightness” which is also not super clear. I think it should be renamed to “mask opacity gain”, or “mask opacity multiplier” if it is a linear coefficient. It’s used often because feathered masks need to be “tone mapped” to get the edges right.

@garcondepapier

for my use, having the light gray sliders collapsible is a benefit. Other people seem to use these a lot so the option to collapse it is in the user’s hands

Would this send a message to new users that these options should potentially be hidden? I think, on the contrary, we should be sending a message that you always want to use these options for path or painted masks. They make masking much easier.

@europlatus

it would be more streamlined to just have drawn+parametric,

Right now switching among these three modes is a way to quickly toggle the parametric or drawn mask without deleting the data. I’d prefer a bigger change than hiding the buttons. A more powerful mask manager (implementing reordering, grouping, polarity, combine mode, disabling, deletion, visualization, and selection for each mask or group) inside the module would streamline operations. But it’s a big change and what we have now is basically good enough for most uses. The only thing it can’t do is add and subtract two different shapes from a parametric mask.

[Masterpiga (Daniele Pighin)]

Yes, that makes sense. It shouldn’t be a blocker, but for sure one should think twice before changing UIs for the sake of it.

Similarly, if functionality changes then it is a good moment to rethink the UI, because a different UI will implicitly invalidate (so to speak) existing documentation that refers the old functionality. E.g., if I see a video from the past and the UI looks very different, then an alarm should go off and let me realize that, probably, the information in the video is not up to date.

[Thad_E_Ginathom]

@martinus

On the topic of maks… What I also would appreciate is that the mask manager itself would get a bit of ui update.

Agree.

@europlatus

I would be very interested in a new workflow that adds these options at the time of making a mask, e.g. add circle 1, add circle 2 in union mode, add paintbrush 1 in intersection mode, add parametric mask 1 in exclusion mode, etc.

I agree with your ideas too.

@europlatus

And I still get confused with the “Add existing shape” and “Use same shape as” options after all these years!
Maybe I just don’t use masks enough to remember…

Ha ha… I use masks quit a lot and often in pairs, eg foreground/backround, and I’m sure that the existing/same thing is important to me. But I can never remember.

I think it is described in the manual. Note to self: rtfm. Again. Frankly, one can never rtfm too many times

[hatsnp (Nuno Paulino)]

I don’t like the collapsible element. it doesn’t save a lot of space and it’s just one more click. It starts getting bothersome seeing collapsible sections everywhere in the software.

Edit: Maybe check out how Ansel is doing masks. It’s not a far fetched idea and it sort of makes sense in my opinion. The space on the left of the screen is not used a lot so using it is a good idea. De-coupling the masks from the modules and then just associating them is smart and really cleans up the module UI a lot.

[hatsnp (Nuno Paulino)]

AP himself nuked the mask controls in Ansel and completely changed them For the better IMO.

[Masterpiga (Daniele Pighin)]

There are some wins and some losses in what Ansel did. The UI is more polished, but it certainly requires a lot more clicking. And being on the other side of the screen is a huge loss for me, there is a lot of left-to-right movement involved. I would rather make masks a floating panel (including the mask editor, at this point) that the user can position where they want

[Thad_E_Ginathom]

@Masterpiga

And being on the other side of the screen is a huge loss for me,

I agree

A no from me on that idea. I want to maximise the space available for the image, and thus I minimise panels that are not in constant use. In the darkroom, the left panel is simply not there for me unless I specifically need it. Which is surprisingly rarely.

And even if that were not the case, I would not want the mask controls for each module instance removed from that instance. Others have clearer heads: I am sure that this would trigger the kind of confusion to which I am all too prone

[hatsnp (Nuno Paulino)]

@Masterpiga

I would rather make masks a floating panel (including the mask editor, at this point) that the user can position where they want

This is what you see in Ansel for the mask properties. The manager is still on the left, but when you need to edit a mask’s params it popups up a window

[Masterpiga (Daniele Pighin)]

@hatsnp

The manager is still on the left, but when you need to edit a mask’s params it popups up a window

Ah, I didn’t notice that. Maybe it’s been added over the last couple of days?

[hatsnp (Nuno Paulino)]

I think so, there are a lot of mask related commits of late, give it a look. I only test it twice a year or so, and the last time happened to best last week

[martinus]

@Masterpiga

I would rather make masks a floating panel (including the mask editor, at this point) that the user can position where they want

Interesting how preferences are different. I absolutely hate floating windows. They also are at the wrong place at the wrong time. For me floating windows is very bad UI, they get lost, it clutter. I am actually very happy that darktable does not have many floating windows

[Masterpiga (Daniele Pighin)]

I would rather have a floating window than the mask panel on the other side.

That said, floating windows are not bad per-se. They are bad when they are too many. Like all tools, one needs to use them deliberately for the right job.

In the case of masks, given that only one mask can be active at any time, a floating panel makes sense. There is only going to be at most one around, so no clutter.

One common cause of friction in darktable (and similar programs) is that you may have to jump back and forth between two or three modules. In this case, I would be very happy to be able to make one or two modules float, so that I can see all the controls at once instead of having to expand/collapse and scroll up and down. I would never use darktable if every module was in a different floating window, because that would be hell.

Yes, you can use shortcuts for your core workflow edits, but you cannot possibly have shortcuts for everything. In addition, not all users like or are comfortable with shortcuts.

[martinus]

@Masterpiga

One common cause of friction in darktable (and similar programs) is that you may have to jump back and forth between two or three modules. In this case, I would be very happy to be able to make one or two modules float, so that I can see all the controls at once instead of having to expand/collapse and scroll up and down.

For me (just talking for my preferences here) floating windows give much more friction than the jumping back and forward. The problem for me with floating windows is that - since I work often on laptop - they always overlap with other things I also want to see.

And my other issue is that floating windows often have the tendency to hide behind the main screen. I almost every program that I have used with floating windows this happend at one point.

I really hope that floating windows is not a path darktable will choice… or that at least that when this path is chosen there is an option to not use it.

---

But what about a dockable layout? In many of programs I use that is an alternative to floating windows.

[Masterpiga (Daniele Pighin)]

@martinus

But what about a dockable layout? In many of programs I use that is an alternative to floating windows.

Oh, I would love to be able to have an arbitrary number of panels on the right and distribute modules on them. That would be heaven.

[Masterpiga (Daniele Pighin)]

Turns out, it’s actually not that difiicult to do:

The secondary panel is just a dumb container, all the logic (including pixelpipe position) stays in the main panel. When a module is moved the secondary panel it leaves behind a placeholder that can be used to adjust the position in the pipeline.

[Thad_E_Ginathom]

@Masterpiga

an arbitrary number of panels on the right

I can understand the appeal, but I just want to have as big an image as possible, and would not welcome any other panel. Just my particular point of view.

[Qor (Chris)]

very nice

[priort (Todd Prior)]

I had often thought that if there was a way to leverage the mask icon or a similar control in the module header, you could present a solution where activating it rolled up the module controls and filled the panel with the mask controls. This might add a click or so but could prevent the need to scroll esp in the longer modules. When you are done editing the mask you could revert it. This could be a toggle of some sort so that both could be left open or you could toggle between both in the panel. This could also be a preference for a mode something like this…

[Thad_E_Ginathom]

@priort

I had often thought that if there was a way to leverage the mask icon or a similar control in the module header

I use it a lot to check on a mask without even opening the module. Both to see which module affects which area as I’m not always careful with naming and, with presets, to see how the preset mask matches this image (if at all) without further work.

I wouldn’t like it do do anything other than displaying the mask