| Summary: | Very low max opacity strokes will never reach full opacity on the canvas | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | tomtomtomreportingin |
| Component: | General | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | apelsinchoklad, dimula73, info |
| Priority: | NOR | ||
| Version First Reported In: | 5.2.9 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
tomtomtomreportingin
2022-01-21 01:11:39 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. Can you try the same test with the image using Float-32 color space? 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. 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 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. Confirmed in 5.2.9 and 5.3 prealpha on Windows 10. Possibly related report: https://bugs.kde.org/show_bug.cgi?id=502489 |