I'm generating new blending modes for Krita

Processing
41

so disregarding the differences in the smoothing/interpolation approach, the default contrast parameter is adding more regions where the tf is saturated. Like you said, things would tend to get pushed into the corners more than I’d expect. It’s nice to have the extra degree of freedom.

Clipping will do that, yes. I can add a softer contrast enhancement formula and then provide an option to switch between that and simply clipping the image.

Would there be a way to hold an unmodified version of the random tf and re-use it between invocation? Having these extra parameters has me kind of imagining something where if a particular desirable random tf is found, the user could tick a box to hold the random tf, so that the smoothing and thresholding parameters could be tuned without losing the base tf. That would be pretty dang convenient.

That would be easy; by default, the removal of the mesh (remove[1,2] where [2] is the mesh) comes towards the end of the filter but I can add an option for G’MIC to output it anyway. It can also be reused and copied in the same invocation.

42

Ok, I’ll edit my post to avoid confusion.

Light, and Shadow from IFS Illusions are done. I get the naming convention now. But, Bright and Dark throws me off in terms of naming convention. So, I renamed Light to Illumination, and Shadow to Shade. Brighten will be renamed to Lighten, and Dark will be renamed to Darken. Not sure about the naming convention here.

By the way, I’m down to six compatible blending modes from IMBLEND. I could emulate mesh to a degree with the aid of conditions, modulus operation, but I don’t feel it’s worth the pain doing that.

43

I will be adding a mesh G’MIC filter soon but I’m not sure what I should do for the opacity setting. What should vary with that parameter?

44

In IMBLEND, opacity is just a scalar which controls the final composition after blending. For the simple case with no alpha content on the inputs:

out = opacity*resultfromblend + background*(1-opacity);

… or whatever is the conventional composition for the environment when alpha is present (e.g. SRC-OVER)

I really never could figure out what the intent was with those modes. That’s another reason I was interested in figuring out what used to be on the site. The developer clearly had his mind set on solving problems with the ‘softlight’ mode. I can only assume there was purpose behind these other modes. Some just seem so radical I can’t really even guess.

For what it’s worth, I don’t know that the renaming really clarifies things to that end. It’s kind of the curse of blend mode naming. The goals are often similar, but the english language has only so many ways to succinctly rephrase “make brighter/darker”. I have often entertained just using other languages simply for the latitude.

It’s all your choice in the end, but I’m reluctant to change names unless it better helps describe the math, the relationships between complements/transposes/inverses, or the characteristics which differentiate it from other modes of similar utility. I changed ‘parallel’ to ‘harmonic’ because that’s mathematically the more correct description,but I left the EffectBank modes as they were simply because I didn’t want to change conventions without confident reason on my part.

If you can figure out the intent, then we’re both better off, but ‘lighten’ and ‘darken’ at least need disambiguation. At least in the sources I found, EffectBank already had a unique non-relational ‘lighten’ and ‘darken’ mode anyway.

45

I have just added Modulo blending mode for Krita, and in addition to that, I have added divisive Modulo. Divisive Modulo is kind like Modulo Addition in a way. Hard to explain. Here’s what Divisive Modulo is:

template<class T>
inline T cfDivisiveModulo(T src, T dst) {
    using namespace Arithmetic;

    qreal fsrc = scale<qreal>(src);
    qreal fdst = scale<qreal>(dst);

    if (fsrc == zeroValue<T>()) {
    return scale<T>(mod((1.00/epsilon<T>() * fdst),1.00));
}  

return scale<T>(mod((1.00/fsrc * fdst),1.00)); 
}

What this does is divide the maximum channel value by the source layer, and then multiply with the base layer, and then apply modulo operation. So, if source layer is halfValue, you get the equivalent of Modulus Addition if the two layers are the same. I actually think these two makes great blending modes for abstract art, and glitch art. Divisive Modulo can also be used to alter gradient.

Next up is smooth divisive modulo.

1 Like
46

i ran a contour of that, and immediately thought, “i’m inclined to continuize this”

yes.

47

I have managed to solve it. For proof:

image

That means, Krita would have a very flexible gradient manipulation tool. With this, I can do a lot with gradient.

Next up, I think I will create Modulo Shift and take a break. I’m really liking this. The modulo blending modes are just too good for gradient mapping manipulation. I can say that I can officially shift gradient map now.

EDIT: I am now down to 1 blending mode to go for Krita! I’ll edit this post back if I managed to do flatlight. Then, I will release those modes to krita phabricator. LCH Blending Modes and filters are something I want to do, but Krita codebase at the moment doesn’t permit that for now. I have finished all the essential modulo blending modes for abstract art, and glitch art, and gradient map manipulation.

There are some IMBLEND mode that are actually way better than the standard overlay, dodge, and so on. Easy Burn, and Easy Dodge for example are superior to Dodge, and Burn in every single way. They’re smooth, don’t add up to one, retain the property of dodge and burn with the difference that they’re smoothed uniformly. Some mode like Super Light is better than their related blending mode, but the issue is that they’re better in either linear space or non-linear space. Super Light beats Hard Light on linear color space. I would argue that some quadratic modes are way better on linear space than overlay and some few lighting mode too.

EDIT: Aw, flatlight is looking way too hard to make. I suppose I do have a workaround to this difficulty. Make up my own expression, and make my own varient of flatlight. I don’t think it should be hard to make. I can certainly do it with one of the dodge varient. But, I suspect it probably won’t turn out too well, but not sure about that. Logarithmic Dodge modes do have some similarity with flatlight, so I can use those mode to mimic flatlight with hardmix conditions.

@DGM Any advice on flatlight mode?

I’m experimenting with layermode.exe, and I find that one section is very similar to (0.5*512)*a/(255-b) assuming the end result determines 8-bit output. If I do a section where inverted hardmix mode, and regular hardmix mode mix, it is simply restricted to the intersection of the hard mix mode, but swapping layers, and inverting. This should lead me to something very similar to flatlight without being flatlight.

Hmm, mixing softdodge, and softburn mode with hardmix conditions would do the trick. I looked at the contour plot, and it seem like the solution. I shall check. My solution works just fine for linear space. Non-linear space, not so much, but well, it is what it is.

I’ll release the patch now.

48

At this rate, we might need options besides opacity for blending - for instance, to control the number of levels for flatlight or the hardness of bomb blend.

49

Finished the mesh blend filter and remade the bomb blend filter to reflect it. There’s also that JIFF self-bomb thing that I demonstrated earlier. #@gui Mesh blend : fx_mesh_blend, fx_mesh_blend_preview()#@gui : note = note(" - Pastebin.com

50

If you can implement softdodge and softburn, flatlight is just the piecewise combination of the two, split along the FG=BG diagonal. Since both softdodge and softburn are piecewise themselves about the other diagonal, there end up being four mask regions.

% conceptual 'flatlight'
topmask = FG>=BG;
R = softdodge(FG,BG).*topmask + softburn(FG,BG).*(1-topmask);

As far as performance in linear RGB, I really haven’t ever explored that.

The LCH/HuSL/HSY modes aren’t something I expect would translate well, or at least not in the same way I’ve implemented them. For example, IMBLEND uses some unconventional features of the LCH conversion tools due to the way IMBLEND is expected to be used. Specifically, IMBLEND’s inputs and outputs are always RGB of standard data range. It does chroma truncation in the polar model before converting back to RGB to keep everything in-gamut and limit hue/lightness distortion. This works sufficiently for a single conversion, but results in chroma compression with repeated use. Implementing these blends in an environment where non-destructive working methods are possible would probably render my code a poor reference.

The HuSL/HSY conversions don’t have the same problem, but I have a feeling that most people would find them superfluous.

As much as I think that the parameterization is a good feature, I don’t think I can reasonably expect it to catch on in existing software. While many of the modes unique to IMBLEND are designed around the flexibility, some do not necessarily require it. I might find it objectionable to use them without that flexibility, but I’m basically the only person on earth who has used them long enough to develop such expectations.

Modes like ‘flatlight’, ‘easydodge’, ‘easyburn’ can work well with defaults. Consider that I’ve parameterized my implementations of ‘overlay’ and ‘linear light’, and yet people use conventional versions of these blends every day. Others like ‘superlight’ might work sufficiently at some other non-default parameter value. It’s modes like ‘near’, ‘far’, ‘curves’ and the mesh modes that are the sort that are too dependent on their parameter to be useful without it.

51

For what it’s worth, I updated some FEX stuff tonight and figured I’ll offer up a newer copy of the code.
imblend_short.zip (2.2 MB)

Of what’s (potentially) relevant to this topic, this was mostly a bit of new and old ideas to clean up the “light” (i.e. contrast) modes.

  • Added ‘softlighteb2’, a parametric version of the most correct (symmetric, continuous) method, and added comparisons to the pdf.
  • I removed ‘softlinearlight’, since it’s just a simple transpose of ‘linear light’. It technically doesn’t belong in this category anyway, since it has no neutral response.
  • I added an old variant of ‘flatlight’ which has some niche utility, but comes with caveats.
  • I added ‘easylight’ for sake of completeness. The ‘linearlight’, ‘vividlight’, ‘flatlight’, and ‘easylight’ modes are all combined versions of ‘linear’, ‘color’, ‘soft’, and ‘easy’ dodge/burn modes.
52

FYI, the formula for PDF 1.7 (PS) soft light has an additional term. I wonder what would change. Looking at D(x) in isolation, the two curves don’t intersect at 0.25.

image

53

Not sure why bump this thread since it was concluded after I pushed a full set of blending modes to Krita, but I’ll start a new thread on experimental blending modes and idea to it.