Bug 411922 - Stair-like edges appear when using some filter mask layers
Summary: Stair-like edges appear when using some filter mask layers
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Filters (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-14 19:50 UTC by acc4commissions
Modified: 2019-09-21 12:09 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
capture (171.04 KB, image/png)
2019-09-14 19:50 UTC, acc4commissions
Details
the file (898.78 KB, application/x-krita)
2019-09-14 20:42 UTC, acc4commissions
Details
Apparently blank .png file with colour values set (20.40 KB, image/png)
2019-09-16 14:24 UTC, Ahab Greybeard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description acc4commissions 2019-09-14 19:50:37 UTC
Created attachment 122658 [details]
capture

SUMMARY
Check the attatchment picture. 
Try Edge Detection Filter, Height to Normal Map filter.

I'm not sure what's the culprit. Filter? Mask? Or something else? :/


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 acc4commissions 2019-09-14 19:51:36 UTC
4.3.0-prealpha (git 3e21da9)
Comment 2 wolthera 2019-09-14 19:52:13 UTC
This require much more information, what kind of colorspace, what kind of bitdepth, can you share a file that this happens with?
Comment 3 acc4commissions 2019-09-14 20:42:49 UTC
Created attachment 122659 [details]
the file

Model : RGB/Alpha
Depth : 8-bit integer/channel
Profile : sRGB-elle-V2-srgbtrc.icc (Default)
Comment 4 Bug Janitor Service 2019-09-15 04:33:12 UTC
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.
Comment 5 Ahab Greybeard 2019-09-15 19:12:47 UTC
For the 4.1.7 appimage onwards, try the following:

Create a new image, add a filter mask (Edge Detection - Prewitt - All Sides - 1px)

Paint in the transparent layer and see the edges appear, as expected but they are white on a black backround.

Switch to an eraser and erase the painted line. The edge does not disappear, it stays there.

Copy/paste that paint layer and apply a fresh Prewitt mask to the copy. The edge is there.

The paint layer seems to hold some strange kind of memory of what used to be there.

If you use a filter layer of the same type, the edges are white on a transparent background and there is no 'memory' effect'.
Comment 6 Ahab Greybeard 2019-09-15 19:37:51 UTC
Additional Experiment:

If you paint on a new layer (with no filter mask) and then erase the paint, an applied Prewitt filter mask will show where the paint edges used to be.

You can export the apparently empty transparent layer as a .png file and then open it in krita and a Prewitt mask will show where the edges used to be.

Note: All done with RGB/A 8-bit integer with default profile.
Comment 7 Ahab Greybeard 2019-09-16 14:24:24 UTC
Created attachment 122681 [details]
Apparently blank .png file with colour values set

Your image has content that is detected by the Prewitt filter (and Height to Normal Map)and shown as the 'staircase'. If you take the image layer and split the alpha to a mask, then turn off the mask, this is clearly visible.

It seems that these filters are sensitive to colour value of the pixels and appear to disregard the alpha values.  If you paint and erase, the alpha is set to zero but the colour values remain which would (and does) cause unexpected artifacts.

I attach the file 'hiddenU.png' which demonstrates this.

I don't know if the Prewitt filter (and others) are supposed to do this.

The Prewitt filter in GIMP does not do this.
Comment 8 Dmitry Kazakov 2019-09-16 15:36:34 UTC
The problem happens because these filters don't take alpha channel into account. It makes them compare pixels with totally black pixels under zero-alpha areas.
Comment 9 Dmitry Kazakov 2019-09-16 20:42:25 UTC
Git commit 02bdc53af81faea55db9e2dd780d28ae302e2979 by Dmitry Kazakov.
Committed on 16/09/2019 at 20:42.
Pushed by dkazakov into branch 'master'.

Fix wrong borders on EdgeDetection and HeightToNormalMap filters

The color data should be premultiplied by the alpha channel to
get correct result on layers with transparency.

M  +16   -0    libs/image/kis_edge_detection_kernel.cpp
M  +5    -0    libs/pigment/KoColorSpace.h
M  +5    -0    libs/pigment/KoColorSpaceAbstract.h
M  +0    -3    plugins/filters/convertheightnormalmap/kis_convert_height_to_normal_map_filter.cpp
M  +0    -3    plugins/filters/edgedetection/kis_edge_detection_filter.cpp

https://invent.kde.org/kde/krita/commit/02bdc53af81faea55db9e2dd780d28ae302e2979
Comment 10 Dmitry Kazakov 2019-09-21 12:09:07 UTC
Git commit 5ccac066cd8d98e655b7d14349dc011205ac096f by Dmitry Kazakov.
Committed on 21/09/2019 at 10:03.
Pushed by dkazakov into branch 'krita/4.2'.

Fix wrong borders on EdgeDetection and HeightToNormalMap filters

The color data should be premultiplied by the alpha channel to
get correct result on layers with transparency.

M  +16   -0    libs/image/kis_edge_detection_kernel.cpp
M  +5    -0    libs/pigment/KoColorSpace.h
M  +5    -0    libs/pigment/KoColorSpaceAbstract.h
M  +0    -3    plugins/filters/convertheightnormalmap/kis_convert_height_to_normal_map_filter.cpp
M  +0    -3    plugins/filters/edgedetection/kis_edge_detection_filter.cpp

https://invent.kde.org/kde/krita/commit/5ccac066cd8d98e655b7d14349dc011205ac096f