No, because the complexity for adding wash is caused by the smudge length/color rate.

Hey sorry for the delay!

I get the feeling something got lost in translation. I understand the complexity of the smudge-brush, It basically works with finely tuned pixel-displacement and adding transparency or wash causes something akin to a time-paradox.

But! The color-well feature has nothing to do with displacement or smudge as it's basically a color-source:


The Resaturation/Colorrate should work practically identical to setting the color-source to gradient for a pixel-brush.
Except that the gradient-start-color is set to the color-under-cursor at stroke-start, and the gradient-end-color is the one you've picked in your color-chooser.
Resaturation-strength basically specifies the location of gradient-end-color in the gradient.

The bleed blends the calculated color towards another sample on the canvas, and the bleed-strength controls the amount of blending.


That way we'd still have all the benefits of the pixel-brush without breaking backwards-compatibility and without having to deal with the complexities of the smudge-brush.
I guess my main frustrations is that I'm trying to use the smudge-brush in a way that It wasn't designed to be used, even though it in some aspects does achieve similar results.

Are my thoughts in the right direction? Is it possible to sample merged canvas from the scope of a color-source?

I get the feeling something got lost in translation. I understand the complexity of the smudge-brush, It basically works with finely tuned pixel-displacement and adding transparency or wash causes something akin to a time-paradox.

That isn't the problem with the wash mode, I am afraid. I wish I could explain the problem, but I sadly am too busy to translate this to human readable text, so I am just gonna link you to the file. https://phabricator.kde.org/diffusion/K ... udgeop.cpp

No worries, I should be able to read that (never worked with KDE libs though) , I actually also been meaning to ask politely if you could point me
to the logic of the color-sources?

Ah! These lines represent the requirements for my experiment,
kis_colorsmudgeop.cpp:234

Code: Select all

            KoColor color = painter()->paintColor();
            // get the pixel on the canvas that lies beneath the hot spot
            // of the dab and fill  the temporary paint device with that color

            KisCrossDeviceColorPickerInt colorPicker(painter()->device(), color);
            colorPicker.pickColor(pt.x(), pt.y(), color.data());


Given I'm able to create a new type of ColorSource, could i theoretically reference to the cursor x,y and the colorpicker object from a ColorSource's scope?

That'd be this one: https://phabricator.kde.org/diffusion/K ... source.cpp