Thx I’ll get around to asking….
If I’m not mistaken, multiply reverse, is just a different, new linear RGB name for screen.
If you look at the RGB scene list you see that several known blend modes are “missing” (overlay, screen, soft light etc). All these RGB scene blend modes are rewritten to be consistent with the linear RGB (scene referred if you want) way of working. Here’s the RFC: [RFC] Improve blending in scene linear space by hlecleme · Pull Request #4688 · darktable-org/darktable · GitHub
Most blending options have an opposite (reverse) option to begin with: subtract/addition, lighten/darken, screen/multiply etc. The counter part got a new name in the RGB scene selection.
I’m not sure why the devs had to give them new names, you have to ask them about that.
To be honest, I don’t get the logic behind your workflow but whatever it is, the results are just fantastic and I love them!
According to the implementation code, it is multiply blending with the opacity slider on the input image of the iop (in opposed to the “multiply” blending where the opacity slider applies to the output image of the iop). The same applies to all “* reverse” blending modes.
Actually they are new blending modes. Most of your mentioned blending modes (overlay, screen, soft light, etc) are developed with display referred (gamma corrected) space in mind, and are not valid in scene referred (linear) space.
1 Like
Really!?
To my knowledge the underlying principles are based on equations, their counter parts basically being the inverse (with a bit of tweaking in some cases). I’ve never heard/read that display referred specifics come into play.
In some cases, according to the GIMP documentation, gamma is even removed when needed before applying them to make sure they are sRGB linear. GIMP chapter about blending modes.
I just searched a bit to make sure and gamma is not mentioned in any of the Photoshop, GIMP and Illustrator documents (except as a basically irrelivant side note).
This video The Mathematics of Blend Modes does mention gamma, but this is very brand specific and not true for the basic principle of the blending mode itself.
The “new” blend modes might be tuned towards better integration towards scene referred, but I still think that, basically, multiply reverse = screen (as is true for the other reverse modes). Still no reason to rename them in my opinion. Then again I don’t get a say in that 
1 Like
Hello Boris,
Thanks for this video!
I missed your videos!
1 Like
Most of the equations assume that the values are between 0 and 255 (or 0 and 1 if you are using floating point), which is not always true in the scene refered world.
1 Like
Great explanation and makes sense now…thanks for taking the time to explain it….
Hi,
From DT code and video The Mathematics of Blend Modes
Multiply (video) : a * b
Multiply (DT) : a * (1 - opacity) + a * b * blend_parameter * opacity
MultiplyR (DT) : b * (1 - opacity) + a * b * blend_parameter * opacity
Screen (video) : 1 - [(1 - a) * (1 - b)]
(Screen is not enabled in RGB Scene blend mode)
When opacity is 1 : Multiply and Multiply Reverse are equals.
Otherwise the base value is added with factor that depend on a (image base) or b (blend).
6 Likes
Thanks for the clarity…
See : Blend modes - Wikipedia
Everytime you see a “0.5” threshold, what it actually means is “OETF(middle grey)”.
1 Like
What does Electro-Optical Transfer Function (EOTF), converting linear scene light into a video signal, have to do with multiply (reverse) being the inverse of multiply and its naming?
I’m not a developer nor a mathematician nor a physicist. I do realise that a certain understanding of the underlying principles are needed and up to a point I do. But don’t expect a “normal” user to deep dive into, let alone understand, the in-and-outs of the code and its mathematical principles/consequences.
In the end I’m a photographer that wants to know what an option does to the image and what its possible pitfalls are.
Am I wrong in stating that multiply (reverse) basically is overlay/screen (i.o.w the inverse of multiply)? And that this is also the case for the other ‘reverse’ blend modes.
As stated before, I do realise that tweaking and/or rewriting needed to be done to make certain blend modes scene-referred compliant. Do I really need to care about that as a normal user though, and does that justify renaming something that’s been around and understood when spoken about for ages?
Yes.
The reverse part refers to the way opacity is used, not to the blending mode in itself: In the “normal” blend modes, the top layer is more or less opaque, i.e. contributes more or less to the final results. For the “reverse” modes, the opacity is applied to the lower layer.
But in both cases, the same blend mode is applied (see also @gi.vi.23’s reply.)
No, if you don’t want to.
But in this case, the devs are not renaming anything, those are new modes.
As in e.g. the GIMP layers are independant, you do not really need such modes, you can just change the layer order. In dt, changing the layer order is still not really recommended practice, and you need to know which layer goes in which part of the pipe (and why: for some the optimal position depends on the use; LUTs have been discussed here before)
===========================
You might want to keep context in mind… The OETF reply from @anon41087856 was to your remark that you didn’t see where scene/display referred was important… And the visual middle gray value in scene-referred is at around 0.18, in display-referred around 0.5… So some blend modes are hardcoded for a display-referred middle gray. Not good for use on a scene-referred image.
So you changed the question to which @anon41087856’s reply was the answer…
2 Likes
Point of definition: display-referred means bounded signal, in 0-100% of display emission. But display emits linear light, once all the electrical treatment has been done (and OETF reverted in DAC or something).
What I’m saying is display-referred doesn’t necessarily imply bounded and non-linear. It’s just bounded. But, in this case, indeed, it’s bounded and non-linear, such that the 18% grey becomes a 50% to match the hardcoded thresholds of the blending modes.
1 Like
Ah, finally a straight and understandable answer to that question. No maths, code and formulas involved
I don’t understand how I need to place this in relation to the way the new blend modes work.
All actions taken are done within a specific module using the input from the previous one and it gives the output to the next one. So the place in the pipe does matter, but only in as far that the input and thus the output is different (which can be a desired/good thing at times or have bad results if you do not know what you are doing).
The way you describe it, or the way I read it, sounds like that the (new) blend modes work over multiple modules, which can’t be the case.
BTW: I do understand and make use of the possibility of placing (a copy of) a module in a different position in the pipe (most often after filmic). Exposure, Colour balance and (the old) Channel mixer being prime examples that I used at times.
Yeah, you are absolutely correct!
I overreacted a bit to yet another maths, formulas, totally unfamiliar abbreviation-as-an-answer explanation that didn’t really answer anything at all (I reiterate: I’m not a developer nor a mathematician nor a physicist).
Sorry about that!
Thanks for explaining the OETF in plain English 
1 Like
Everything still happens within one module.
But of course a blend mode works over (at least) two layers/iamges:
- the input to the current module
- the raw output of the current module
These two are combined acording to the blend mode operation to get a result.
That result is what you see when opacity is set to 1 ( or 100%).
So, we have actually three (!) images here:
- ( a ) module input
- ( b ) module output before the blend mode is applied (what you see with blend mode=“normal” and opacity=100%)
- ( c ) module output after blend mode application (e.g. blendmode=“multiply” and opacity=100%)
Now, if opacity is set to a lower value, ( c ) is mixed with either ( a ) or ( b ) to get the final result you see.
For the normal modes, ( c ) is mixed with ( a ),
in the reverse modes, (c) is mixed with ( b ).
I won’t write out the math, but the resulting equations are quite different from the traditional blend mode equations which don’t take into account layer opacity.
Here we get backt the GIMP: there, layers are one image, there is no input to a layer or output from a layer, as long as we don’t take into account blend modes and opacity.
Now, for many of the blend modes, it doesn’t matter which layer is on top (ab==ba), so in the Gimp, you can switch layer order to get the blend mode result with either one of the layers. You can’t do that in dt (input always comes before output…), so the new blend modes do give us something new, different from the existing modes.
(You are right in that module order doesn’t come into it, the layers are all within a single module, that was a mistake on my part)
But showing the differences precisely requires math and equations. If you don’t want to deal with those, you’ll have to trust the ones that do deal with it. Of course you can describe mathematics purely in text, after all, that’s what Newton did. The modern way is just a tad more compact…
4 Likes
New episode: Last autumn leaves 
13 Likes
Merry Christmas, Boris!
yet another AMAZING edit. Inspiring and me learning a lot
I have one question:
I tried blend mode multiple reverse as well and did one thing differently: I increased exposure AND combined it with a drawn mask. What now happens, is, the brightness increase also is applied OUTSIDE my drawn mask. I would expect, every modification stays within the mask… Where did I take the wrong exit?
@AxelG: This might be a bug related to the multiple reverse blend mode.
I just recreated what you describe and I can confirm your findings. This only happens when you use the multiple reverse blend mode, all others are unaffected as far as I can tell (tested all the reverse ones, both the reverse and its counter part).
Just to make sure, here’s what I did:
Using: darktable 3.5.0+169~gecc48ae7a
- set exposure,
- set filmic,
- create second exposure instance and place it above filmic,
- create a drawn mask,
- select multi reverse blend mode,
- change exposure setting (not the fulcrum one, the ‘real’ one)
These steps show that the complete image is adjusted, not just the masked area. Changing the blend mode to any other does not show this behaviour.
BTW: There’s no actual need to create a second instance and/or activate filmic, this also shows when using just the exposure module.
EDIT: This is not exposure + multi reverse specific, this also happens in other modules. So: multi reverse specific.
Ok, I see, but I don’t use the second instance to increase exposure, I always do that with the first instance. Second instance is only for contrast. And for fine adjustments fulcrum is enough.