Created attachment 143690 [details] Brush editor showing the difference between the two brush tips The brush mode option "Alpha Mask" for predefined brushes doesn't seem to work properly. When it's selected, the brush tip is somewhat transparent although the brush tip is black and opacity is at 100%. The problem seems to occur when the brush tip is a transparent PNG file. I had them exported from abrmate. When the brush tip isn't transparent (black on white background), the problem doesn't occur. It's also fine if "Color Image" is selected as brush mode. This also affects the brush tip in the Masked Brush category, as the default (and only ) option is "Alpha Mask". I've checked the issue in Krita 4 and there everything works as expected. Attached is a screenshot of the brush editor showing the issue. The top brush dot in the Scratchpad is created with "Alpha Mask" selected, the bottom one with "Color Image" selected. I hope this is an easy fix and can be implemented soon - it's crucial for Masked Brush creations. SOFTWARE/OS VERSIONS Windows: 10 64-Bit macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
I've uploaded the brush tip that was used. Here's the link ... http://www.argfx.at/upload/Sammy_Brushes_All_12.zip
I believe this should be resolved now as of commit 0b260f71b614e700d6ae9108e31509f81b66fbf2. If you continue to have this issue, please get back to me and reopen the bug. Thanks! Eoin
I just tested it with the latest nightly build (krita-nightly-x64-5.1.0-prealpha-0fa5c8a4af.zip) and the issue still isn't fixed. Here's a screenshot of a comparison between two identical brush tips. The left one in the scratchpad is the alpha version, the right one is the opaque version. http://www.argfx.at/upload/Krita_Bug_03.jpg
I never reopened a bug, but maybe this is how it works.
It's worth noting that the png attached also has alpha value on the png. It probably means that we are doing the alpha part of RGBA brushes incorrectly. (?)
Created attachment 144074 [details] Sammy_Brush_12-noalpha Thanks for reopening the bug. I had thought this would be fixed with dmitry's change to the duplicate resource bug found with brush tips, but the issue persists. So it's worth noting that this is the result of krita changing it's behavior based on the fact that you have a brush tip w/ transparency. When you use my attached black-and-white no-alpha image as a brush tip, it works as expected. Krita wants a black and white mask image, and that should be what users supply. It's less a bug and more a papercut, but it's worth investigating a fix. It should be possible for us to detect this specific situation and do something about it.
Git commit 31a44cf99165efb16e905ed209dbdcdea57f8509 by Eoin O'Neill. Committed on 29/11/2021 at 23:36. Pushed by eoinoneill into branch 'master'. Fixed backwards compatibility edge case for alpha-mask png brush tips. User was getting unexpected results compared to previous version of krita. While this behavior is not technically a bug, it was a regression compared to the user's expected behavior. They had a single png image with all black rgb channels and only an alpha channel defined. We can try to catch this specific edge case to assign the alpha mask mode to the correct setting to have consistent behavior with krita 4... M +27 -1 libs/brush/kis_png_brush.cpp M +1 -1 libs/brush/kis_predefined_brush_factory.cpp https://invent.kde.org/graphics/krita/commit/31a44cf99165efb16e905ed209dbdcdea57f8509
Git commit 5176b92ed4c24e61525e7fe89fc182c8a704c2a9 by Eoin O'Neill. Committed on 30/11/2021 at 04:29. Pushed by eoinoneill into branch 'krita/5.0'. Fixed backwards compatibility edge case for alpha-mask png brush tips. User was getting unexpected results compared to previous version of krita. While this behavior is not technically a bug, it was a regression compared to the user's expected behavior. They had a single png image with all black rgb channels and only an alpha channel defined. We can try to catch this specific edge case to assign the alpha mask mode to the correct setting to have consistent behavior with krita 4... (cherry picked from commit 31a44cf99165efb16e905ed209dbdcdea57f8509) M +27 -1 libs/brush/kis_png_brush.cpp M +1 -1 libs/brush/kis_predefined_brush_factory.cpp https://invent.kde.org/graphics/krita/commit/5176b92ed4c24e61525e7fe89fc182c8a704c2a9
I just tried the fix in the latest build of today and the issue still isn't fixed. There's an additional bug now. When I select the brush tip with the included alpha mask, the Brush Mode jumps to "Lightness" instead of "Alpha Mask". And when I switch the Brush Mode back to Alpha Mask, the brush tip is transparent like it was before.
(In reply to Andreas Resch from comment #9) > I just tried the fix in the latest build of today and the issue still isn't > fixed. There's an additional bug now. When I select the brush tip with the > included alpha mask, the Brush Mode jumps to "Lightness" instead of "Alpha > Mask". And when I switch the Brush Mode back to Alpha Mask, the brush tip is > transparent like it was before. The issue is that your brush tip is not designed to be used with Alpha mask because it isn't defined like a mask should be. (It should be black and white with no alpha.) I'm sorry but because of the new alpha mask changes for RGBA brushes, I'm not entirely sure I understand the desired behavior here. If you want to use this as an alpha mask, then please define it like an alpha mask should be. Is there a particular reason why `Lightness` doesn't work for your given use case?
I will confirm this bug and come up with another fix -- I presume that the issue at hand here is that this work around will cause some backward compatibility issues with resources defined in Krita 4.x However, it is worth noting that the image in question is not properly defined for your intended use case and that any fix here is a work around for that. Simply changing the source image to have no alpha mask would fix the behavior. That is basically what I will do behind-the-scenes, but I think that we should plan to migrate away from this fix long term and resources should be properly updated to reflect the new design.
Git commit 357aff91fd5c03aa58c7691a7fb8493ceff5fad1 by Eoin O'Neill. Committed on 02/12/2021 at 23:31. Pushed by eoinoneill into branch 'master'. Modifications to alpha mask exception for png with uniform rgb values. User wasn't happy with the previous work around, so this will hopefully be closer to what they expect with regards to behavior. M +13 -3 libs/brush/kis_png_brush.cpp https://invent.kde.org/graphics/krita/commit/357aff91fd5c03aa58c7691a7fb8493ceff5fad1
Hi there, I've made some more alterations to try to get the behavior of this edge case closer to Krita 4.x -- please try the new version when you get a chance. Sorry for the inconvenience, Eoin.
It's better than before. The brush tips still aren't identical (the alpha version is slightly brighter) but I guess it's close enough. And don't worry about me being "happy". I won't even use Krita before some of the missing basics are implemented and productivity is supported better. This is mainly about users porting their brushes from 4.x and wondering why their brushed suddenly look different (in case they use transparent brush tips). Now that I know about this bug I would only use opaque brush tips. Cheers for the effort.
One thing I noticed is, when I set the Brush Mode to "Lightness Map" now (for the transparent brush tip), the brush stroke looks weird and the transparency seems to be ignored. Maybe worth checking. Here's a screenshot. http://www.argfx.at/upload/Krita_Bug_04.jpg
Hi, Thank you for the fix, just tested 5.1.0-prealpha (357aff91fd), the alpha is slightly different in non-black png. Step: 1. Select b)Basic-2 Opacity, disable its Opacity sensor, and switch to Predefind brush tips 2. Select DA_RGBA bluegreen_small1, change brush mode to Alpha Mask, size 450px, spacing 1.0 (non-auto) 3. Choose black (#000000) and draw on canvas 4. Pick color with Color Sampler Tool (set to Sample current layer) Observed: in 4.4.8 the alpha value is around 120 in 5.1.0 the alpha value is around 100 5.0.0-beta3 also have the original alpha mask bug
> It's better than before. The brush tips still aren't identical (the alpha version is slightly brighter) but I guess it's close enough. And don't worry about me being "happy". I won't even use Krita before some of the missing basics are implemented and productivity is supported better. Andreas, I hope that commit message didn't come across as snarky. I honestly only mean to only keep a note of why the change I was making was being made in order to keep a detailed log on changes made to the code. I think you're basically right here, which is why I tried to make more modifications to get the behavior closer to 4.x. This area of the program is definitely not my expertise, so any input here is of great help. Since it's not really code I touch often, I think taking notes on what is happening is important for those who will be working on that code later down the line without having to look at the bug report in question. Also, if you have any productivity concerns, please feel free to share them with me. We can't get to them quite yet since 5.0 has had some hurdles that we need to clear in the short-term, but workflow is one of the areas I want to tackle next and any input here would be great as well. Anyway -- I want to thank you for taking the time to report this bug and working with me to try to come to a solution. It is of great value to us that we have users who are willing to use our beta software and provide us with detailed bug reports, so I hope you do continue to try to use Krita to that capacity and give us insights wherever possible. Cheers, Eoin.
That behavior in the screenshot is concerning... I'm going to have to run by DmitryK what modifications we might need to make to address this compatibility issue during the next meeting. For the time being, I'm reopening this bug until I can get better consultation.
Thanks for the investigation. This seems to be a tricky one. Don't worry about your comments. I'm just a very rational person and sometimes that comes across as being angry. The productivity issue I've tried to get across in the forum - to no avail. It seems as if the Nr. 1 priority of Krita is to be different than other programs, no matter what. And when you use Krita, this is obvious all over the place. Different is fine, but only if it makes the experience better, faster or easier. And that's not the case. Love the brush engine but I'm struggling with the rest a bit. Overall I would have to sacrifice speed and flexibility for some nice brushes. And when you make a living with painting, that's an equation that doesn't work out. I'll keep an eye on Krita over the coming years and hope for the best.
Git commit 1fc1926d25821867581172ad6b8139893d4578ac by Eoin O'Neill. Committed on 09/12/2021 at 02:52. Pushed by eoinoneill into branch 'krita/5.0'. Another pass at alpha mask related regression. It seems like the behavior changed due to an unnecessary change to a default value in the KisColorfulBrush header. Changing the autoadjust bool to start at true was causing unintended modifications to ALPHAMASK brush behavior. Checked unit tests and all tests passed after changing the default value back -- plus the behavior was fixed and did not seem to cause regressions anywhere else. M +1 -1 libs/brush/KisColorfulBrush.h M +1 -27 libs/brush/kis_png_brush.cpp https://invent.kde.org/graphics/krita/commit/1fc1926d25821867581172ad6b8139893d4578ac
Hi Eoin, will this fix also be pushed to master?
Git commit a840b241c155d3cae05b28d285d8e59d7a130128 by Eoin O'Neill. Committed on 25/01/2022 at 22:29. Pushed by eoinoneill into branch 'master'. Another pass at alpha mask related regression. It seems like the behavior changed due to an unnecessary change to a default value in the KisColorfulBrush header. Changing the autoadjust bool to start at true was causing unintended modifications to ALPHAMASK brush behavior. Checked unit tests and all tests passed after changing the default value back -- plus the behavior was fixed and did not seem to cause regressions anywhere else. (cherry picked from commit 1fc1926d25821867581172ad6b8139893d4578ac) M +1 -1 libs/brush/KisColorfulBrush.h M +1 -27 libs/brush/kis_png_brush.cpp https://invent.kde.org/graphics/krita/commit/a840b241c155d3cae05b28d285d8e59d7a130128