Hi!
I arrived to Krita land from the CorelPainter and the only thing that has kept bugging me is that the smudge-brush is a poor
replacement for the bleed and resaturation that painter offered.

Most problematic is that the smudge brush practically ignores what color your choose in the color-selector and no matter how long strokes you draw or how hard you press
you never reach real color-intensity thus your painting ends up looking dull and devoid of life.

Don't get me wrong, the smudge brush is amazing at blending existing colors on canvas, actually it does a much better job than any bleed/resat-blenders i've ever created.

It would unlock some truly amazing potential if it would be possible to add a "color well" section and two dynamics for "resaturation" and "bleed" to the pixel brush,

I did my best to try and describe the effect here: https://github.com/telamon/bleed_resaturate

Pasted a copy below:

The Resaturation and Bleed effect

The resaturation effect reminds you alot about the dulling mode of krita-smudge brush,
but it's behaviour different as it tries to simulate having a physical brush loaded color particles and painting onto a canvas containing wet-color.

Your brush get's tainted with the wet-color on the canvas and slowly as the brush disperses the particles your brush-stroke starts
to paint the color that you actually loaded it with.

The bleed factor creates an effect that at low values reminds you of some kind of digital Oil
while at high-values acts like digital watercolor.

Given variables:

`C` Color selected from colorwheel

`R` Resaturation `[0..1]`

`B` Bleed `[0..1]`

`K` Sampled color from canvas beneath cursor (Sampled continiously)

`S` Sampled color from canvas where brush-stroke started. (Only sampled once)

`N` Number of brush-dabs that were spawned since brush-stroke started.


Given blending function:

Code: Select all

    function blend(A,B,alpha) {
       return A * alpha + B * (1-alpha);
    }


Then:
the function to calculate what color to render a dab during a stroke can be described as following:

Code: Select all



    tint = blend(S,K,B);
    progress = N * R; 
    return blend(C,tint, progress);



Hey! Thanks for humoring me and following the instructions! It's pretty late here, so I'll try to give this a good read over tomorrow

What exactly do you find lacking?

Krita has settings that match one to one what you have described

Well, to be honest, it's not exactly the same, but you can achieve the feeling of the brush that would be indistinguishable from painters and even better tuned for your needs. You have Color Rate, Smudge Length, Smudge Radius and Opacity plus curves to control them and multitude of sensors (not available in painter) to play with. Maybe you should experiment more. Be sure to use 16bit integer per channel though, 8bit artifacts like crazy with all brushes not just smudge ones.

Well, it is a good sign when the basic feature is super close, because that might mean only a tweak is necessary for getting it right. Perhaps Telamon could give an example of where it goes wrong exactly for Krita's brushes compared to painters, because indeed, Krita engine is quite intricate and it might be possible to solve.

I'll try to write down later on an exact overview of how the color smudge brush works, to help identify problems there.

Frostwyrm, I was aware that the smudge brush artefacts in 8bit, but not other brushes, could you give an example of that? I suspect this one (https://bugs.kde.org/show_bug.cgi?id=356462) is involved, but it could very well be a cluster of bugs.

Wow, this is the third time I raise this question and once again I'm completley baffled.
So I did some more testing, mainly just "colorate vs resaturation" , I left opacity on 100% , and disabled pressure modifiers on both programs.

Krita brush i used: https://github.com/telamon/bleed_resaturate/raw/master/dev_colorrate_stops.kpp

The first test gave some really good results! The results are practically identical:


So I moved on to the next issue, and that was my complaint about krita-smudge brush never reaching the color i've picked.
Luckily i managed to reproduce the issue, and feel a little bit of my sanity returning


Basically my issue is the black-rectangles which indicate where Krita's color-rate simply decides that It's already reached it's full potential and stops transitioning into the
pure red. What's worse is that when using the blue box as starting point, the final transitioned color is even further away from the pure red I've selected.

The behaviour I expected is that while color-rate is above zero it should reach the pure red sooner or later given a long enough brush-stroke.

I'll take a look at Bleed .vs Smudgelength tomorrow.
Thank you for your time guys.

EDIT: Did some more testing, and realized that bug only appears at very low color-rate strengths like the brush i was testing with had a strength of 0.08%. painter seems to have similar probems around 0.04% strength.

Hey, Thera! The most obvious artifacts are produced by pixel brushes with soft gaussian tips and low opacity when repeatedly stroking the same area.

Looks something like this:
http://i.imgur.com/mgwAP2J.png

Other low opacity pixel brushes don't feel right too, it's just harder to demonstrate with hard edged or textured presets. When brushing over fully opaque layer there are bands and random patterns where smooth transitions should be and some hue shift is present. On fully transparent layer there's no hue shift but bands seem to be more pronounced.

The bug you've mentioned seems to do with layer composition and this is just brush related. Maybe general purpose math libraries are not robust enough to handle painting apps. Gimp's brushes artifact exactly like Kritas, MyPaints too but differently and much less. Major commercial apps handle 8bit color ok, but the do dithering. Photoshop definitely does it's very obvious.

telamon, that is because you are using 8bit color. Use 16bit integer or 32bit float and everything will be fine. I've tested your brush and it works fine.

No, the layers compositing stuff is also used for the brush engine, because of our color management system.

Both the color rate problem and the brush banding could very well be affected by what I mentioned, though with the brush-banding we might indeed want to think of dithering(Krita needs a lot of dithering options for 8bit in a lot of different places, so I've added this to the pile).

I'll try and see if I can get some assistance from other devs to first fix the opacity bug, and see how that affects the other two bugs.(As wel as the bizarro hue-changing bug when confronting black with orange).

frostwyrm wrote:telamon, that is because you are using 8bit color. Use 16bit integer or 32bit float and everything will be fine. I've tested your brush and it works fine.

Thank you for the tip, it indeed did wonders, what are the drawbacks of using 16bit int-mode? ( Quadruple memory consumpation, lower performance? )

TheraHedwig wrote:No, the layers compositing stuff is also used for the brush engine, because of our color management system.

Both the color rate problem and the brush banding could very well be affected by what I mentioned, though with the brush-banding we might indeed want to think of dithering(Krita needs a lot of dithering options for 8bit in a lot of different places, so I've added this to the pile).

I'll try and see if I can get some assistance from other devs to first fix the opacity bug, and see how that affects the other two bugs.(As wel as the bizarro hue-changing bug when confronting black with orange).

Yeah to be honest I've been struggling with the smudgebrush for over a year soon, I've encountered banding a few times but did't consider it could be a bug

Anyways, I did't have time today to do the bleed vs. smudgelength comparison and probably won't have an opportunity to do so until monday, thank you for your patience. Maybe this thread will turn out to serve a better purpose as an orientation for people that are used to painter.

Double memory usage, same performance, some filters are a little glitched. There is no real reason not to use 16bit int per channel, i never use 8.

Actually, there's another difference to 16bit: the default profile is a linear space, meaning that colour blends will come out much more physically correct and thus pretty and saturated, the down side being that white is a bit more overpowered(more info here:https://docs.krita.org/Gamma_and_Linear).

Don't worry that a feature request turns out as a dud. Discussion helps a lot, for example, I learned something about corel painter's smudge, and I learned about dithering being useful for brush-tips, and how that affects your workflow. It might even be that what I am worrying about is not actually a related bug, which means we'll just have to dig further

So , I've experimented a little bit more with the "color-rate" and created a brush that i'm almost satisfied with.
https://github.com/telamon/bleed_resaturate/raw/master/telamohn_tin_foil.kpp

It seems that Opacity works differently on a smudge brush compared to a pixel-brush.
At first when i was experimenting with the above-linked brush I thought that opacity slider was broken as even on 0% it left a completely opaque trail.
But after a few minutes I realized that a low opacity actually just divided the color-rate and kept smudging my pixels like a rake-tool.

Is it possible to make a smudge brush's opacity behave like a pixel-brush in wash-mode?
I love the color-rate but I'd like to be able to contol the opaque-ness of the brush-stroke.

Thanks!

Is it possible to make a smudge brush's opacity behave like a pixel-brush in wash-mode?

Sadly enough really really difficult. I tried implementing it myself a few times, but I got nowhere.

Ah I see, what about the opposite? Adding color-rate/resaturation capabilities to pixel-brush?

Sidenote, I quickly estimated the difference between Krita's smudge-length and painter's bleed, they feel fairly similar without having done a visual comparison.