Prevent Blur/Blend Tool from bleeding in from outside selection

[angrymidget4728]

I use the default Blender Blur tool to blur edges

But I’ve noticed that even when I have a selection, the part that is meant to be opaque receives blurring from outside the selection.

This is often the case when I want a wide area soft-blur, resulting in the brush size being larger than the opaque region itself. I checked Tool Options for different settings, but there aren’t any like that.

I tried checking with other softwares like CSP just to make sure I wasn’t making the mistake of blaming Krita for a universal problem and yeah, I was kind of right. The bleeding isn’t nearly as bad in CSP as Krita.

Krita blends really nicely imo (better than CSP) but the bleeding has caused friction in my workflow.
On the flip side, even though CSP doesn’t blend as nicely with a single stroke, it makes up for it by blending waaay more smoothly with multiple strokes.

In CSP, if you use a smaller brush to avoid the bleeding, you can simply go more strokes or harder strokes to create a smoother blending.

On the flip side, if I try to use a smaller brush with harder/more strokes in Krita, it results in a “harsher edged blended blotch”

The only solution I’ve found is for me to be very conscious of the brush size, and also use very light, carefully placed strokes to create a smooth transition.

Otherwise, I end up with a mess like this. See how there are awkward transitions. If I’m not careful, it might go unnoticed on a detailed piece until it’s too late.

[Thrall]

The closest thing is to uncheck the “Smear alpha:” box under Smudge Length option and the cut and paste and reselect the area you want to blur, and then after it’s done merge back down.

Tho I wish there was a don’t sample outside of the selection checkbox. Or vise versa, only sample within selection checkbox.

Usually I change the brush settings to have a very low strength for Smudge Radius in brush settings.
To make it so I don’t have to tip toe as much around the edge. However coming from outside and crossing the boundary causes problems like you mentioned.

[SelectionToolFriend]

the same thing happens with blur filters as well. the selection keeps referencing pixels outside of the selection. This is frustrating as I use another program that doesn’t have this problem. I’m about %60 sure this is an oversight that’s just hardly brought up. the other route is that its somehow intentional i just don’t have the perspective to know why. I’m wondering if this should be submitted as a bug report or not. a feature request at least. would be great if someone with a better grasp on the code could explain what could be going on.

[Michelist]

Hello @SelectionToolFriend, and welcome to the forum!

I would take a two-pronged approach here and both report it as an error, for which I would create an error report, and, in case this is actually intended behavior, create a feature request for it. To do this, I would refer to this forum topic in the feature request and the bug report (and also include a link to it in both) and also refer to the bug report and the feature request in the other report (which is only possible in the first post as a subsequent edit or attached second post, since you don’t know in advance which number/ link the second of the reports will be assigned by the bug tracker system).

If you have never created such a report before, I am attaching my templates for creating a bug report and for creating a feature request, which are partially identical:
Bug report:

If you want, then you can report it as a bug via the KDE-Bugtracking System at https://bugs.kde.org/.

To report a bug, you must register at https://bugs.kde.org/ to gain access to the “KDE bug tracking system”, i.e. “KDE’s bug tracker”. Keep in mind that the e-mail address you use there must firstly be existing / valid and secondly that it can be viewed by any visitor to the site. But the likelihood of your address falling into the hands of spammers there seems to be very low, because the address I used to register with them, I’m using exclusively for access to the KDE bug tracking system and have not had a single spam mail in my mailbox in the years I have been registered there.

You can read what a bug report should look like under Reporting Bugs in the Krita manual (the input mask looks slightly different today), or the User Guide on KDE.ORG, which I like less. Please use the drop-down menus to select the software, i.e. Krita, the version number, the operating system and try to narrow everything down as much as possible using the drop-down menus available there.

Here you’ll find the mask to report bugs in Krita, you can open it when you are logged in into your account (if not logged in it will detour you to the start page):

https://bugs.kde.org/enter_bug.cgi?product=krita

It might be a good idea to include the link to this topic in your bug report so that the developers can read your findings here.

And after completing the bug report, i.e. after you have sent it, please publish the link to the bug report here in this topic.

And feature request:

If you want, then you can report it as a wishbug via the KDE-Bugtracking System at https://bugs.kde.org/.

To report a wishbug, you must register at https://bugs.kde.org/ to gain access to the “KDE bug tracking system”, i.e. “KDE’s bug tracker”. Keep in mind that the e-mail address you use there must firstly be existing / valid and secondly that it can be viewed by any visitor to the site. But the likelihood of your address falling into the hands of spammers there seems to be very low, because the address I used to register with them, I’m using exclusively for access to the KDE bug tracking system and have not had a single spam mail in my mailbox in the years I have been registered there.

You can read what a wishbug report should look like under Developing Features in the Krita manual (the input mask looks slightly different today), or the User Guide on KDE.ORG, which I like less. Please use the drop-down menus to select the software, i.e. Krita, the version number, the operating system and try to narrow everything down as much as possible using the drop-down menus available there.

And after completing the wishbug report, i.e. after you have sent it, please publish the link to the wishbug report here in this topic.

How to think about a feature request (to hopefully create a good one, one that gets considered worth implementing): When requesting a feature, be sure to describe it well. Explain why you want it and why you think Krita and the community will benefit from it. Think of it as trying to sell something, so emphasize its advantages and present it well. When requesting a feature, be sure to describe it well. Explain why you want it and why you think Krita and the community will benefit from it. I think the first part of the manual chapter provides some good tips on this.

Michelist

Add/Edit: I’m too slow, just saw you created the request in between.

[SelectionToolFriend]

Great thank you, I will work on submitting a bug report as well then. I started with a feature request to be safe, as it comes of more as something ‘missing’ rather than the program working unintentionally. I actually didn’t see the guide before making the topic, sorry about that. I tried to keep in mind what I read on the pinned topic and hopefully shared adequate details.