Feature #9149

Some way to copy conditional blending parameters between modules (or instances of modules)

Added by asdkant - over 7 years ago. Updated over 6 years ago.

Closed: won't fix
Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
hardware architecture:


This could be very useful, especially with multi-instance. Two examples:

  • normal blending, conditional on skin tones. Some high-grained contrast reduction with an equalizer instance and some lightening with an exposure instance.
  • Two instances of a single module, each one with the complementary part of the image (between the two they act on the whole range of the conditional blending, but each one has the part that the other doesn't). Again, this is useful on skin tones.

I'd be a good idea to think how this acts in tandem with area selection (not yet implemented in git master, but I think someone is working on it)


#1 Updated by Pascal Obry over 6 years ago

  • Assignee set to Pascal Obry

I had the need for this. Will look at this after 1.4 I think.

#2 Updated by Tobias Ellinghaus over 6 years ago

  • Status changed from New to Closed: won't fix

This is going to bring more trouble than good.

#3 Updated by Pascal Obry over 6 years ago

  • % Done changed from 0 to 50
  • Status changed from Closed: won't fix to In Progress

Why? A simple gui button on the blendif dialog to import the parameters from other modules seems quite simple and very handy. In fact I had something almost working some time ago and never had time to finish it. Let me do a proposal here.

#4 Updated by Pascal Obry over 6 years ago

Note that here I'm only speaking of copying parametric masks (blendif) parameters for the same picture.

Let me explain also why I think this would be handy. Currently when I do some skin mask with the parametric blendif it can be quite time consuming. I do that with the local contrast module to smooth the skin a bit and I often want to also desaturate the skin and/or change slightly the color. This means that I need the same blendif parameters for colorzone. Today I write the blendif values and re-enter them on the other module. That's time killer.

#5 Updated by Simon Spannagel over 6 years ago

But the copied parameters will affect a different portion of the image in the other module. It might not be that obvious in this case, but if you take another example it is:

You have a parameteric mask for "Monochrome" to get all blue stuff down to grey. You copy these parameters over to "Sharpen" to sharpen that portion of the image - and you won't get anything, because your "Input blue" parameters do not yield any portion of the image anymore.

Allowing this would only be beneficial in very few cases but make it easy for the user to shoot him/herself in the foot. Compare this to what could be done when rearranging modules in the pipeline - it might be a cool feature in 1 or 2 cases but results in unpredictable output all the time.

So my vote: don't allow it. If you write the stuff down and re-apply it you might at least think about what went wrong and see the yellow overlay while you apply the mask.

#6 Updated by Jérémy Rosen over 6 years ago

nobody questions that it's usefull, the problem is to do it in a consistent way that doesn't suprise the user...

problem is : if you copy blendif parameter from module A to module B, the mask selected on module B will not be the same mask as the one on module A, since they don't have the same input.

this will probably lead to a lot of confusion to the user and there is no simple way to do it... here are the problems with the obvious solutions

  • module B could ask module A for its mask
    that doesn't work if A is after B in the processing pipe. Very hard to explain to the user and make a consistent UI
  • module A saves its mask as a bitmap that becomes a normal mask, no transmission of blendif parameters
    that means saving the whole mask in the XMP, which is way too large for the XMP. Moreover the mask wouldn't adapt to changes in the image, which is one of the selling points of blendif

we don't really know how to deal with this. We are opened to ideas, and maybe copy/paste of pure parameters from A to B could work... (or any copy/paste between bauhaus sliders) but this needs to be thought through before putting too much effort into it...

please come discuss it on IRC for a bit, so we can try to put our heads together and think something through

#7 Updated by Simon Spannagel over 6 years ago

Summary of arguments from IRC:

(03:16:12 PM) dtslave: dtbugs: Feature #9149: Some way to copy conditional blending parameters between modules (or instances of ...
(03:17:59 PM) boucman_work1: ^^^^ that's definitely a frequently requested feature...
(03:20:10 PM) parafin: does blendif actually create a bitmap mask in memory? if so in theory it could be possible to one module to use it from another, but it will complicate things too much
(03:21:09 PM) parafin: another thought - convert blendif to drawn mask
(03:21:22 PM) parafin: some vectorization algorithm could do it...
(03:22:15 PM) houz: i doubt it, in general you have single pixels in/out with varying alpha
(03:22:22 PM) houz: no way to put that into a mask
(03:24:49 PM) boucman_work1: how about not saving the mask, but the pair <module,parameters> as the mask...
(03:25:37 PM) boucman_work1: i.e you create the blendif param in a module, save it, and the module using it would ask the original module, at pipeline time, what the mask is 
(03:25:36 PM) parafin: in any case you can't use mask from module further down the pipe than the one you're copying it to
(03:25:55 PM) boucman_work1: ... good point
(03:29:46 PM) parafin: even for a modules before it will require saving the mask in memory
(03:30:20 PM) parafin: either in cache, or we will have to reprocess the whole pipe every time
(03:30:23 PM) parafin: so bad idea
(03:33:54 PM) boucman_work: the alternative would be some sort of "save blendif as mask" UI that would generate and save the bitmask once and for all, fogetting where it comes from... 
(03:34:37 PM) parafin: bitmask is gonna be big
(03:34:42 PM) parafin: and how to save it? in xmp?
(03:34:59 PM) parafin: xmp will be as big as original raw this way
(03:35:57 PM) boucman_work: yeah, I know...
(03:36:07 PM) houz: nothing we want to do
(03:36:13 PM) boucman_work: i'm brainstorming here... trying to find a way
(03:36:30 PM) parafin: I don't think there is
(03:36:33 PM) houz: it could be argued that copying between multi-instances, but nothing else
(03:36:49 PM) houz: +could work
(03:36:48 PM) parafin: people will just have to draw mask over blendif mask
(03:37:01 PM) boucman_work: if we only allow forward usage of mask, we could collect all the needed blendif parameters before starting the pipe and build them as we go through the pipe for further use... 
(03:37:02 PM) parafin: is it possible to display blendif mask while drawing a mask?
(03:37:41 PM) houz: boucman_work: nobody would understand that concept. and in the end they would complain that the stored mask isn't as they want it to be
(03:38:01 PM) boucman_work: yeah :(
(03:38:19 PM) boucman_work:  from a UI point of view, save as bitmap is more or less the only way to go...
(03:38:19 PM) houz: we discussed that in the past already and didn't find a solution
(03:38:55 PM) parafin: boucman_work, even if we save it just in memory and only for the referenced oned, it's still additional memory usage
(03:39:05 PM) boucman_work: what could be done, though is copy/paste of blending parameters (not result) from one module to another 
(03:39:05 PM) parafin: ^oned^ones
(03:39:18 PM) boucman_work: that's a pure UI feature and could solve 90% of the user need
(03:39:37 PM) parafin: boucman_work, but still will be misinterpreted by many
(03:40:04 PM) houz: yes, people wouldn't understand why the mask isn't the same. they don't even understand module order
(03:40:43 PM) boucman_work: I'd still like to see copy/paste...
(03:40:54 PM) houz: we could add c&p of values
(03:41:30 PM) houz: we should add that to bauhaus sliders, too. right click, ctrl-c, esc, right click other slider, ctrl-v
(03:41:44 PM) parafin: yeah, that sounds good
(03:41:44 PM) houz: on blendif it would copy all 4 values
(03:42:14 PM) parafin: maybe blendif keyboards entry should be smth like 0/10/90/100
(03:42:36 PM) parafin: how finetune gonna look is another question...

#8 Updated by Pascal Obry over 6 years ago

  • % Done changed from 50 to 0
  • Status changed from In Progress to Closed: won't fix

I see, devil is on the details :( I'll discuss this for sure before doing anything anyway. But you guys know lot more about this stuff than I do, so if you say it is quite tricky...

#9 Updated by Tobias Ellinghaus over 6 years ago

Sorry that I closed this without any explanation, I wanted to give the reasons later, but as I see others were faster. We did discuss this a few times in the past and never found a sane way to achieve this, so the consensus was that it's not doable within dt's scope.

You could create a bitmap that other modules can reuse, and once the module that created the bitmaps changes it would recreate that bitmap and signal that it was changed or something like that. However that would most probably break our cache, be quite memory consuming and would need a bunch of extra API for the signalling part.

#10 Updated by asdkant - over 6 years ago

Here's an idea: have a UI for creating blendif masks at the begenning of the pipeline (or very near that), and be able to use those masks as if they were drawn masks.

Also, finetuning in ifblend would be VERY welcome (and I don't see any drawbacks about having that)

Also available in: Atom PDF

Go to top