Bug 431937 - Custom smudge brush that worked in a previous version of Krita no longer works
Summary: Custom smudge brush that worked in a previous version of Krita no longer works
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Brush engines (show other bugs)
Version: 4.4.2
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression, release_blocker
Depends on:
Blocks:
 
Reported: 2021-01-22 15:50 UTC by tomtomtomreportingin
Modified: 2021-02-09 12:19 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tomtomtomreportingin 2021-01-22 15:50:46 UTC
SUMMARY
I have this brush named Rakkuri_Blender_Frosty from Rakkuri's Brush Set V1.1 that no longer appears to have any effect. Appears to be a regression starting in 4.4.0. 

STEPS TO REPRODUCE
1. Download the brush bundle from https://krita-artists.org/t/rakurri-brush-set-free-krita-brushes/3524/14 (only 1.1 is necessary for reproducing, you'll get the same result regardless if 1.0 is installed or not)
2. Draw something with a regular non-blending brush.
3. Attempt to blend it using Rakkuri_Blender_Frosty.

OBSERVED RESULT
Nothing happens.

EXPECTED RESULT
The drawing should be blended with a frosty effect.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian sid
(available in About System)
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.12.9 (Appimage)

ADDITIONAL INFORMATION
In the brush settings, if you select a different brush tip and then reselect the original brush tip, the brush seems to work again. Clicking "Reset Predefined Tip" also achieves this effect. I am not sure if either of these actions changes the expected default behavior of the brush.
Comment 1 Tiar 2021-01-23 03:35:06 UTC
Confirming.
I've also added "release_blocker" since it sounds serious (but hopefully easy to fix, if there are no engine issues, just initialization).
Comment 2 Dmitry Kazakov 2021-02-05 12:40:54 UTC
Well, it looks like the brush has been generated at the short period of time when the format of the lightness brush algorithm was not finished enough (even though we released that). Now the file has incorrect settings inside.  Just changing the brush tip to some other one in the new version of Krita and setting it back fixes the issue. 

I will try to add some workaround that.
Comment 3 Bug Janitor Service 2021-02-05 17:45:23 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/692
Comment 4 Dmitry Kazakov 2021-02-05 19:20:06 UTC
Hi, tomtomtom!

Could you please test the packages linked in this MR?

https://invent.kde.org/graphics/krita/-/merge_requests/692

It should fix the bug, and I hope it doesn't cause any more regressions...
Comment 5 tomtomtomreportingin 2021-02-07 13:14:43 UTC
The buggy brush seems to work now, and I did a quick stroke with each and every brush I have installed, and they all seem to work fine.
Comment 6 Dmitry Kazakov 2021-02-09 11:26:26 UTC
Git commit 2f2f5722cbcd4323bb5f6ee77bc3945fc7b59274 by Dmitry Kazakov.
Committed on 05/02/2021 at 17:39.
Pushed by dkazakov into branch 'master'.

Fix opening brushes created during incomplete lightness feature implementation

We had a period of time, when the presence or absence of **color**
in the brush (not transparency) was used to decide whether to use
useColorAsAlpha. Basically, absence of color in the brush would switch
mask mode even when useColorAsAlpha was false.

In the new versions of Krita 'useColorAsAlpha' tag is completely
removed, and 'brushApplication' tag is used instead, which does
allow such ambiguity.

M  +12   -2    libs/brush/KisColorfulBrush.cpp
M  +5    -1    libs/brush/KisColorfulBrush.h
M  +9    -2    libs/brush/kis_brushes_pipe.h
M  +6    -3    libs/brush/kis_gbr_brush.cpp
M  +2    -1    libs/brush/kis_imagepipe_brush.cpp
M  +6    -2    libs/brush/kis_png_brush.cpp
M  +2    -2    libs/brush/kis_predefined_brush_factory.cpp
M  +4    -4    libs/brush/tests/kis_imagepipe_brush_test.cpp
M  +2    -2    plugins/impex/brush/kis_brush_import.cpp
M  +1    -1    plugins/paintops/libpaintop/kis_brush_chooser.cpp

https://invent.kde.org/graphics/krita/commit/2f2f5722cbcd4323bb5f6ee77bc3945fc7b59274
Comment 7 Dmitry Kazakov 2021-02-09 12:19:05 UTC
Git commit 53d4e1121e2d90aa48de01a2f0539ddd132d80b4 by Dmitry Kazakov.
Committed on 09/02/2021 at 12:04.
Pushed by dkazakov into branch 'krita/4.3'.

Fix opening brushes created during incomplete lightness feature implementation

We had a period of time, when the presence or absence of **color**
in the brush (not transparency) was used to decide whether to use
useColorAsAlpha. Basically, absence of color in the brush would switch
mask mode even when useColorAsAlpha was false.

In the new versions of Krita 'useColorAsAlpha' tag is completely
removed, and 'brushApplication' tag is used instead, which does
allow such ambiguity.

# Conflicts:
#	libs/brush/kis_brushes_pipe.h
#	libs/brush/kis_imagepipe_brush.cpp

M  +12   -2    libs/brush/KisColorfulBrush.cpp
M  +5    -1    libs/brush/KisColorfulBrush.h
M  +8    -2    libs/brush/kis_brushes_pipe.h
M  +6    -3    libs/brush/kis_gbr_brush.cpp
M  +2    -1    libs/brush/kis_imagepipe_brush.cpp
M  +6    -2    libs/brush/kis_png_brush.cpp
M  +2    -2    libs/brush/kis_predefined_brush_factory.cpp
M  +4    -4    libs/brush/tests/kis_imagepipe_brush_test.cpp
M  +2    -2    plugins/impex/brush/kis_brush_import.cpp
M  +1    -1    plugins/paintops/libpaintop/kis_brush_chooser.cpp

https://invent.kde.org/graphics/krita/commit/53d4e1121e2d90aa48de01a2f0539ddd132d80b4