Ensuring raster masks are less dependent on the source

[RawConvert]

Suppose you've defined a mask and are re-using it later in the pipeline in some other module using the raster facility.
If you switch off the module where it's defined, the later module can no longer use it. This can be quite confusing until you work out what is happening. The suggestion is to keep masks available for later modules even when off. In terms of functionality, is there a downside to this?, I can't see one myself.

Also, if you delete the module where the mask is defined, then again (not surprisingly) it's unavailable as a raster. Perhaps here there could be a warning message to remind you that you've re-used it. (But only if you have re-used it)

[elstoc]

Raster masks (as any parametric mask) can be generated based on both the input and output of the source module. If the source module is switched off it does not participate in the pixelpipe and therefore has neither input nor output. Certainly any output used to generate the parametric mask would require the module to process image data and generate said output so I don't know how nicely your suggestion would play with how the current pixelpipe functions.

As a workaround (and assuming you only need to use the input sliders to generate your mask) you could place a module instance into the pipe that essentially does nothing (for example an instance of the exposure module with all of the sliders set to zero) and you use that module purely for generating your reuseable mask. In this case there should be no issue with keeping that module switched on.

[parafin]

As a workaround (and assuming you only need to use the input sliders to generate your mask) you could place a module instance into the pipe that essentially does nothing (for example an instance of the exposure module with all of the sliders set to zero) and you use that module purely for generating your reuseable mask. In this case there should be no issue with keeping that module switched on.

That's identical to using an output on previous module, which won't require enabling an extra operation, isn't it?

[elstoc]

That's identical to using an output on previous module, which won't require enabling an extra operation, isn't it?

Indeed - though I do like the idea of having a separate module just to contain the reusable mask and I'd have thought exposure is a fairly low impact module (in terms of performance).

Either way if it's a parametric mask you risk changing that mask if you alter either the source module or any module prior to it in the pipe. So it's "buyer beware" however you do it (including choosing to switch the source module off).

Unless there was a good reason to do otherwise I'd want to put the source module for the raster mask as early in the pipe as possible and on a module I wasn't likely to later remove, to avoid these issues.

[parafin]

The main problem with this feature request is that it basically requires non-linear pipeline, while darktable was designed only for linear processing, without branching. So implementation will either be a total hack or too hard IMHO.

[elstoc]

That's what I'd assumed.

[johnny-bit]

A very hacky and probably too problematic "workaround" but providing even more features - allowing to save mask to single-channel file and loading from file. eg 32-bit float tiff. That's imo not really worth pursuing yet.

A sensible workaround might be indeed what @RawConvert suggested - have a warning in case of disabling/removing module that has mask which is used as raster by other modules.

[RawConvert]

switched off it does not participate in the pixelpipe
I can see this but can't so easily see why the calculated raster can't remain present after switching off.

use that module purely for generating your reuseable mask
I wasn't thinking of that particularly, more that you would have a genuine need for the first mask to begin with, but if you then don't need it and want it used by something else, it's a shame to spend the time re-making it in the later module. That was my case, I thought exposure would do the trick, but it didn't look good, so I used a tone curve with raster subsequently, and set the exposure module to zero. Ok, it's not a massive problem!

it's "buyer beware"
Yes agree, there's some of that involved. Though I suppose a drawn mask is less likely to cause confusion.

basically requires non-linear pipeline
Why does it if you were just freezing the raster mask at the point of switching off the module?

... but as always, I don't know how difficult these things are to implement or go against the design...

[elstoc]

I can see this but can't so easily see why the calculated raster can't remain present after switching off.

Why does it if you were just freezing the raster mask at the point of switching off the module?

I think you're assuming the raster mask is generated once and then saved away somewhere for future use but I'm not sure it works like that. I believe the raster mask is regenerated within each run of the pixelpipe because it could contain parametric masks whose input has been altered since that mask was created. So you're telling your target module "use the same mask as the source module does" and if the source module has not generated its mask (because it's not executed in the pipe) there is no mask to use.

[parafin]

I can see this but can't so easily see why the calculated raster can't remain present after switching off.

Why does it if you were just freezing the raster mask at the point of switching off the module?

I think you're assuming the raster mask is generated once and then saved away somewhere for future use but I'm not sure it works like that. I believe the raster mask is regenerated within each run of the pixelpipe because it could contain parametric masks whose input has been altered since that mask was created. So you're telling your target module "use the same mask as the source module does" and if the source module has not generated its mask (because it's not executed in the pipe) there is no mask to use.

Indeed "freezing" implies it gets saved somewhere (because it needs to be persistent across application restarts), but storing it on disk will consume roughly the same amount of space as original raw file. So in reality it gets recomputed instead.

[RawConvert]

OK, looks like preserving a raster mask is not a goer.
I'll leave this open for now in case there's any interest in a warning when disabling/removing a module that is a raster parent.

[junkyardsparkle]

A very hacky and probably too problematic "workaround" but providing even more features - allowing to save mask to single-channel file and loading from file. eg 32-bit float tiff. That's imo not really worth pursuing yet.

If it ever does become worth pursuing, why not allow RGB channels... then it could be used for stuff like flat-field correction of chromatically complex lens vignetting, etc... ;-)

[parafin]

A very hacky and probably too problematic "workaround" but providing even more features - allowing to save mask to single-channel file and loading from file. eg 32-bit float tiff. That's imo not really worth pursuing yet.

If it ever does become worth pursuing, why not allow RGB channels... then it could be used for stuff like flat-field correction of chromatically complex lens vignetting, etc... ;-)

FFC is better done before demosaicing.

[elstoc]

Of course if we could save the raster mask as an additional (massive) sidecar that would open the door to someone writing a raster mask painting module...

[RawConvert]

It would be nice to remove bits of mask by painting. Though I saw a comment somewhere by AP I think, saying "DING", "dt is not Gimp". How about dt sends the image and the mask (as a separate layer) to Gimp, you paint etc, alter the mask however you want/can, then back to dt replacing the mask (but no changes to the image itself of course).

[johnny-bit]

Ummm... gimp may not be best suited for that - krita is theoretically bit better, however that still relies on external app which we have no control of (in terms of speed and accuracy of methods)...

Theoretically having raster masks paintable via painting gui in darktable it would allow for totally free raster-based dodge and burn and all other cute raster based masking which is awesome, but comes with couple added costs and tradeoffs.

[github-actions]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.