Bug 294122 - Filter layers over a transparent background also display their source (minus the filter effect) - 100% replicatable
Summary: Filter layers over a transparent background also display their source (minus ...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Filter Layers (show other bugs)
Version: git master (please specify the git hash!)
Platform: Chakra Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-15 03:11 UTC by Kubuntiac
Modified: 2015-06-18 08:34 UTC (History)
2 users (show)

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


Attachments
Basic file that demonstrates the bug (235.64 KB, application/octet-stream)
2012-02-15 03:12 UTC, Kubuntiac
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kubuntiac 2012-02-15 03:11:08 UTC
Version:           svn trunk (using KDE 4.8.0) 
OS:                Linux

This is hard to explain, but easy to demonstrate / replicate.

Open the attached file and toggle the visibility of the bottom layer. When you do, look at how the appearance of the paint layer changes.

What seems to happen, is that when a filter layer, affects a paint layer and there is nothing but transparency behind it, then it doesn't just show the paint layer filtered, it shows the paint layer filtered... with a duplicate of the paint layer unfiltered over the top as well!

Reproducible: Always

Steps to Reproduce:
1. Create a paint layer
2. Either delete all layers behind it, or put it in a group layer
3. Place a filter layer directly above it (any filter, I used blur)


Actual Results:  
You'll see the paint layer filtered, with a duplicate of the paint layer drawn on top of it.

Expected Results:  
You see the paint layer filtered, with no duplicate of the paint layer drawn on top, just like what happens if you put a visible, opaque layer beneath both the paint and filter layer.



OS: Linux (x86_64) release 3.2-CHAKRA
Compiler: gcc
Comment 1 Kubuntiac 2012-02-15 03:12:40 UTC
Created attachment 68808 [details]
Basic file that demonstrates the bug

Just look at what the paint layer + filter layer output. It looks fine at the start... until you turn off the visibility of the background layer at the bottom. Then strange things happen...
Comment 2 Sven Langkamp 2012-02-19 14:57:04 UTC
The behavior is sort of expected. It caused by the way blur works. It basically mixes the pixel on a certain position with all the pixels around. In the first case it mixes with a lot of white so the result becomes gray. In the second case it mixes with transparent pixels.
Comment 3 Halla Rempt 2012-02-19 15:04:48 UTC
Yes... If the paint layer and the blur layer would be in a separate group, it'd always look like it does when the bottom layer is invisible. I think we should re-classify this as a feature :-)

(We do have a wish, which I cannot find right now, for photoshop-style composition with layer groups, which is kind of pass-through)
Comment 4 Kubuntiac 2012-02-20 02:06:53 UTC
This "feature" is vastly different from what I expected and also stops me
from doing things that would have been easy without it. Surely if a pixel
is being mixed with transparent pixels around it, it should become more
transparent as well, rather than looking exactly the same? All of the
pixels where the original painted image is, are completely unchanged by the
blur filter layer. Regardless of what the maths being used is, that doesn't
seem right from a users perspective.

If I put a blur filter over something I expect it to look blurred. Period.

Having it look blurred when an unrelated layer is opaque, but not when that
unrelated layer is transparent is bizare. Show this to any user at all
without an explanation. I would be amazed if a single user reported that
the current behavior is what they expected, or helpful.

On Sun, Feb 19, 2012 at 10:04 AM, <boud@valdyas.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=294122
>
>
> boud@valdyas.org changed:
>
>           What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                 CC|                            |boud@valdyas.org
>
>
>
>
> --- Comment #3 from  <boud valdyas org>  2012-02-19 15:04:48 ---
> Yes... If the paint layer and the blur layer would be in a separate group,
> it'd
> always look like it does when the bottom layer is invisible. I think we
> should
> re-classify this as a feature :-)
>
> (We do have a wish, which I cannot find right now, for photoshop-style
> composition with layer groups, which is kind of pass-through)
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>
Comment 5 Halla Rempt 2012-02-29 14:58:26 UTC
I still don't know what to do... We're running into basic maths here :-(. Would using a filter mask instead work for you?
Comment 6 Dmitry Kazakov 2012-03-01 14:35:06 UTC
I think the problem here is that the Filter Layer is merged into final projection as COMPOSITE_OVER, that is why the original black layer is shown as well. 

We might want to add (revert back) COMPOSITE_COPY layer blending option. In this case the result will be exactly as Bugsbane suggests (at least as far as I understood).
Comment 7 Halla Rempt 2012-03-01 14:38:32 UTC
Of course, that will break other filters again... So, I guess filters should have a property that defines the "right" composite op to use when used as a filter layer.
Comment 8 Dmitry Kazakov 2012-10-27 14:14:07 UTC
Git commit 04420efd8b44ae8745632de8c1180abd5f5edfd3 by Dmitry Kazakov.
Committed on 27/10/2012 at 15:44.
Pushed by dkazakov into branch 'master'.

By default Adjustment Layers should have COMPOSITE_COPY op

Otherwise it makes users perplexed with the result.

M  +4    -0    krita/image/kis_adjustment_layer.cc

http://commits.kde.org/calligra/04420efd8b44ae8745632de8c1180abd5f5edfd3
Comment 9 Jarosław Staniek 2012-10-31 11:35:16 UTC
Git commit f357ea38edfcba019c9e3c5dadcee3c47e66c976 by Jaroslaw Staniek, on behalf of Dmitry Kazakov.
Committed on 27/10/2012 at 15:44.
Pushed by staniek into branch 'kexi-altertable-staniek'.

By default Adjustment Layers should have COMPOSITE_COPY op

Otherwise it makes users perplexed with the result.

M  +4    -0    krita/image/kis_adjustment_layer.cc

http://commits.kde.org/calligra/f357ea38edfcba019c9e3c5dadcee3c47e66c976
Comment 10 Halla Rempt 2013-09-28 10:53:15 UTC
Git commit 85a9c7761bea895ba235c284b868e794b39168dd by Boudewijn Rempt.
Committed on 28/09/2013 at 10:52.
Pushed by rempt into branch 'master'.

Add links to two bugs for documentation purposes.

These bugs explain the dilemma of which blending mode to make
default for filter layers.
Related: bug 324505

M  +3    -0    krita/image/kis_adjustment_layer.cc

http://commits.kde.org/calligra/85a9c7761bea895ba235c284b868e794b39168dd
Comment 11 Dmitry Kazakov 2015-06-18 08:34:50 UTC
Git commit fc3fcc743d9706f13167b7317fdfb10c02fce7a9 by Dmitry Kazakov.
Committed on 18/06/2015 at 08:30.
Pushed by dkazakov into branch 'calligra/2.9'.

Fix Adjustment layers composition

This was a very old bug related the way how selection is applied
to adjustment layers. Now selection defines not "how the filtered
data is blended into the image" but "how the filter effect is applied
to the composed image". In the result, erasing the selection now will
*not* make your image fully transparent, but just removes the filter
effect from that area.
Related: bug 324505, bug 349078
CC:kimageshop@kde.org

M  +2    -1    krita/image/kis_adjustment_layer.cc
M  +19   -3    krita/image/kis_async_merger.cpp
M  +39   -25   krita/image/kis_selection_based_layer.cpp
M  +21   -0    krita/image/kis_selection_based_layer.h

http://commits.kde.org/calligra/fc3fcc743d9706f13167b7317fdfb10c02fce7a9