Bug 411922

4.3.0-prealpha (git 3e21da9)

This require much more information, what kind of colorspace, what kind of bitdepth, can you share a file that this happens with?

Created attachment 122659 [details]
the file

Model : RGB/Alpha
Depth : 8-bit integer/channel
Profile : sRGB-elle-V2-srgbtrc.icc (Default)

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.

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'.

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.

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.

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.

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

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