Improve Brush Opacity handling.
Open, WishlistPublic

Description

Several people have commented that opacity seems to work odd for them.

On the left is b) basic 2 opacity, and on the right is b) basic 4 flow opacity. The only difference is that the right one has the flow curve enabled. It seems that the flow is cut off by the total opacity instead of the opacity of the stroke at that moment, making flow difficult to control.

https://forum.kde.org/viewtopic.php?f=288&t=136165
https://forum.kde.org/viewtopic.php?f=139&t=152017

I am making a Krita Abyss task for this because I suspect it is quite complicated thing to fix, but I would like to discuss it at the sprint.

woltherav triaged this task as Wishlist priority.
wbrown added a subscriber: wbrown.Jan 23 2019, 5:19 AM

I'm not sure if I should put this here, or on the forums, but after looking at it for a bit, I think I've found the root of this bug. It's mostly caused by a problem in the Alpha Darken Composite Op, and fixing it only involves changing a few lines of code.

Basically: when the dabs are blended into the stroke, flow is used to LERP b\w two values (zeroFlowAlpha and fullFlowAlpha).
fullFlowAlpha is the alpha value that an opacity-only brush would give, as you would expect, but zeroFlowAlpha is always darker than (rather than lighter than) fullFlowAlpha, which is where the problems arise.

The dab opacity is also premultiplied by flow, which also causes complications.

the fix is basically:

  1. don't premultiply opacity with flow
  2. use dstAlpha for zeroFlowAlpha.

There might be another reasonable formula to use for zeroFlowAlpha, but I have no idea what the intuition behind the current one is, or what it's trying to accomplish. Just using dstAlpha makes it simpler and easier to control.
This does mean that flow-only brushes behave slightly differently as well, but not noticeably, in my opinion.

some comparisons of strokes (current Krita on the left, my patch on the right):

I don't know what the process is for bug fixes, feature implementations etc., but I would like to send a diff of the changes so devs can try it out, see if they think it's better, etc.

Hey!

Cool that you managed to make a patch! You can submit it by making a review request(press the star in the topright next to your name). You will need to select krita as the repository, and as the reviewers, and you'll need to point them at this task and the forum thread so you don't get a confused reviewer.

Deevad added a subscriber: Deevad.EditedJan 23 2019, 2:18 PM

Hi,
Thank you for taking care of this (huge) issue, the screenshot looks really promising.

I remember when Animtim found a way to add the flow paramater inside the Pixel Brush because when I started to paint with Krita we had only choice between build up or wash blending mode and spliting the two type of opacity like that was nearly impossible to get all the variation we have today. I always knew something was 'off' with the flow, but worked around it by adapting all the settings as I could to reach the painting effect I wanted.

Fixing this issue is major. It would probably impact all the brush preset behavior created before pushing something like that I imagine. I'm in favor of the fix (of course) but we might also consider not only redoing the default brush pack, but also 'porting' automatically the old brushes preset behavior and setting or I anticipate drama for trained artist with brush preset that have a specific behavior. I'm not sure this is safe to push in the current progress of the ressource system. Imo, this is a fundamental change that would need a major version change in case retrocompatibility is not perfectly possible. I'm affraid it will break the custom brush preset of users.

I'm right now in finalising my next episode of Pepper&Carrot (release tomorrow) and I'll be able to test tomorrow. Thank you again for looking at this issue! This is will really improve the brush system at the root.

As deevad said, thank you very much for this patch, and from initial testing it seems to be a desirable change. However as deevad said, all the brushes needs to be changed to incorporate this new behavior and also we need to update the documentation stating this change. We need a proper plan to roll out this change.

This patch looks very good! Though +1 that it needs a solid update plan...

@Deevad Flow was already there but only as static value inside the opacity tab, I just decoupled it in its own tab with dynamics ;)

I agree with everything said here. I think is good for Krita to fit the standards when we are talking about basic features. So for me is a good oportunity to fix something we have used to ( a bit weird in some cases).
Breaking something that a user has created (custom brushes) is dangerous. i agree with @Deevad worries.
And also agree with @kamathraghavendra we have to take in mind the manual too and not loose coherence between what the softwares do and what the users read when they are learning.

I will stay tuned to find a nightly build and give feedback.

Hi, picture on top: I ran tests to compare 4.1.5appimage (left) and git~master with the flow patch (right).

About existing/default paintoppresets

I tested three default ressources and one custom using flow (static) or with sensors/curves.
In all cases, the resulting brush preset was different, but very usable and I had no feeling of being broken, it was just different.
But when both Opacity+Flow had pressure curves; the result is really different...BUT...lovely.
In general, that's really ok.
conclusion: I'm OK with pushing the patch asap in official releases, as it is, without bringing modification to the paintoppreset.

Advices/Receipe for portage of old paintoppresets

In release notes it is interesting to add this informations for those who wants the same rendering or who have mission-critical brush presets:

For old preset with dynamic curves on Opacity/Flow:

  • Desactivate Pressure sensor on Opacity and keeps only Flow.
  • Switch max of the Flow slider to 50%
  • Increase how hard is the curves.

With this routine, I'm able to match 100% of the time the old rendering.
Here is a GIF ANIMATION I made to show this portage process, it can be used to illustrate release notes:

All in all, big thumbs up!

Hi, all!

I've just pushed William's patch into master. The new mode can be configured globally in Krita settings (it is on by default).

Hi all
Happy to see this is evolving ;D
Referring to Deevad last comment showing the prefs with patch, i don´t see
this as a need. After testing a lot, the "flow changed" release, for me it
is better, and keeping an older version can be more confuse more new users.

Is the "creamy effect" selected by default? if yes , then i agree to
integrate it in preferences. If not i don´t agree.
New users are not even worried about these variants. They look for the
"Patched mode" based on another softwares experience.

Anyway i think Krita 4.2 is going to be full of nice interesting features,
thanks for the hard work.

El vie., 1 feb. 2019 a las 11:37, Dmitry Kazakov (<
noreply@phabricator.kde.org>) escribió:

dkazakov added a comment.

Hi, all!

I've just pushed William's patch into master. The new mode can be
configured globally in Krita settings (it is on by default).

F6580852: image.png https://phabricator.kde.org/F6580852

*TASK DETAIL*
https://phabricator.kde.org/T8576

*To: *dkazakov
*Cc: *scottpetrovic, ramonmiranda, timotheegiet, kamathraghavendra,
Deevad, wbrown, rempt, dkazakov, woltherav, jasperh, jacobhe, mregdos,
razcore.art, jhoolmans, amedonosova, eoinoneill, emmetoneill, keeganh,
stevenp, hellozee, jbaran, neviril, rchakrabarti, peterkovar, zilong,
razvanr, char1a, dimitard, hanu, franciscofernandes, jose.arroyo,
bruceoutdoors, qwer_ty, rjquiralta, alvinhochun, ali-mohamed, jospin,
justmesr, irinarempt, raphaelc, nicholasl, tokiedian, Bollebib, jounip

the "creamy effect" selected by default nice , then i agree to integrate it in preferences.
New users are not even worried about these variants. They look for the "Patched mode" based on another softwares experience.