Bug 441755 - Smudge brushes have buggy interaction with Value option on 16-bit float and above color depths
Summary: Smudge brushes have buggy interaction with Value option on 16-bit float and a...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Brush engines (show other bugs)
Version: 5.0.0-beta1
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-08-30 12:18 UTC by tomtomtomreportingin
Modified: 2021-10-01 11:41 UTC (History)
2 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-08-30 12:18:36 UTC
SUMMARY
Smudge brushes in Krita 5 can experience malformed hue changes when utilizing the Value sensor on 16-bit float and above documents. This doesn't occur in Krita 4 so it's a regression. Occurs regardless of smudge algo used.

STEPS TO REPRODUCE
1. Create a 16-bit float document.
2. Select Wet Knife brush.
3. Select and enable Value option, turn off Pressure sensor, enable Fuzzy Dab.
4. Make some red strokes.

OBSERVED RESULT
There are malformed streaks of blue appearing in the strokes. The issue is exaggerated in 32-bit float.

EXPECTED RESULT
No malformed streaks of blue.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian sid
KDE Plasma Version: 5.21.5
KDE Frameworks Version: 5.85.0
Qt Version: 5.12.11 (Appimage)
Comment 1 tomtomtomreportingin 2021-08-30 12:26:11 UTC
I don't think this is a duplicate of https://bugs.kde.org/show_bug.cgi?id=437430 as although disabling canvas acceleration relieves the problem, there are still subtle hints of blue, which don't accur in Krita 4.
Comment 2 wolthera 2021-09-15 16:43:01 UTC
Ok, this is rather tricky.

so the problem seems to be with the HSV transform itself. When checking where the color goes wrong, it is normal before the HSV transform is applied, and is completely borked afterwarts, complete with overflow.

However, I can't for the life of me figure out why the color smudge is THAT much different than the pixel brush. The pixel brush IS also affected, but it's very minor in comparison. Similarly, the HSV filter seems to work as expected. Turning the compatibility mode on or off does not seem to make a difference.

I think this is a clamping issue, but the obvious way to clamp did not work, and it seems the filter already implements clamping in places.

My best guess is that it is in fact not the HSV transform, but rather the way we use it inside the color smudge. I already tried having it not read and write to the same paintColor.data(), but that didn't seem to make a difference. Another thing that might be related is the precisepaintdevice wrapper, though, that'd make the bug also appear in 4.4...

I am at a loss...
Comment 3 Dmitry Kazakov 2021-10-01 11:39:39 UTC
Git commit abd82cbc5f12e41a32b8d43d0ea33b802c6d492a by Dmitry Kazakov.
Committed on 01/10/2021 at 11:39.
Pushed by dkazakov into branch 'master'.

Fix artifacts in Hue sensor in colorsmudge brush

m_hsvTransform had been created before m_paintColor was converted
into the correct color space. It meant tha m_hsvTransform manipulated
pixels in a different colorspace (16i) instead of 16f or 32f :)

M  +14   -11   plugins/paintops/colorsmudge/kis_colorsmudgeop.cpp

https://invent.kde.org/graphics/krita/commit/abd82cbc5f12e41a32b8d43d0ea33b802c6d492a
Comment 4 Dmitry Kazakov 2021-10-01 11:41:28 UTC
Git commit 5dada1e5047d2194a473c611860996d32e0e0aaf by Dmitry Kazakov.
Committed on 01/10/2021 at 11:41.
Pushed by dkazakov into branch 'krita/5.0'.

Fix artifacts in Hue sensor in colorsmudge brush

m_hsvTransform had been created before m_paintColor was converted
into the correct color space. It meant tha m_hsvTransform manipulated
pixels in a different colorspace (16i) instead of 16f or 32f :)

M  +14   -11   plugins/paintops/colorsmudge/kis_colorsmudgeop.cpp

https://invent.kde.org/graphics/krita/commit/5dada1e5047d2194a473c611860996d32e0e0aaf