EDIT: Please read final part of this post.

Hi, I'm wondering what would be the equivalent of 1 in the Pegtop code for reflect

f(a,b) = a2 / (1 - b)

Source: http://www.pegtop.net/delphi/articles/b ... dratic.htm

Code: Select all

if b = 255 then
  result := 255
else begin
  c := a*a DIV (255-b);
  if c > 255 then result := 255 else result := c;
end;

Using the pegtop reference, I assume that zerovalue means the max value. So therefore, the code I believe would work in KoCompositeOpFunctions.h would be:

Code: Select all

template<class T>
inline T cfReflect(T src, T dst) {
    using namespace Arithmetic;
   
    if(dst == UnitValue<T>())
        return UnitValue<T>();
   
    return clamp<T>(div(pow(src,2), UnitValue<T>() - dst));
}

I'm starting to think it's UnitValue<T> that's the correct answer.

On that note, here's the current code for freeze

Code: Select all

template<class T>
inline T cfFreeze(T src, T dst) {
    using namespace Arithmetic;
   
    if(dst == ZeroValue<T>())
        return ZeroValue<T>();
   
    return clamp<T>(UnitValue<T>() - (div(pow(UnitValue<T> - src,1), dst)));
}

Is this correct?

EDIT: I'm compiling Krita now.

Damn... I gotten these errors
EDIT: Now I managed to get to compile, but there's these error message -

Code: Select all

collect2: error: ld returned 1 exit status
libs/pigment/CMakeFiles/kritapigment.dir/build.make:1472: recipe for target 'libs/pigment/libkritapigment.so.17.0.0' failed
make[2]: *** [libs/pigment/libkritapigment.so.17.0.0] Error 1
CMakeFiles/Makefile2:5713: recipe for target 'libs/pigment/CMakeFiles/kritapigment.dir/all' failed
make[1]: *** [libs/pigment/CMakeFiles/kritapigment.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2


EDIT: I finally gotten Krita to compile with my new codes. I am compiling, and then it'll be on the testing page.

Finally created new blending modes for Krita

Heat Blending Mode


Reflect Blending Mode


Freeze Blending Mode


Glow Blending Mode

Decided to post some more here to update this thread. I have created 7 new quadratic blending modes, interpolate (only works on float images), penumbra mode, and softlight pegtop, and 3 negative blending modes. Now, I am testing photographs since I can't really paint on a linux VM for testing, and that linux VM was used for coding since it was the only way I could have compiled.

Here's a document which can be used to infer the property of new blending modes. - https://phabricator.kde.org/file/downlo ... Series.pdf

As you can see, of all the blending modes, I have decided to make ones that are viable for testing.
[*]Softlight Peg-top
[*]Interpolate
[*]Penumbra Series
[*]Reflect
[*]Glow
[*]Helow
[*]Frect

Reason those are viable:

Let's start with softlight pegtop. The reason I have decided to make this despite that other softlight blending mode exists is that there was a claim on Pegtop website that it solves the issue with Photoshop softlight mode. Particularly white area excess, and black area excess. I have tested, and Pegtop softlight does solve that very problem with other two softlight mode. Pegtop also preserve details better. But, the result aren't so different than other softlight with the issue of those softlight blend modes solved.

Interpolate is simply a better version of Allanon Blend Mode in many cases because more details would be apparent, and there's actually a functional difference from 50% opacity. Theoretically, there's no reason why this should be rejected when allanon blending mode exists, and this does more.

Reflect and Glow. They're simply color dodge that follows a quadratic forms, and thus for some applications, they can be very useful because of that property. However, I am not sure how viable they would be for painting. One thing to note that these blending modes exist in Affinity Photo, and Paint.NET. So if these modes gets accepted, you can actually have greater compatibility with other apps which is always a good thing.

Helow, and Frect, just looking at the pdf document, it's clear that these blending modes have less discontinuity (discontinuity disappears altogether with float images, and less visible in 16-bit integer). In some way, they can be better for painting just because of that property. They also seem to emulate overlay, and in many cases, the results are arguably a slight better with helow and frect than overlay and hard overlay. There's also the slight burning in those blending modes while preserving some properties of one of the two layers.

After testing more of the Helow, and Frect blending mode, it seem that they would benefit matte painters by a good margin because of their properties of preserving details of one layer better than other blending modes, and their continuity. Even with color adjustment, those details still get preserved. So, there's those benefit of those modes. A downside is that they suffer from the very issue of brightening colors where they're not suppose to show up on. I can't fix that issue even with conditions implied on coding.. But, even with some similarities with overlay and hard overlay, even colors are different, and this is one other way I can see how it may benefit matte painters. You may want similar result with overlay, and maybe a few more blending mode, but frect/helow gives a slight different colors which might be more into your taste.

Penumbra series are rather different in the sense that you cannot get the same blending with other blending modes. You can get close, but it's not going to be the same thing at all.

The ones that will most likely get rejected are:
[*]Heat
[*]Freeze
[*]Gleat
[*]Reeze

Reason for rejection at this point:

Even from the inferring from the pdf document, it's clear those blending modes are not viable for painting usage at all nor other purposes. Many areas would just either get black and white. But, I can't say this for sure as this is something that needs testing. Maybe they could have a use for toon shading considering their properties, but that's about it. They're not useful at all from my perspective. If a painter mentions how they can benefit from the properties of blending mode, I believe that painter should show how it can be used.


Ooh, and let's talk about negative modes
[*]Negation
[*]Phoenix
[*]Signed Difference

The reason I wanted to have negation mode is that it's a blending mode that exists within other software, and why not have this when other negative modes exists on Krita even though they're not practical for most usage other than color themes. Phoenix is less used, but it's also used in a few software. Signed Difference is the most interesting one because you can actually perceive differences of images better than the standard difference. Signed Difference is more likely to be accepted than the other two, but negation only saving grace is it seen usage of other programs, and its interesting property of preserving images in some areas.

Nice work!

How can I try them? Maybe those you consider material for rejection are not as bad as you think.

:]

ghevan wrote:Nice work!

How can I try them? Maybe those you consider material for rejection are not as bad as you think.

:]

If you know how to compile, git pull Krita and git apply reptorian/blending modes and compile Krita.

You can look up additional blending modes into kde phabricator website for more details. Leave a comment there for blending modes review.

Also, Interpolate do not work on integer images. Quad blending modes has the same bugs as Color Dodge and Parallel blending modes. I refer that bug as ZX Spectrum bug because "binary channel values" show up in places where they are not to show. These will go unsolved for a while. I can only reduce ZX Spectrum bugs.

More updates here. All Quad modes works as expected and consistently. I ended up creating XOR mode, but only with indirect proof of concept coding and experimenting. The thing is the code does not work for anything higher than 8-bit integer, and it is only for demonstration purpose, but it is possibly feasible. There's also some issues in some places as it's using a psuedo-xor algorithm which only gets more accurate with more iteration.

- https://i.imgur.com/twjExDn.png

I also have tested one obscure use for XOR blending mode - Continuity Check and Reference. Also can be used for generating patterns, but if XOR texture is up to your liking, then I guess it's useful there too.

- https://phabricator.kde.org/file/data/r ... sage_2.png
- https://phabricator.kde.org/file/data/7 ... ge_one.png

There is some use other than that I have found.
- https://www.wikihow.com/Create-a-Blast- ... -Paint.Net
- https://forums.getpaint.net/topic/3321- ... -gemstone/

Those are done with Paint.NET, but it can be used with the fake xor code found in KDE Phabricator.

Also, apparently considering the code avoids the usage of binary operators, XOR can also be done with float images, but the thing is that it's not done. Right now, the image below is indicative proof it can be done with float images. The image here was generated by the float-xor blending mode found in KDE Phabricator.

- https://i.imgur.com/zXaGzS6.png

The thing is in here the half is not exactly half, but however if you were to take a look at the generated .kra file, you'll note it follows the same pattern as the one in integer xor for the second largest square iteration. If you put it in your calculator, you'll find 128/255 > .5, and in the float xor image, if it a little over .5, it will automatically be considered as that. .75 is also observed within one of the intersection.

So, I came up with this theory that 10 iteration of float xor base can be used for 8-bit integer, and 18 iteration of float xor base can be used for 16-bit integer while float images should use 48 iterations at most. 10 iteration of float xor base converted to 8-bit RGB integer images would not be different than the one generated with Paint.NET.

XOR can also be used for image analysis, and in some cases, even better because it can be used to prove a image with very slight global iteration that won't be shown that much in difference or signed difference is in fact different than the unaltered image.

Also, the principle of psuedo-xor can also be used as a base for converting shades of gray into lines based on even/odd value or checkerboard blending modes, so if you want those for testing, I will be open to creating those codes.

Another update - I learned how to work with ColorSpaceMath, and that would mean that I can finally finish up not working blending modes. I believe Interpolate blending mode can be made to work on all color space model without problems.

As for XOR, results partly works for 8-Bit Integer, but I'm not very confident about it. Even works on 16-Bit Integer, but fails on 2 Quadrant. I will have to speak with someone about that.

Float-XOR is possible as well. They'll be separate unless I can somehow make it work together. For now, I will need to solve quirks of XOR that is not seemingly solveable. If it can be solved, there will be Float XOR 8, and 16.

I won't do contrast-negate from Affinity. Totally useless.

All Blending Modes expected to finish next week.