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
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...
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.
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)
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. >
I still don't know what to do... We're running into basic maths here :-(. Would using a filter mask instead work for you?
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).
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.
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
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
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
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