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.
