[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #29 from Dmitry Kazakov --- Git commit ad7e606e1374555a03bb546ecb425076d5acc9fc by Dmitry Kazakov. Committed on 21/09/2019 at 10:07. Pushed by dkazakov into branch 'krita/4.2'. Add a comment about merging adjustment layers Krita sticks to "keep image unchanged" approach when merging layers, just state it clearly in the code, so we wouldn't spend time on discussing that again. M +3-0libs/image/kis_adjustment_layer.cc M +28 -0libs/image/kis_layer_utils.cpp https://invent.kde.org/kde/krita/commit/ad7e606e1374555a03bb546ecb425076d5acc9fc -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 Raghavendra kamath changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |LATER --- Comment #28 from Raghavendra kamath --- > sorry if I was a little too aggressive. We are used to this kind of behaviour, you would be surprised how many users even curse us and say weird things and want the features that they think is prime importance, it feels sad when you put on hours of free volunteer work and rewarded with aggression, But we are now indifferent to it, so no problem. I am closing this bug report for now. Please open a forum discussions so that we can continue to discuss it with larger group of people and arrive at a conclusion. Thank you for your support -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #27 from katearche...@yandex.ru --- (In reply to Raghavendra kamath from comment #26) > Hi Kate, > > Thank you very much for the images, that makes it clear to understand what > you want. > > From what I understand you want the filter to only applied to the selected > layer and merged down, disregarding the unselected layer, that is the filter > should not be applied to the unselected layer and it should be reverted to > how it looked without filter. > > Now as we have told you in previous comment that in krita the filter layers > are just like new "layers from visible + the filter applied to them" so we > try to keep the output as close to what users see prior to merging. > I understand what are you trying to say but it's not intuitive at all. Just for a moment wear my boots with my train of thought: I see two layers(and a bunch of other i'm not interested by), I want to merge these two layers, I select them to isolate from the others but, by some miracle, in the end I got not only the layers I've selected but all other layers merged in that I've NOT selected purposely and by intent because I was merging these two. To expand: Let's say you have two paint layers. They are displayed on a canvas exactly the same way as two layers from my latest example but merging them together won't result in the merging in layers that wasn't selected. What I grieve for is a lack of consistency: in the end filter or not it's all _layers_, they exist in a same docker etc and a user should not be bothered with all the booby traps here and there when in one case selected layers merging in one way and in the other case completely differently from the first. > In your scenarios the merged output changes from what you have prior to > merging, it might be easy to guess in simple situations like having two > three layer and some adjustment layers, but It gets tricky when you'll have > filters such as blur or when you'll have more than 10 or 20 layers in > between with different blend modes. > I understand that merging with different blend modes can lead to unexpected results as well, and that's the case for Photoshop and other layer/blending operating programs as well. But there is a great difference between cases: "selected layers merging with no additional pixels created" and "selected layers merging with all the pixels from non-selected layers merged in as well". > May I request you to also show us images what photoshop does when you have > blur as filter layer, as you had in your first attachment. I can do that but it would be of no use since photoshop' adjustment layers are indeed working somehow differently from Krita's filter layers(i'm not sure about it's inner workings). They have two adjustment layer systems in place, the legacy one, adjustment layers, and smart layers, which are more or less works as krita's filter layers. - The legacy one was there like forever and from my understanding it's designed to work as fast as possible, therefore only selected filters are available as adjustment layers. - Smart filters are applied to smart objects only and in this case the whole set of filters are available, they can be stacked, edited at any given moment turned off and on again etc. The catch is that to apply these smart filters to a set of layers you must convert them into a smart object beforehand. So in a sense photoshop' smart filters work the same way krita filter masks. Returning to the question: The blur filter is available only as a smart filter so it is attached to a smart object which itself is just one layer from a layer stack point of view. So it's already "merged" with filters applied to it in the stack and they only way to merge in with filters is to flatten a layer which is working(kinda obviously) the same way as in krita. > > The design of the filter layer in Krita is different from photoshop's > adjustment layers. And krita users are more accustomed to the behaviour that > we have now. Changing it will lead to discomfort to many of the krita users > who rely on the existing behaviour. > To be honest I'm s not sure that your average joe keeping in his head that merging selected layers with filter layers without grouping selected layers beforehand would lead to other results than as with grouping them and/or that the "feature" of merging in pixels that wasn't there before can be used in any workflow usefully. > Still if you feel like we need to change the behaviour I humbly suggest you > to start a discussion topic in forum, so that we can gather more support and > opinion from the artists and we will get know what they like. > > P.S. The bug title can be - [Wish bug] Make filter layer affect only the > selected layer when merging down. Yes, I do feel like this behavior is inconsistent and misleading and I'll make a topic on a forum about it later on, thanks for a meaningful discussion, sorry if I was a little too
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 Raghavendra kamath changed: What|Removed |Added Resolution|NOT A BUG |--- Status|NEEDSINFO |REPORTED Ever confirmed|1 |0 --- Comment #26 from Raghavendra kamath --- Hi Kate, Thank you very much for the images, that makes it clear to understand what you want. >From what I understand you want the filter to only applied to the selected layer and merged down, disregarding the unselected layer, that is the filter should not be applied to the unselected layer and it should be reverted to how it looked without filter. Now as we have told you in previous comment that in krita the filter layers are just like new "layers from visible + the filter applied to them" so we try to keep the output as close to what users see prior to merging. In your scenarios the merged output changes from what you have prior to merging, it might be easy to guess in simple situations like having two three layer and some adjustment layers, but It gets tricky when you'll have filters such as blur or when you'll have more than 10 or 20 layers in between with different blend modes. May I request you to also show us images what photoshop does when you have blur as filter layer, as you had in your first attachment. The design of the filter layer in Krita is different from photoshop's adjustment layers. And krita users are more accustomed to the behaviour that we have now. Changing it will lead to discomfort to many of the krita users who rely on the existing behaviour. Still if you feel like we need to change the behaviour I humbly suggest you to start a discussion topic in forum, so that we can gather more support and opinion from the artists and we will get know what they like. P.S. The bug title can be - [Wish bug] Make filter layer affect only the selected layer when merging down. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #25 from katearche...@yandex.ru --- (In reply to katearcher89 from comment #23) > > https://imgur.com/a/0GjXguZ > > In photoshop there were the same steps: create a filter layer(an adjustment > layer in a adobe world), select two layers(an adjusment layer and a paint > layer) and hit ctrl-e to merge them. Notice that the adjustments were > transfered only to the layer that was merged with and no additional pixels > were added to the result. I want to note that in photoshop we get exactly what is expected: all the pixels are preserved and no other additional pixels slips in. _And that's the most important point and I can't stress that enough._ The current merging with filter layers of krita is creating new pixels and that is not expected and cannot be expected unless explicitly stated by the user. If I previously altered only color of the pixels why should I have pixels from other layers merged in that I didn't explicitly selected in the first place? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #23 from katearche...@yandex.ru --- (In reply to Raghavendra kamath from comment #20) > @ Kate the filter masks are designed to affect everything beneath them, when > you merge it , it creates a layer similar to what "new layer from visible" > does. perhaps you need filter masks and not filter layer. Well, yes and no. The workflow is kinda the same but since it's a nondestructive workflow I don't want to immediately merge results or to restrict myself to only one layer at the time. It's usually several layers created one after the other and some filter layers in between. At certain points in time I'm merging some of them since they were temporary anyway and pretty much ad-hoc. But I want to retain the ability to tweak them in that time that passes between their creation and the eventual merging. And most certainly I don't want to loose transparency in the process or have some unexpected pixels bleeding through. > > In the scenario of your latest attachement, can you show us images of what > is expected after the merge of two layers (marked in red). Should the filter > be only applied to layer 11 and merged, but then the remaining layer won't > have the filter applied to it. > > Can you show us the resulting merged layer in your ideal case. As in a > screenshot of what the resulting layer should look like would help. Yeah. sure thing. Here is the gallery with krita expected/actual results and I've asked a friend to make the same thing in photoshop so the results of that operation there as well: https://imgur.com/a/0GjXguZ In photoshop there were the same steps: create a filter layer(an adjustment layer in a adobe world), select two layers(an adjusment layer and a paint layer) and hit ctrl-e to merge them. Notice that the adjustments were transfered only to the layer that was merged with and no additional pixels were added to the result. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #24 from katearche...@yandex.ru --- (In reply to Raghavendra kamath from comment #22) > Hi Kate, > > May I request you to answer to the questions in comment 20 ? > > thank you I was in the process of writing it :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 Raghavendra kamath changed: What|Removed |Added Status|REOPENED|NEEDSINFO Resolution|--- |NOT A BUG --- Comment #22 from Raghavendra kamath --- Hi Kate, May I request you to answer to the questions in comment 20 ? thank you -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #21 from katearche...@yandex.ru --- (In reply to wolthera from comment #19) > I have the feeling this could be solved by you not using the copy blending > mode? Because that is what causes this distinct merging behaviour. The copy mode is assigned by Krita the moment the filter layer is made actually. But changing the blending mode to normal doesn't change a thing, the resulted merged layer still contains overlapping parts of a layer underneath. As for grouping layers debate: My main assumption in working with selected layers is that they are effectively a temporary group anyway(I selected several layers so I do want to work only with them atm so they are should exist in isolation, I selected-isolated them from others for that particular reason after all) so I see why it's not possible/would break things if the user will have to do a couple less tedious gestures to get the result that he was initially expected? I know it's a kinda bad argument but nonetheless: Photoshop treats selected layers the exactly same way: as a temporary group(at least when it comes to merging and transforming layers) and you don't have to rely on layer thumbnails to figure out the result(don't forget that they can be turned off so they will be of no help in this case). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 Raghavendra kamath changed: What|Removed |Added CC||ra...@raghukamath.com --- Comment #20 from Raghavendra kamath --- @ Kate the filter masks are designed to affect everything beneath them, when you merge it , it creates a layer similar to what "new layer from visible" does. perhaps you need filter masks and not filter layer. In the scenario of your latest attachement, can you show us images of what is expected after the merge of two layers (marked in red). Should the filter be only applied to layer 11 and merged, but then the remaining layer won't have the filter applied to it. Can you show us the resulting merged layer in your ideal case. As in a screenshot of what the resulting layer should look like would help. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #19 from wolthera --- I have the feeling this could be solved by you not using the copy blending mode? Because that is what causes this distinct merging behaviour. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #18 from katearche...@yandex.ru --- woops, it seems I've posted at the same time as wolthera overriding the status, sorry for that. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #17 from katearche...@yandex.ru --- Created attachment 122765 --> https://bugs.kde.org/attachment.cgi?id=122765=edit merge within a group test -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 katearche...@yandex.ru changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #16 from katearche...@yandex.ru --- Actually I've made new test and results are even more weirder than before and it cant be treated as _expected_ bahaviour. I've upload the file, the steps are: 1. select two layers marked red 2. Merge them with ctrl-e. The result is that the layer beneath the merged one is now part of the merged layer and it's weird as hell. This is not what anyone would expect like at all. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 wolthera changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED CC||griffinval...@gmail.com --- Comment #15 from wolthera --- Hi Kate, This was actually discussed with two artists in the IRC(raghavendra kamath and me). The conclusion was that it was preferable to have merges result in the closest thing that the current projection does. If you do ctrl+g beforehand, the projection will show the result that merging these layers without taking the layers outside the selection into account will result into. This is especially important with color adjustment filters, or when the underlying layers are not a flat color. This is the most consistent result we can come up with. We did take your desire into account, but we honestly believe this is the most consistent. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990
katearche...@yandex.ru changed:
What|Removed |Added
Resolution|INTENTIONAL |---
Status|RESOLVED|REOPENED
--- Comment #14 from katearche...@yandex.ru ---
I strongly disagree. Information IS destroyed.
Let's assume I'm a new user knowing nothing about blend modes and internal
workings of krita.
It's confusing as hell that in one case selecting two layers: a filter layer
and a paint layer and merging them will result in losing a transparency while
applying a filter from filters menu _OR_ merging two paint layers will preserve
transparency.
The strait-forward way of thinking in merging layers is that if the pixels are
transparent("what you see is what you get") they will remain like this. And if
any other merging operation keeps the transparency of the bottom layer why it
must be different for filter layers?
And what you are proposing: to group layers beforehand is _VERY_ unintuitive
and there is no way a user without advanced knowledge of krita inner workings.
And while it's not a bug in itself this is wrong UX behaviour and it should be
discussed more than with one person and preferably with artists not the
developers(I mean no disrespect at all but since you are so deeply involved in
the code itself your point of view is very biased on a UX matter). So I reopen
is so it can be discussed or at least someone other than Dmitry from the
development team will make a statement about the issue.
My point of view on this: If filter layers are merged with selected layers it
should be possible(at least as an option, because why would you force user to
make monkey job and it IS a monkey job that can be clearly automated with a
little effort even via python script) to create a temporary group and merge
that group only so transparent pixels will be preserved.
As it is standing now it's inconsistent with other merging operations and is
confusing(even the other participant in the thread confirms it: "It indeed is
inconsistent. If a Levels filter layer is created and adjusted it does not
behave the same as if HSV filter layer is created and adjusted. The Levels
layer will properly adapt to new layer changes below, whereas HSV seems to
rasterize itself on any change. Merging does lose transparency, which is the
part that seems like a side effect.").
So I propose to at least have a wider discussion why this is cannot be
implemented to have a more consistent workflow with merging layers?
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 Dmitry Kazakov changed: What|Removed |Added Resolution|--- |INTENTIONAL Status|ASSIGNED|RESOLVED --- Comment #13 from Dmitry Kazakov --- I will close the bug as resolved/intentional now. The functionality requested by the user is available by pressing Ctrl+G,Ctrl+E. Changing the way how adjustment layers are merged into "group them and merge" approach will make users even more confused. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #12 from Dmitry Kazakov --- Git commit 59d8e62207acf10afca0158e377c1775c18eb857 by Dmitry Kazakov. Committed on 20/09/2019 at 14:00. Pushed by dkazakov into branch 'master'. Add a comment about merging adjustment layers Krita sticks to "keep image unchanged" approach when merging layers, just state it clearly in the code, so we wouldn't spend time on discussing that again. M +3-0libs/image/kis_adjustment_layer.cc M +28 -0libs/image/kis_layer_utils.cpp https://invent.kde.org/kde/krita/commit/59d8e62207acf10afca0158e377c1775c18eb857 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #11 from Dmitry Kazakov --- Hi, katearcher89! The information is not destroyed. That is how the adjustment layers work. They **copy** the result of the entire projection beneath them into their point of layer stack. If we implement what you propose, the merge operation will **change** the look of the image, which is against our definition of a merge operation. Can you try to select you layers, then press Ctrl+G and Ctrl+E? It well do exactly what you want (and will alter the image, exactly as you expect it to happen). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #10 from katearche...@yandex.ru --- The most intuitive way of thinking about the result is the "what you see is what you get" approach in my opinion. In the most obvious cases at least. While it is indeed unclear what you should get when different blend modes are involved the current(as of 4.2.6) behaviour discards the transparent pixels completely in any case regardless blending modes involved. I've done a simple test case: 1. Created a new file. 2. Created one layer(normal blending mode) and made few strokes(so other than strokes the layer is transparent) on it. 3. Created an hsv layer and shift hue a little. 4. Merged these two layers. 5. Lost all transparent pixels on the resulted layer. The key word here is lost. By no way I cannot foresee that the result of the applied hue shift would be losing pixels that were otherwise(without merging and in normal blend mode) there. Even worse: it's inconsistent with the other way of shifting hue(or applying filters to a layer for that matter) via filters menu(or via hotkeys like ctrl-u in the hsv case). It's simply and plainly wrong at all levels. Information should not be destroyed. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #9 from Dmitry Kazakov --- I'm looking into this bugs now. Firstly, about the blending mode. Krita follows these rules: 1) If merged layers have **the same** blending mode, then layers are merged together using "Normal" blending mode, and the result layer is set to the original blending mode. That is the only way that preserves the look of the image. 2) If merged layers have different blending mode, then there is no way to preserve the look of the image. It is theoretically impossible. Therefore Krita falls back to merging the layers using their own blending modes and resetting the blending mode of the destination layer to Normal. This way the user will lose minimum of information. And if he selects all the layers from the background layer, he'll get exactly what he expects to get. Conclusion: don't merge layers with different blending mode unless you really know what you are doing (and how these blending modes work). About adjustment layers, I'm not sure yet. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 Boudewijn Rempt changed: What|Removed |Added CC||b...@valdyas.org Assignee|krita-bugs-n...@kde.org |dimul...@gmail.com Status|CONFIRMED |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #8 from katearche...@yandex.ru --- (In reply to bugs from comment #7) > > Regarding blending modes, if memory serves, this is how Photoshop behaves. > It might not make both layers Normal, but it has to decide between one or > the other. It seems like a complex issue no matter the program. What is the > expected result? Yes, I have tried to merge layers with different blend modes in photoshop and the behaviour is exactly the same: layers are blended and merged and then the resulted layer is set to normal. As for what was expected: I was thinking that since merging preserve the name of the bottom layer it should do the same for other properties like a label's color for example and blend mode as well. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #7 from b...@fastmail.com --- (In reply to katearcher89 from comment #6) > (In reply to katearcher89 from comment #5) > > > > I stand corrected: I've tried merging paint layers in different modes and by > > now, in 4.1.1 when merging any blend mode set to any higher level is > > discarded as well, meaning that the layers that are supposed to me merged > > are merged in normal blending mode. It's a totally wrong behaviour and I'll > > report that bug as well, since that means that we have no means to merge a > > layer stack without loosing color info and preserving transparency of that > > layers. > > after a little more experimenting I've found that that was mostly my > mistake: two layers with different blend modes merging totally fine but > after the merge the resulted layer is set to normal(instead of whatever > blend mode was assigned to the bottom layer of the selection) thus producing > different visual effect other that before the merge. Not sure is this > defaulting to normal blend mode of the merged layer a bug of a feature > though. Perhaps "intended" was a poor word to use. It indeed is inconsistent. If a Levels filter layer is created and adjusted it does not behave the same as if HSV filter layer is created and adjusted. The Levels layer will properly adapt to new layer changes below, whereas HSV seems to rasterize itself on any change. Merging does lose transparency, which is the part that seems like a side effect. This is because it becomes a regular paint layer using the values it had previously, which could have contained all layers beneath it. It is no longer a "Filter Layer", it is simply a "Paint Layer". Whether or not this is good or bad is unknown, this is coming from a non-developer, trying to explain how it is understood. Regarding blending modes, if memory serves, this is how Photoshop behaves. It might not make both layers Normal, but it has to decide between one or the other. It seems like a complex issue no matter the program. What is the expected result? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #6 from katearche...@yandex.ru --- (In reply to katearcher89 from comment #5) > > I stand corrected: I've tried merging paint layers in different modes and by > now, in 4.1.1 when merging any blend mode set to any higher level is > discarded as well, meaning that the layers that are supposed to me merged > are merged in normal blending mode. It's a totally wrong behaviour and I'll > report that bug as well, since that means that we have no means to merge a > layer stack without loosing color info and preserving transparency of that > layers. after a little more experimenting I've found that that was mostly my mistake: two layers with different blend modes merging totally fine but after the merge the resulted layer is set to normal(instead of whatever blend mode was assigned to the bottom layer of the selection) thus producing different visual effect other that before the merge. Not sure is this defaulting to normal blend mode of the merged layer a bug of a feature though. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #5 from katearche...@yandex.ru --- (In reply to katearcher89 from comment #4) > (In reply to bugs from comment #2) > > krita-4.2.0-pre-alpha-127857b-x86_64.appimage > > > > confirming > > > > However, this seems intentional, or at least a side effect of how filter > > layers work. > > ... > > this can be proven by converting a filter layer to a paint layer. This is > > essentially what it is doing when merged down. The act of merging in this > > method conflicts with transparency preservation. > > Actually it's not entirely correct: when merging we are effectively creating > a temporary group containing all the layers that were selected. And > transparency preservation works totally fine with merging two paint layers > with different blending modes. > > I.e. let's say we have three layers, a base/bottom layer, a painted layer > and a top layer with overlay blending mode set having some gradient drawn in > that layer; if we merge two top layers parts of the painted layer that were > covered with the overlay will stay 'overlayed' and parts of the overlay > layer that were over transparent parts of the painted layer will be still > there but changed to normal blend mode, and there will be now pixels taken > from the bottom layer at all. > > Using hsl or other color-tweaking filter layers doing effectively the same: > changing the color of pixels underneath it. And they should not take any > pixels that is not included in the merge selection. > > Moreover on the transparency issue let's say that it is intended(although I > highy doubt that since I see no use case for such behaviour), but using > transparency mask on filter layer has no effect as well -- if the filter > layer has some transparency mask it is discarded during merge as well. I've > attached the file to demonstrate it. I stand corrected: I've tried merging paint layers in different modes and by now, in 4.1.1 when merging any blend mode set to any higher level is discarded as well, meaning that the layers that are supposed to me merged are merged in normal blending mode. It's a totally wrong behaviour and I'll report that bug as well, since that means that we have no means to merge a layer stack without loosing color info and preserving transparency of that layers. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #3 from katearche...@yandex.ru --- Created attachment 115202 --> https://bugs.kde.org/attachment.cgi?id=115202=edit filter layer with transparency mask merge -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #4 from katearche...@yandex.ru --- (In reply to bugs from comment #2) > krita-4.2.0-pre-alpha-127857b-x86_64.appimage > > confirming > > However, this seems intentional, or at least a side effect of how filter > layers work. > ... > this can be proven by converting a filter layer to a paint layer. This is > essentially what it is doing when merged down. The act of merging in this > method conflicts with transparency preservation. Actually it's not entirely correct: when merging we are effectively creating a temporary group containing all the layers that were selected. And transparency preservation works totally fine with merging two paint layers with different blending modes. I.e. let's say we have three layers, a base/bottom layer, a painted layer and a top layer with overlay blending mode set having some gradient drawn in that layer; if we merge two top layers parts of the painted layer that were covered with the overlay will stay 'overlayed' and parts of the overlay layer that were over transparent parts of the painted layer will be still there but changed to normal blend mode, and there will be now pixels taken from the bottom layer at all. Using hsl or other color-tweaking filter layers doing effectively the same: changing the color of pixels underneath it. And they should not take any pixels that is not included in the merge selection. Moreover on the transparency issue let's say that it is intended(although I highy doubt that since I see no use case for such behaviour), but using transparency mask on filter layer has no effect as well -- if the filter layer has some transparency mask it is discarded during merge as well. I've attached the file to demonstrate it. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 b...@fastmail.com changed: What|Removed |Added CC||b...@fastmail.com Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #2 from b...@fastmail.com --- krita-4.2.0-pre-alpha-127857b-x86_64.appimage confirming However, this seems intentional, or at least a side effect of how filter layers work. Filter layers have to cover all layers below in the stack, unless grouped. When merged or changed it becomes rasterized into what it was displaying, this can be proven by converting a filter layer to a paint layer. This is essentially what it is doing when merged down. The act of merging in this method conflicts with transparency preservation. The blur layer strangeness is an issue, however. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 398990] Filter layer ignores transparency when merged with layers beneath it
https://bugs.kde.org/show_bug.cgi?id=398990 --- Comment #1 from katearche...@yandex.ru --- Created attachment 115191 --> https://bugs.kde.org/attachment.cgi?id=115191=edit an example file to demonstrate the issue -- You are receiving this mail because: You are watching all bug changes.
