Bug 432287

Summary: New RGBA brushes causing black pixels
Product: [Applications] krita Reporter: levi21sanchez
Component: Brush enginesAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED WORKSFORME    
Severity: normal CC: griffinvalley, halla, tomtomtomreportingin
Priority: NOR    
Version First Reported In: 4.4.2   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Picture of dark pixely things

Description levi21sanchez 2021-01-29 20:08:19 UTC
SUMMARY
Dark pixels will form on top of RGBA brush strokes if the RGBA brush stroke was really dark or black and you go over them with a brighter color. The second stroke can be a different brush or the same brush, this will still produce black pixels as long as its brighter than the first black stroke


STEPS TO REPRODUCE
1. Paint anywhere using an RGBA brush that is dark, black is best but not needed
2. Using any brush, paint with white or any bright color
3. Dark Pixels

OBSERVED RESULT
Dark pixels forming on top of bright colors

EXPECTED RESULT
Just dark pixels

SOFTWARE/OS VERSIONS
Windows: Version 10.0.19041 Build 19041
KDE Plasma Version: No Idea
KDE Frameworks Version: No Idea
Qt Version: 5.12.9 (Loaded and Compiled)

ADDITIONAL INFORMATION

Can be done on a single layer and two different layers if the brighter colors are above the darker colors

When using two layers, if you transform the bright color and move it over the darker one, it will look shimmery or wavy
Comment 1 levi21sanchez 2021-01-29 20:14:57 UTC
Created attachment 135291 [details]
Picture of dark pixely things
Comment 2 Halla Rempt 2021-01-31 15:18:55 UTC
Are you working on a grayscale image?
Comment 3 levi21sanchez 2021-01-31 20:45:09 UTC
(In reply to Halla Rempt from comment #2)
> Are you working on a grayscale image?

No, image color space says RGB/Alpha (32-bit float/channel) sRGB-elle-V2-g-10.icc
Comment 4 Halla Rempt 2021-02-01 09:26:41 UTC
Okay, then that might still be the reason. Is there a reason why you're working in 32 bits floating point?
Comment 5 levi21sanchez 2021-02-02 01:51:54 UTC
No, I'm new to digital art in general and never really gave much thought to the color spacing
Comment 6 Halla Rempt 2021-02-02 08:32:58 UTC
Okay, 32 bits/floating point per channel is useful when creating background images for movies or art for HDR displays. If you just want to paint, 8 bit/channel rgba is the format you want.
Comment 7 tomtomtomreportingin 2021-02-07 12:23:11 UTC
Isn't this still bit of an issue though? I can observe this on 16-bit float as well, which is what you'd use if you'd prefer more traditional color blending, right? Also, if you use dark colors with the RGBA brushes on a 16-bit float/32-bit float color space, you can observe colors somehow bleeding onto the other side of the color wheel. For example, using a dark yellow brush will introduce a lot of dark blue artifacts.
Comment 8 Halla Rempt 2021-02-07 14:09:50 UTC
Yes, it's still an issue, which why I didn't close the report. I haven't tried to reproduce it, though, so I also didn't set it to confirmed -- but it isn't an issue for the majority of our users.
Comment 9 wolthera 2021-09-08 09:20:52 UTC
I suspect this may have been fixed, as I cannot reproduce it anymore, but I do recall it being there and dmitry and peter fussing over it (on top of the changes deif lou did to handle a similar issue with the color dodge).

If you can still reproduce this, don't hesitate to reopen the bug!