When merging filter layer with layers beneath it the resulted merged layer have no transparency at all with all pixels that were supposed to be transparent filled with a color of a flattened image. How to reproduce: 1a. Download an attachment or: 1b.1. create three layers on the root level. 1b.2. Fill the bottom layer with some color/colors completely. 1b.3. Draw on top two layers something, leaving some pixels untouched/transparent. 1b.3. create a filter layer for hue/saturation/lightness on top and tweak it so there would be seen changes in the color of layers beneath it. 2. Merge all the layers(including hsl filter layer) except for the bottom one(filled with color completely). 3. Get two layers that has no transparent pixels at all with the top one having all of the transparent pixels replaces with pixels of the flattened image beneath it. Expected results: To have transparency from merged layers preserved since they were transparent for a reason before the merge. Actually it happens with any filter layer thrown into the mix, and for an example i've included blur filter layer as well which produces even stranger results. Why is it a problem: it can be solved by wrapping the layers that needed to be merged in a group(since that way a filter layer would inherit the transparency of a group) and merging the resulted group, thus having the result that was expected to be produced, but it's kinda cumbersome and totally unintuitive since every other merging operation on the root level preserves transparency totally fine.
Created attachment 115191 [details] an example file to demonstrate the issue
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.
Created attachment 115202 [details] filter layer with transparency mask merge
(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.
(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.
(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.
(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?
(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.
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.
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.
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).
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 -0 libs/image/kis_adjustment_layer.cc M +28 -0 libs/image/kis_layer_utils.cpp https://invent.kde.org/kde/krita/commit/59d8e62207acf10afca0158e377c1775c18eb857
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.
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?
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.
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.
Created attachment 122765 [details] merge within a group test
woops, it seems I've posted at the same time as wolthera overriding the status, sorry for that.
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.
@ 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.
(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).
Hi Kate, May I request you to answer to the questions in comment 20 ? thank you
(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.
(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 :)
(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?
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.
(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 soooo 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 aggressive but krita is a great piece of software and this kind of papercuts(because I CAN do a merge of selected layers with "what-I-see-is-what-I-get"(I select layers so I want to make actions only with them) approach, it's already there but to do this I have to make actions that are tedious and easily automated and implementing it will make things much more uniform in terms of UX and what is expected from merging selected layers) needed to be talked over.
> 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
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 -0 libs/image/kis_adjustment_layer.cc M +28 -0 libs/image/kis_layer_utils.cpp https://invent.kde.org/kde/krita/commit/ad7e606e1374555a03bb546ecb425076d5acc9fc