Tested with Krita 5.2.9, 5.3 alpha and 6.0 alpha (Windows 10) - no pen, only touchpad of the notebook.
Brush (pixel engine) is set to “Build up” in the settings (all pressure settings are off). As I understand it, in this mode the “Flow” settings get ignored (they don’t have an effect anymore) and “Opacity” acts like the “Flow” parameter.
This mode builds up color in a single stroke if I paint over the same area multiple times (like with a real pencil on paper where you move it forth and back without lifting it).
What I expexted:
Regardless of what “Opacity” I set for the brush, I always can get 100% color.
(because Opacity in build up mode is actually Flow).
But as shown in the screen shot, if the Opacity is at a low level this does not work. I paint endlessly over the same area but don’t get to 100%.
Changed in version 4.2: In Krita 4.1 and below, the flow and opacity when combined with brush sensors would add up to one another, being only limited by the maximum opacity. This was unexpected compared to all other painting applications, so in 4.2 this finally got corrected to the flow and opacity multiplying, resulting in much more subtle strokes. This change can be switched back in the Tools Settings, but we will be deprecating the old way in future versions.
So since they get multiplied this means that with values of one and smaller (so with very low opacity) it will never get any increase and you can never get more opacity.
Thanks @Takiro and @Michelist,
I watched the video and read the manual in the past.
But I think there is not a clear explanation of Opacity and Flow with respect to build up mode.
It seems in build up the Flow parameter is not used at all. So, there is no multiplication of Flow and Opacity in the current versions of Krita.
Only the Opacity is active but it is acting like Flow.
The question is about the algorithms behind this Opacity.
There seems to be some math that takes the initial value (see the 1% example in my screen shot) and adds more color based on some coded rules. But for some reason it was decided to code it in a way that:
if initial value = 1% than never add to 100%.
But I don’t get why it is like that. If I add e.g. 1000 strokes with an Opacity of 1% (= Flow 1%) on top of each other, I would expect that this leads to at least 100% color in the end.
Please note: This is with using no pressure sensitivity. The Opacity stays at 1% like with using a mouse without pressure sensor.
When it’s really just a simple multiplication, so basically canvas color = brush color • current canvas color the canvas color will never be different when brush color is 1. This is a simplification of course but my assumption is that something similar is happening. So even after thousands of strokes nothing changes because x times 1 is always x again, even after many iterations.
Multiplication was mentioned in the manual but with respect to wash mode.
But regarding built up mode is mentioned that “Will treat opacity as if it were the same as flow”. Thats all about it.
So I am just guessing and hope somebody knows how build up mode is expected to work.
After further testing I think it is caused by 8bit color depth. If I set the document to 16 bit it works as I expected it. So maybe rounding errors or something like that in 8 bit. Another reason why I prefer to use 16bit
I tried with 16bit linear profile and gamma 2.2 profile - it works in both cases.
Checking the color numbers, 16bit integer isn’t perfect either. With pure green on black I go from 65535 green to 65486. On 8bit it’s 255 to 206. Interestingly the difference in both cases is 49, suggesting they have the same problem. On 16bit it’s a visually indistinguishable .07% difference, but on 8bit it’s huge 19% difference.
Can somebody be so kind as to confirm the issue in the bug tracker (or should I confirm it myself)?
I have noticed that there are hundreds of bug reports with state REPORTED but they are never confirmed or have any reaction at all.
Yesterday I watched a few and found already ones which are “user error”, or can’t be reproduced etc.
Is the kde bug tracker still a relevant place for tracking Krita issues? To me it seems there are users reporting something but not much community activity about doing the next steps like confirming the report etc.
Generally you shouldn’t confirm your own issue, someone else should do it to ‘confirm’ more than one person can reproduce it.
The fact that there are hundreds of bug reports with no reaction stems from the fact that there are hundreds of bug reports; it’s a lot to handle, especially when a lot of them are poorly reported.
The dev team’s been busy with large projects (Text Tool rewrite, Qt6 port, etc) so the number’s been creeping up again. I’m guessing there might be another ‘community bug hunt’ at some point in the next few months.
In my eyes, this is mainly because of two reasons: Users reported bugs without discussing them beforehand in the forum, additionally these bugs often were not announced as reported in the forum. And the bugs you don’t know of, you don’t confirm.
We also have, at least felt, a loss of technically skilled users that is greater than the number of people who (should) fill their places. I am also able to help less and less here, as my strength simply does not allow me to be as involved as I was two years ago.
This is the next problem: Please excuse the wording: As pretentious as it may sound here, users with little to no experience, when it comes to handle a computer or the programs they installed on their PCs, report issues that happened in front of the PC as bugs, because they simply do not understand the connections that lead to something not working the way they want it to. In this context, users who are bursting with self-confidence and a lack of competence are very “busy” reporting things that are (no-)thing.
It definitely is, but as you can read in the post by @freyalupen who posted while I was translating my text, the developers are having trouble coping with the waves of error messages arriving at the bug tracker “beach”.
It is therefore a good idea to repeat last year’s bug hunting month more often in order to get to grips with the mass of bug reports.
Are the devs expected to monitor the bug tracker?
They are only a few as I understand it and I geuss they are busy designing Krita and writing code.
In that case it makes sense to make additional bug triage runs where hopefully at least a few normal users help out. And maybe a “needs information” state that does not get answered within a certain amount of time should automatically be closed. Maybe this way it is possible to get rid of some of the 701 reported bugs without confirmation - the oldest one is from 2016
I guess that only really hazardous bugs can expect a quick reaction. Currently, there are only 5 full-time developers left, if I’m not mistaken, and they monitor the bug tracker. And from those left are at least two not in the best shape health-wise if it is right what I read out of the messages from “dev-land”, one of them has post covid, the other I don’t know. On the other hand, I see all of them fully engaged working on Krita, so I’m sure that nothing gets ignored, but not everything needs the already mentioned quick reaction, although the reporting users often expect exactly this for themselves and “their” bug.
Then, there are some of the very knowledgeable users of the forum who are no longer as active as before or even left the community, so from the forum side there is also less reaction on (some) bugs because of this loss of expertise.
Maybe I’m too pragmatic, but in my eyes it is not a problem if I can reach my goal with other means as I expected initially, because something is currently buggy, like currently some functions of the text-tool, as long as this other means (workarounds) exist. But it can of course be inconvenient and time-consuming to work around some issues, like with the text-tool to start an older or a Krita Next version, to achieve what the release version currently does not offer.
I totally agree. If one would want to have priority there are commercial vendors who offer support contracts for their products (at a high $$$ of course).
