After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760383 - Merging down a layer in Multiply mode loses all its data
Merging down a layer in Multiply mode loses all its data
Status: RESOLVED NOTABUG
Product: GIMP
Classification: Other
Component: General
2.8.16
Other Linux
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2016-01-09 23:33 UTC by Alexandre Prokoudine
Modified: 2016-01-10 14:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alexandre Prokoudine 2016-01-09 23:33:17 UTC
1. Create a new image.
2. Add two transparent layers.
3. Go to the topmost layer, change its mode to Multiply.
4. Paint something on it.
5. Merge it down.
6. All that you painted is lost.

Quick video: https://www.youtube.com/watch?v=FoAeMBZf3e4

The original reporter can reproduce it in both 2.6 and 2.8 on Windows, I can reproduce it in Git master on Linux.

This is possibly related to:

https://bugzilla.gnome.org/show_bug.cgi?id=132498
https://bugzilla.gnome.org/show_bug.cgi?id=595524

In the latter one Martin comments that this should be fixed in GEGL-based GIMP. Apparently, it's not :)
Comment 1 Joao S. O. Bueno 2016-01-10 04:47:00 UTC
While the visible colors of a layer are the result of applying its mode to the comosite image of all  layers bellow it (or all layers on the same group bellow it), "Merge Down" jus applies the layer pixels, using the given mode, to the layer imediately bellow the given layer.

Both on your description and on your video, the layer bellow the subject layer is a fully transparent layer - with 0 opacity (and 0 RGB for each pixel, but that 0 opacity suffices) - So, any values you have on your subject layer are multiplied by zero and the result of that is stored in your target layer. Yes, their values will vanish. 

So, what could be a more correct behavior to that? Disregard the "multiply" mode? Merge the layer down to the next layer, but taking into account all layers bellow the subject layer? 

The current behavior may be unexpected, but I see it as correct. If one needs the multiplied values taking into account more layers than the one immediately bellow, he/she should use "merge visible layers" instead. Yes, GIMP lacks an UI to quickly mark such visible layers, or to just regard as "visible" the layer which actually contribute to the current image projection (and not the ones behind a fully opaque pixel) -  but these would be different issues.

(Now I took the time to check the other bugs you mention - Sven's comments on bug #132498 still apply to this case. The same for the scond case - "lighen only", but the second layer is transparent - if you "lighten up" transparency, you end up with transparency.


So the only thing I can imagine being done here is to issue a warning when one picks "merge down" on (any "non normal" subject layer which underlying immediate layer contains transparent pixels)
Comment 2 Michael Natterer 2016-01-10 14:56:43 UTC
I have nothing to add to the reasons for closing the bugs mentioned
in the original description, and to the explanation from Joao in comment 1
here.

A layer stack is not a mathemetical formula where you can set () at will
and the result doesn't change, it's not a series of operations that
correspond to additions, it's a series of arbitrary operations, any
of which can be destructive.

If you want to merge layer1 and layer1, and '+' represents arbitrary
layer modes, then:

a) layer1 + (layer2 + (layer3 + layer4))

is simply not the same as

b) layer1 + layer2 + layer3 + layer4

Projection compositing is a), and what you ask for is possible only in a
non-existant world that does a layer stack using b). No amount of GEGL
or "correct" code is going to accomplish the impossible :)

Well, now I had something to add anyway...

Closing as NOTABUG.