Bug 420600 - Krita 4.3.0 Preserve Alpha Colorsmudge Opacity Affected by Smudge Length
Summary: Krita 4.3.0 Preserve Alpha Colorsmudge Opacity Affected by Smudge Length
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Brush engines (show other bugs)
Version: 4.2.9
Platform: Microsoft Windows Microsoft Windows
: NOR wishlist
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-26 03:15 UTC by Ryan Miller
Modified: 2021-05-21 10:57 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Opacity decreases with decreasing smudge length. (33.40 KB, image/jpeg)
2020-04-26 03:15 UTC, Ryan Miller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Miller 2020-04-26 03:15:23 UTC
Created attachment 127877 [details]
Opacity decreases with decreasing smudge length.

SUMMARY


STEPS TO REPRODUCE
1. Run portable version of krita at this link (https://disk.yandex.com/d/Ei1n9S16faEppg)
2. Create a new file.
3. Create a new smudge brush preset. Make sure that only opacity is controlled by pen pressure.
4. Deselect "Smear alpha" in brush settings under "Smudge Length"
5. Increase Smudge Length to 100% under brush settings. Draw a line on the image file
6. Decrease the smudge length to 75%. You may notice a slight decrease in maximum opacity.
7. Continue decreasing the smudge length in small increments. As the smudge length is decreased, the maximum opacity also decreases. This bug occurs in both dulling mode and smearing mode for the smudge brush. A similar bug was reported in 2014 for Krita 2.8, but it appears to have been fixed.

OBSERVED RESULT
As the smudge length is decreased the maximum opacity of each dab will also decrease.

EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 10
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Halla Rempt 2020-05-04 12:40:06 UTC
Is this with one of Dmitry's special builds for the threads on krita-artists.org? Please check first with the latest beta (https://download.kde.org/unstable/krita/4.3.0-beta1/).
Comment 2 Ryan Miller 2020-05-05 08:28:13 UTC
This bug persist in the latest beta (4.3.0) of Krita. Aditionally, after further testing, it appears in the latest stable release of Krita (4.2.9). The bug appears not to require disabling smear alpha to replicate the bug.
Comment 3 Bug Janitor Service 2020-05-06 04:33:13 UTC
Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.
Comment 4 Dmitry Kazakov 2020-05-06 15:02:23 UTC
That is the related bug:
https://bugs.kde.org/show_bug.cgi?id=329557
Comment 5 Dmitry Kazakov 2020-05-06 15:28:10 UTC
Hi, Ryan!

This behavior is just a way how "Smudge Rate" is implemented. It worked this way since "Color Smudge" engine was first implemented :)

The reason for this behavior is that we just don't have any control for the "smudged area" filling. It is painted with 100% opacity, then blended with color rate (using `colorRate * (1.0 - smudgeRate)` opacity), and then the final result is blended into the image with `smudgeRate` opacity. The "smudging" itself happens not because of mixing in the brush, but because of mixing on the canvas.

Theoretically, we can move final mixing into the brush and control the smudge rate of separately from the final opacity, but I'm not really sure what will be the benefit... And it will be surely slower.
Comment 6 Dmitry Kazakov 2020-05-06 16:30:04 UTC
Hi, Ryan!

Please test this proof-of-concept package: it has the meaning of the smudge rate and color rate sliders changed as you explained. I'm not really sure this change is really useful though.

https://yadi.sk/d/YybxFsfObB5WAg

WARNING: the package has the following limitations:

1) It only works in "Smearing" mode. Dulling mode is just not implemented
2) It works weirdly when the source layer has transparency. Please test on layers filled with opaque color (it is fixable).
3) It is slower than the original implementation (it is not fixable)

If you think that this behavior-change is "useful" for real work, then we should start the discussion with other painters on KA about that. But since it is a behavior change, it should give a really obvious set of benefits to be accepted.

Branch for compiling from source:
https://invent.kde.org/dkazakov/krita/commit/a45a986bcdb4326418ea80cfd062c7fc8913828e
Comment 7 Dmitry Kazakov 2020-05-12 18:51:15 UTC
Since it is a huge behavior change I'm downgrading the bug to a wishlist.
Comment 8 voronwe13 2020-07-28 19:59:33 UTC
MR 422 (https://invent.kde.org/graphics/krita/-/merge_requests/422) fixes this by adding a "Use New Engine" option.  When I wrote a new method for smudging to allow Color Image, Lightness Map, and Gradient Map brushes to work with the smudge engine, I did the smudging a slightly different way, and it doesn't have this issue.  Those modes only use the new engine, but it works with Alpha Mask brushes as well, so I made it an option for those brushes.  Once that's merged in, this can be closed.
Comment 9 Dmitry Kazakov 2021-05-21 10:57:15 UTC
This bug is fixed in the new colorsmudge engine that has been merged into Krita 5 last week.