Bug 448860 - Very low max opacity strokes will never reach full opacity on the canvas
Summary: Very low max opacity strokes will never reach full opacity on the canvas
Status: CONFIRMED
Alias: None
Product: krita
Classification: Applications
Component: General (other bugs)
Version First Reported In: 5.2.9
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-21 01:11 UTC by tomtomtomreportingin
Modified: 2025-04-13 06:03 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tomtomtomreportingin 2022-01-21 01:11:39 UTC
It's possible that I'm just misunderstanding opacity and that this is intentional behavior, but I'm reporting this just in case it's an actual bug.

SUMMARY
If a user has a very low max opacity on their eraser brush, such as 10%, it will never fully erase drawings from the layer. Conversely, if the user draws with very low max opacity, the drawing will never reach 100% opacity. This occurs regardless if the painting mode is wash or build up.

STEPS TO REPRODUCE
1. Create an 8-bit document with two layers, background layer is white.
2. Draw something.
3. Select an eraser brush like Eraser Soft.
4. Set max opacity to 10%.
5. Attempt to fully erase the drawing.

OBSERVED RESULT
There is still a faint rendering of the drawing.

EXPECTED RESULT
The drawing should be fully erased eventually.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian sid
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.88.0
Qt Version: 5.12.12 (appimage)

ADDITIONAL INFORMATION
This issue seems similar to https://bugs.kde.org/show_bug.cgi?id=424075, however my report concerns opacity instead of flow. It does not appear to be a regression of Krita 5.

When you select the faint rendering with the color selector's color picker, it appears as some value like (250, 250, 250), assuming you were drawing in black. However, if you hide the white background layer and color pick it again, it appears as (0, 0, 0), despite the fact that the rendering is still just barely visible.
Comment 1 apelsinchoklad 2022-01-21 06:11:01 UTC
(In reply to tomtomtomreportingin from comment #0)

I believe it's intentional (I'm not a developer though).
It’s 10% of a low value which rounds to the same value. You’d have to go 51% or more to round to 0 or full alpha value. So it makes sense math wise. (Kind of, should be 50% maybe?) Might not feel intuitive though? Not sure.

The color picker doesn’t pick alpha value but you can see it in the tool options docker with color picker tool selected.
Comment 2 Dmitry Kazakov 2022-01-21 12:51:27 UTC
Can you try the same test with the image using Float-32 color space?
Comment 3 tomtomtomreportingin 2022-01-21 13:39:06 UTC
On float 32-bit, a 10% eraser does seem to fully erase eventually. I verified this using apelsinchoklad's tip of checking the color picker's tool options.
Comment 4 apelsinchoklad 2022-01-21 15:44:57 UTC
Can confirm what tomtomtom said.
With 10% opacity brush:
32bit float reaches to full/zero opacity. (It takes more strokes to reach full opacity then zero.)
16bit int and float reaches zero opacity but not full opacity

32bit float image with 0.999999 opacity pixels:
5% opacity brush does not reach full opacity
6% opacity brush does

32bit float image when erasing with a 1% opacity brush can reach 0 opacity
Comment 5 tomtomtomreportingin 2022-03-18 03:40:28 UTC
I just noticed this issue again late into a drawing with Pencil-3 Large 4B in eraser mode. It will never fully erase in 8-bit integer since it's a 15% opacity brush. Had to apply a levels filter to get rid of the ghost image, which is not ideal as it removes information from my intended sketch.
Comment 6 Wolfgang Baer 2025-04-13 06:03:09 UTC
Confirmed in 5.2.9 and 5.3 prealpha on Windows 10.

Possibly related report:
https://bugs.kde.org/show_bug.cgi?id=502489