Alpha Smudge - Average - Blending Bug / workarounds?

Edit:
Just to make it short for those who doesn't want to read all:
Workaround is to color pick the color close to alpha.
Explaination: So far, Verve flushes areas with alpha/opacity=0 with actual picked color due to some problems. Read below for more detail.

Hi,

after a long, relaxing break, I touched verve again, today.
But after a minute I already stepped into the most annoying "bug" verve had from the very beginning i started using it.
The way verve handles unpainted alpha space while smudging - averaging- blending.

Smudge-Average-Bug.JPG (44.86 KiB) Viewed 27541 times

Instead of mixing with alphas opacity and color, verve uses the actual selected color.
This is unlogical and unexpected, like a bug. No matter what technical reason.
I am quite sure, that this behaviour ends in the black bug worst case.

Just a guesstimation - it lies in the fact that smudging, blending and averaging (CTRL+SHIFT) uses the active canvas colors and the selected color, but not really the alpha.
I.e. If there is 50% color and 50% alpha under the brush tips canvas, verve still uses the selected color to mix with - even when it's opacity is set on 0.
Strange.

This is such a pity as it makes one of the biggest advantages in digital painting less useful for verve - using layers to add details and smudge and blend them with alpha.

The only "workaround" I know to get decent smudging and averaging is to fill the canvas first, which is not a real workaround at all.
Anything else one can do to avoid this?

If there is technically no other solution than a switch to ignore selected color for smudging, blending etc. I would really appreciate this function.
Honestly a fix would be the best.

[Taron]

The problem lies in the fluid/vector concept. Verve takes the brush motion and records it as vectors. These vectors then push the color and material buffers. It does so by means of essentially looking behind to pull those colors to the current pixel. What happens, when there's a alpha at 0 and color at 0 is that it will blend alpha up, but also the color in, which is black. No matter what logic I've tried to apply, I could never get it to remember that the 0 alpha was not meant to transport any color into the mix. It sounds SOOO trivial, but it is not. Apparently it isn't to me, that's for sure.
My alternative was to use the current color and flush all the 0 alpha area (with a tiny tolerance) with that color. As a result...well... you know the result. I've tried a number of things, but I'm sure there are still a few things left. My last resort was a total change of my system, knowing that it will have to take a performance hit, but would act more as people might expect. I could consider limiting this type of process to areas that have 0 alpha potential, maybe reducing the performance hit to where it's needed only. But well... not so easy either.
So, if you somehow have an inspiration on how to write the code to prevent the color bleeding from 0 alpha pixels, by all means, I'm all ears!

[Taron]

One thing you can do to reduce the issue, but somewhat change the paint behavior is to reduce the layer's OPACITY to like 60%, for example. This way it will simply ignore a good part of the lower alpha, giving you greater tolerance before the mixing behavior becomes obvious.

Almost understood
If you would create a pure smudge brush, ignoring the selected color, it would smudge with black, instead of alpha and color on 0?

I have no idea about coding, sorry.
Maybe a look into the source code of krita, or other open source progs can give some inspiration, as any painting program has to handle this somehow?
https://phabricator.kde.org/source/krita/

Other than that I only have workarounds ideas, which would lead probably into other problems, like using canvas color (the real canvas look) or underneath layers color instead of selected color.
This would lead into less obvious problems, as long as you don't change underneath layer & background....well....OK.....also not fantastic.

OR

"My alternative was to use the current color and flush all the 0 alpha area (with a tiny tolerance) with that color"

I guess you are constantly color picking internally for smudge and blending etc., anyway?
Maybe best would be to combine smudge, blend etc. on alpha =0 (with a tiny tolerance) to use this picked color on active layer, instead of using the current color and flush all the 0 alpha area?

The most practicable workaround I found works exactly like the last I said above.
Colorpick the color close to alpha before smudging - averaging - blending.

Smudge-Average-Bug_Workaround.JPG (48.28 KiB) Viewed 27535 times

I think, that an constant internal colorpicking interval during smudge, average and blend would make the "problem" almost invisible for the user.
That means the selected color is stored at the beginning of those critical actions and restored at the end, or another buffer is used for that.
It could have some conditions that it only starts if alpha / opacity is 0 on canvas, if that would slow down normal actions in problem less zones......

[Taron]

I thought about something like that, but it would be quite awkward and possibly choppy. Blending, essentially is doing that and also shows the performance it represents. What bothers me is that it isn't really a solution. I'll keep pondering over it, but it must not be a work-around, I think.

I thought about something like that, but it would be quite awkward and possibly choppy. Blending, essentially is doing that and also shows the performance it represents. What bothers me is that it isn't really a solution. I'll keep pondering over it, but it must not be a work-around, I think.

What surprises me with blending is now, that it reacts exactly the same way concerning alpha@0.
Put opacity on 0, blending on max and the alpha at 0 area is flushed by selected color.

Blending-Bug.JPG (42.17 KiB) Viewed 27525 times

But with color picking the border color while smudging, blending and averaging along alpha=0 areas I can work quite well.
If one knows how it works, it can be even fun to use it for adding slightly another color while smudging.
EDIT:

Another workaround is to fill (CTRL+SHIFT+F) the canvas with black and opacity @ almost 0. One have to play around with that. Already a very low opacity is damping the "flush by picked color" effect.
A bit more let it completely disappear for a very low (almost invisible) price of grey dust on top.
It then smudges to slightly grey.

Fill_Workaround.JPG (58.45 KiB) Viewed 27524 times

Play around and fill with low opacity white instead.
Works even more neutral, I guess. Still testing.
Ahh, sorry, know you'll have a dark border to alpha. Maybe filling is not THE solution, but black is the better choice.

[Taron]

Hey Knacki, I'm trying stuff right now and I have managed to reduce the bleeding, but not remove it. And there's another fundamental challenge with the principle brush transfer, since GL blending doesn't allow complicated maneuvers, though, they were needed. I'd have to augment every shader to somehow take over the entire blending process, which is not necessarily successful and for sure not easy. I will give it another try, though, not keeping my hopes up too high.
...I will let you know, when I'll have uploaded a new version for you to try!

Thank you very much for your efforts!

[Taron]

Likewise, Knacki, likewise! If I didn't know how much I was doing, I would've almost said you're doing more than me, haha, but no...I'm in action again for some time, no worries!
YOU ROCK!