Summary: | Krita 4.3.0 Preserve Alpha Colorsmudge Opacity Affected by Smudge Length | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | Ryan Miller <millerryanmi> |
Component: | Brush engines | Assignee: | Dmitry Kazakov <dimula73> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | dimula73, halla, voronwe13 |
Priority: | NOR | ||
Version: | 4.2.9 | ||
Target Milestone: | --- | ||
Platform: | Microsoft Windows | ||
OS: | Microsoft Windows | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Opacity decreases with decreasing smudge length. |
Description
Ryan Miller
2020-04-26 03:15:23 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/). 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. 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. That is the related bug: https://bugs.kde.org/show_bug.cgi?id=329557 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. 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 Since it is a huge behavior change I'm downgrading the bug to a wishlist. 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. This bug is fixed in the new colorsmudge engine that has been merged into Krita 5 last week. |