Color Smudge Brush Opacity Affected By Smudge Length

Over the past month, I have been testing an experimental feature for the smudge brush engine that allows the user to control whether or not the smudge brush blends with alpha transparency. (Selective Color Channel Blending for Smudge Brush)
I have just noticed a potential bug in the smudge brush engine where the maximum opacity of the brush is affected by the smudge length parameter. As the smudge length is decreased, the maximum opacity of the brush is decreased. This bug occurs with both dulling and smearing mode in the smudge brush engine.

After further testing, it appears that this bug exists whether or not “smear alpha” is turned off in the alpha build as well as in the current stable version 4.2.9 for Krita. I have just created a bug report on the KDE page (https://bugs.kde.org/show_bug.cgi?id=420600); however, it appears that this bug may have already been reported back in 2014 for version 2.8 of Krita (https://bugs.kde.org/show_bug.cgi?id=329557). The thread for the older report from 2014 claims that the bug had already been fixed, but the same bug appears to have resurfaced again. Whether or not this is actually a bug, it is critical for this behavior for “smudge length” to be corrected in later versions of Krita. Once the preserve alpha/ smear alpha toggle feature is added to the next stable version, this undesirable behavior will prevent the smudge brush from using full opacity when the smudge length is less than 100%.
P.S. I have noticed that Smudge Length only behaves properly only when Color Rate is Set to 0%, otherwise this setting will affect opacity.

I’ve spent some time thinking about this issue with the smudge brush and it appears that five default presets by @Deevad as well as five watercolor presets by @Pesi and possibly four presets by @RamonM in his digital atelier pack might be affected by changing the behavior of smudge length in the smudge brush engine when color rate is set to greater than 0%. These authors might have to check and make sure their presets don’t get severely damaged by changes in the behavior of Smudge Length in the smudge brush engine.

Thank you @Rigognos for your research, bug report and testing. Testing Krita 4.3x for me is harder because I have to build it and switch my personnal preferences to not damage my production version (4.2.9appimage) and I don’t feel 4.3 is solid enough yet for using it as my main (last time I had still a lot of jump of settings while switching presets and micro-freeze while switching layers) . I try to jump on it for a small hour on a weekly basis in general. I’ll try to look at this behavior on my next testing session.

Hi

On my side, I have 2 users account on my computer:

  • One for ‘production’ (ie, a user session on which I use a stable version of Krita appimage)
  • One for ‘testing’ (ie, a user session on which I use unstable version of Krita, appimage too as I’m not yet motivated to build it by myself)

As I use 2 users account, modifications made for a user do not impact the other user account as configurations files are located in different /home/xxx/.config and /home/xxx/.local directories
Same for binaries, the appimage are locates into different /home/xxx directories

Just have to switch session from user to another one when I need to switch my activity

The only thing that i don’t know about is the build process, but I don’t think that doing a build with a user can have an impact for another user.

Grum999

Hi @Grum999, thank you for sharing your setup. It looks effective and sure it protects your production environment. But a full new user/home folder account isn’t enough flexible for my usage. I know how my energies got down here each time I’m setting up a system where I need “to unclothe Peter to clothe Paul”: the friction always makes me keep a single unified system on long run.

For appimage testing; Anna Medonosová shared on IRC chat with Krita dev a small script to execute appimage to external preference folders: https://invent.kde.org/snippets/741

For Krita build; I heard often that one can change the PATH/ENVIRONEMENT/LOCAL on the fly before executing it. But I never found a way to do it.

Yes I understand :slightly_smiling_face:

Thanks for the share! :+1:

Grum999

@dkazakov has built an experimental solution to fix the problem where smudge length affects the final opacity of the stroke earlier this week:


Currently, the build does not blend with alpha channel transparency and the fix is only applied to smear mode for smudge length. I also have not been able to get smudge length to respond to pen pressure on my tablet in this experimental build. Before implementing this change in brush behavior, I would like @Deevad to test to see how this build affects the behavior of the default presets.
Below is the link to the Bugzilla page:
https://bugs.kde.org/show_bug.cgi?id=420600#c6

Hey, thanks for the ping. I’ll note on my to-do to build and test kazakov/separate-smudge-rate; it might be difficult if it is based on git~master and easier if this branch is based on 4.3; I’ll have to investigate.

Mmm… Unfortunately, it is not a Krita branch ( I tried the classic: git fetch, then git checkout kazakov/separate-smudge-rate but “error: pathspec ‘kazakov/separate-smudge-rate’ did not match any file(s) known to git”)

erm, isn’t this in master/krita-4.3 already? It’s a checkbox under the smudge length option?

Are you thinking of the “smear alpha” checkbox? That is a separate feature. The build I shared a link for just now from @dkazakov actually changes the behavior of smudge length in the smudge brush engine.

Hi, I agree, we need to review all the brushes personally to make sure they are not making weird things.
Please @Rigognos could you tell me which brushes do you think can be affected in Digital Atelier? Thanks.
Because I am updating, and I was testing the feature but not too much. Take into account that time is limited and Krita is changing lot of interesting things. :wink:

Any preset that uses the smudge brush engine where color rate is greater than 0% may be affected by this change in the brush behavior proposed in the experimental build above. For the default presets by @Deevad: i) Wet Bristles, i) Wet Bristles Rough, i) Wet Knife, and i) Wet Textured Soft. For the Digital Atelier pack by @RamonM: DA Oil 01 Detail Lines, DA Oil 11 Rake Wet, DA Oil 12 Color Fade, DA Oil 13 Blocking, DA 14 Oil Round Wet, DA 01 Pastel Pencil, DA Pastel 05 Basic Blend, DA Pastel 06 Block, DA 09 Pastel Oily, and DA Pastel 10 Soft Touch. For the watercolor pack by @Pesi: PW-12-wetonwet-side, PW-13-wetonwet, PW-14-blendnpaint1, and PW-15-blendnpaint2. In the @Rakurri Brush Set v1.0: Rakurri Blender Sahblend, Rakurri Brush Squarepaint, RakurriNoTilt Brush Squarepaint. If there are any other smudge brush presets in popular brush packs that make use of color rate, please post them here as they may also be affected by the change in brush behavior.

So, I tested this just now. It seems that the difference is quite big, as well, it seems that if you make a rather convex opacity curve (much like how you’d fix flow/opacity curves after the creamy flow mode was introduced), you get behaviour that seems similar to the old behaviour. This needs testing, but it does feel like this to me…

2 Likes

Hi, all!

Here is a testing AppImage for the proof-of-concept. Please remember, that this code is not yet intended to go into Krita codebase. There is not much use in duscussing what presets are affected. The main question I’d like to know: “is this version of sliders more convenient for creation of new presets or not?” The patch does change how smearing effect is built up in the brush, so I need your opinion on “whether this effect is better than the previous one?”. If you think that this version is better, then we’ll have to add a checkbox for it. The old and new versions are not compatible from mathematics point of view.

So, questions:

  1. Is this version of sliders more convenient for creation of new presets or not?
  2. Is new effect of smearing better than the old one?
3 Likes

@dkazakov Thank you for the easy Appimage. I spent the last hours testing it since you posted and doing way and back between 4.3beta appimage to understand the changes.

First, I listed the preset in 4.3 using Smear and tested them without (top) and with the patch (bottom):

As you can see; the change is obviously very dramatic for them.

Then I painted with random new presets I made ( mostly derivating existing ones):

To answer your questions:

Is this version of sliders more convenient for creation of new presets or not?

Yes, sliders can produce more effect and the variation from 0 to 100% is very obvious. It inputs much more control in the preset creation.

Is new effect of smearing better than the old one?

It is still the same effect of smearing, so the effect in itself is not better or worst. But it offer new way to setup the effect and get “stronger and longer” smearing; and this is something new. This patch makes possible the creation of infinite smearing preset (very smeary, like painting with a iron on hot wax, a rare technique.) that makes the pixels area a bit more elastic. It also gives more control to create probably in a easier way subtle Color Rate and Opacity mixes.

My opinion about it:

First; like it. I had quick fun with Smearing based brush and the patch. This patch makes the sliders feels more WYSIWYG and with the preview of the brush stroke in the brush editor it works really well. It also allows stronger effects, and that’s great. But it would break also all previous smearing based presets badly (their effect being way way way too strong).

So, this patch is welcome, but it would require a mechanism to do the reverse math for the legacy smearing brush presets.

2 Likes

I find the new behavior more useful when replicating oil paint presets in the smudge brush than the current behavior, but as you mentioned you might need to include a “legacy mode” switch to retain compatibility with older presets. The fact that the smudge length now remains consistent as color rate is increased to greater than 0% with this build makes it easier to predict the behavior of a smudge brush preset when creating a brush in the settings.

@Deevad is creating a portable version of Krita an option on the version of Linux you’re using?

@Rigognos : I totally see what you mean about oil paint. I agree. I think @RamonM will really like this change, especially mixing this wet wet new smearing mode with his experiments with Lightness brush mask for impasto (I haven’t tested).

About portable version of Krita on Linux; that’s what Appimage are. I don’t have knowledgeto create them myself, but @dkazakov has and made for me an appimage on this thread. It’s a single 373MB file and I only need to double-click on it to launch Krita. I keep many versions on my hard drive this way, and not only for Krita but Inkscape, Scribus and Kdenlive too.

1 Like

Thank you for detailed info and warning. How do you think guys - how much time we will have to test and retweak our brushes to fit to new smudge engine before it will go official? Or maybe automatic preserving old smudge technique for older brushes is really sane idea…

We can have the option for automatic legacy mode for old preset for may be one or 2 krita versions. We can give warnings to brush makers saying that this legacy mode will be gone. So that they get a chance to tweak their brush presets and we also get time to tweak our default brush presets. Then after 2 releases we can remove the legacy mode.

1 Like