I recently figured out the mask manager. I haven’t seen a lot of videos of edits that use it. It’s quite nifty.
5 Likes
I struggle with the mask manager. I am not sure if the GUI could be improved or if I just have to put more effort into reading the manual again and getting used to how it works. I guess the truth is that when I want to use it I need to open the user guide to remember how it works. As an infrequent user of the mask manager I forget how to reveal the option to get to the various operators to combine shapes. I would have found right clicking on the shape to get to the operators easy to remember but it seems I have to expand the group name.
I am also seem unable to combine a drawn mask and a parametric mask in the mask manager, although a similar function can be found in individual modules. Am I missing something here?
But yes the mask manager is under-appreciated and can be helpful.
1 Like
It’s only for combining drawn mask elements to craft the final group that makes the overall drawn mask.
1 Like
Would there be any sense in including parametric masks and maybe even raster masks? Just wondering. I haven’t thought this thoroughly but I have wanted to use mask manager to control interaction between drawn and parametric masks in the past.
1 Like
Raster, maybe. But parametric masks are ‘unstable’, they depend on the input or output of a module, so you can’t freely assign them to another module and keep the effect.
2 Likes
raster masks even more.
In short - no.
2 Likes
Thanks @kofa and @hannoschwalm. Happy to accept your answers on that.
This is relevant -
1 Like
This would be a solution to the fact that in darktable there’s no way to both add and remove region from a parametric mask. The one time I really wanted to, I couldn’t cleanly mask the sky. I really like darktable and don’t want to come off as too salty, but I was really surprised such a useful feature workflow wasn’t possible. (Make a parametric mark, draw a shape that removes some positive error region, draw another shape that adds some negative error region, done.)
I’ll try to post a playraw this weekend.
1 Like
I think you’d be able to do that with the MMM!
@kofa , I’m not sure what you mean but I think “unstable” isn’t the best description. It’s not as if they blow up or something! I find raster masks very useful. Suppose someone is wearing a bright jacket and I want to tone it down. I can select it with a hue-based mask in an Exposure instance, then use it it Color Balance RGB, and with those two modules do what I need.
If I was able to combine raster masks, do you see a problem?
Yes, probably unfortunate wording on my part. What I meant is that if you have a parametric mask based on e.g. 0.25 < Jz < 2 (arbitrary values), that same masking condition (Jz range) may cover different pixels at the input of different modules (including ‘none at all’). Or, depending on the space the module is applied in, may not be available at all.
Actually, it would be very nice to have a way to “rasterize” a parametric (+ drawn) mask.
This could be used to “protect” a mask from changes in the previous modules parameters, and it would also have computational benefits because you would not have to recompute the mask continuously.
Basically, have a control that would turn the parametric (+ drawn) mask into a raster mask, change the mask type to raster and set it to use the newly computed raster mask.
Next level would be “snapshots for masks”, i.e., keep raster copies of the mask at different points in time.
Has this idea been floated around already?
1 Like
You’d have to store the 20-100 Mpx mask in the history stack… unless it’s to be based on a certain point in the development history, which can get invalidated by compressing the stack.
Why would it need to be saved in the history stack? Couldn’t it be just stored in the filesyatem?
I think there is confusion. Here’s what the manual says about raster masks -
“As described in the previous sections, the final output of a module’s mask (the combined effect of any drawn and parametric masks) is a grayscale raster image representing the extent to which the module’s effect should be applied to each pixel. This raster image is stored internally for active modules and can be subsequently reused by other modules in the pixelpipe.”
So all drawn/para masks are rasterized anyway.
And however many Mpx are needed, the raster is already stored within DT as a grayscale image.
I assume it is stored once and once only.
Re. compressing the stack, I think this is not relevant because DT executes the modules in pipe order (once only per module), not in history order.
@hannoschwalm , am I understanding correctly pls?!
I have no idea what I am talking about, but I believe that partial masks are recomputed whenever you pan/zoom. Of course there is some caching, but I believe that that is purged everytime that the mask itself or any of the previous modules in the pipe is changed.
I don’t know if there are “partial masks” or anything about them.
Sure! Absolutely!
It’s stored while processing the module if another module want’s that rastermask. So if B wants a rastermask from A that will only be available if A is processed – and A is only generating it if B is asking for it 
(Pretty complicated stuff with a lot of hashes and cache data involved)
1 Like
I was responding to:
(Emphasis mine.)
It is important to note that he meant (if I understood correctly), that once a parametric mask is computed, it could be marked as “frozen”, so not even changes to modules before the module that has the “frozen” (protected) mask would change it in the future.
Yup, that’s what I meant.