bugMyPaint - Bugs: bug #20295, Lighten mode wrongly merged in...

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #20295: Lighten mode wrongly merged in places

Submitted by:  David Gowers <ion9>
Submitted on:  Tue Nov 13 13:55:38 2012  
Severity: 3 - NormalPriority: 5 - Normal
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: Planned Release: None
Operating System: 

(Jump to the original submission Jump to the original submission)

Fri Jan 4 18:17:02 2013, comment #9:

This bug is already Fixed in git, but is marked as Open. I am now
marking it Closed because a new stable version, 1.1.0, is
available, meaning that this bug no longer affects the current
stable release.

Please reopen if this problem reoccurs with the new version of

Andrew Chadwick <achadwick>
Project Administrator
Tue Dec 11 11:03:50 2012, comment #8:

I can confirm Maxy's fix as being working code, and I think this bug is fixed - with reservations. The solution we have now might cause more confusion for users in the long run than it will solve if it's the only merge command.

I'd like to work on a more judicious "Merge Visible Layers" command, but that's going to require RGBA compositing and a background that can be turned off as needed. But that's a separate bug report. Having a separate "convert to normal" command which doesn't perform a merge is a Very Good Thing to have, for pure interoperability reasons. Kudos to Maxy for that!

There are good, open questions to answer for OpenRaster about how (or if) to specify compositing operations for plain old viewing too. A survey of how common software apparently does things is needed, given the observed Gimp behaviour :)

Andrew Chadwick <achadwick>
Project Administrator
Sun Nov 25 13:27:35 2012, comment #7:

PS: some users also want GIMP-style merging in addition (the first post in the linked forum discussion). But you really need to know what you're doing to make use of that behaviour. So yes there is more work that could be done here, but it's not related to the original bug report.

Martin Renold <martinxyz>
Project Administrator
Sun Nov 25 12:42:54 2012, comment #6:

I have reworked the rgbu branch a bit and pushed it to master.

Depending on the mode and effect, background pickup can be minor or quite notable. There is a bit room for improvement, too - the alpha is increased a bit more than strictly required when merging. Maybe I'll fix that. But I think in many use-cases it simply isn't a problem.

I consider this fixed, please test.

Martin Renold <martinxyz>
Project Administrator
Sun Nov 18 10:34:25 2012, comment #5:

I have updated the rgbu branch to work with current master: https://gitorious.org/~maxy/mypaint/maxy-experimental/commits/rgbu2

Here is a screencast that shows the bug as reported, and the behaviour in my rgbu2 branch: http://maxy.homeip.net/misc/rgbu2-branch-bugtest.ogv

Here is the relevant forum thread about merging layers: http://forum.intilinux.com/mypaint-development-and-suggestions/merging-weird-behavior/

Martin Renold <martinxyz>
Project Administrator
Wed Nov 14 21:55:30 2012, comment #4:

Andrew: You shouldn't have to move any layers. There are already >1 areas of paint which are invisible before the merge (because it's being applied in Lighten mode and is not lighter than the BG), and which show up after the merge. If it really does look the same before and after, that's a .. anti-bug? (seeing as this is a bug report for how it DOESN'T look the same before and after)

Martin: IMO the appropriate way to handle transparency control is to provide some kind of masking, where the alpha channel of one layer masks the layers atop it. I think it's not a big deal that the merged paint could be solid-er as long as a way to do that is on it's.. way, especially considering that some effort is made to avoid solidifying. In any case I absolutely agree that it's the most predictable + reliable choice, and transparency is not a big deal.

GIMP-2.8 has the same behaviour as 2.6. Not sure about 2.9 (development version), as GEGL introduced some changes in the way compositing is put together.

Out of curiosity, what would the code do in this case I attached? (where the best solution seems to be to decrease alpha to 0 for areas of no visible effect)

David Gowers <ion9>
Project Member
Wed Nov 14 18:36:21 2012, comment #3:

Just realized, that when I said "the sane thing to do" I meant sane for painting, which usually produces a solid result.

The main drawback is that it does always pick up the background color, so if your goal is really to make a translucent painting, your completely screwed. (The whole compositing is wrong for this usecase, already before you merge.) My opinion is just that you almost never have this usecase when painting, it's more an "image editor" thing - supporting this will probably mean to make the "normal" usecase more complicated?

Martin Renold <martinxyz>
Project Administrator
Wed Nov 14 18:24:18 2012, comment #2:

To be more precise: the solution that I have proposed (and implemented in a branch somewhere) doesn't make all strokes solid. How much it "solidifies" the layer depends on the blending mode and colors used. The result is always a "normal" layer, and it tries to increase the alpha only if the same result cannot be achieved by changing the colors.

The implementation is just a bit messy, maybe I'll clean it up for master. IMO it's the sane thing to do, everything else will be predictable only to very advanced users. It also has the advantage that it can convert any layer into "normal" mode, side-stepping all the inter-application compatibility headaches (except the one about linear light).

Martin Renold <martinxyz>
Project Administrator
Wed Nov 14 16:25:22 2012, comment #1:

(You need to move the top layer so a dark bit and a light bit are over the background, right? It looks the same before and after if I don't.)

What you've just described is actually how it's supposed[1] to behave when composited over alpha=0, and all modes will suffer for it to varying degrees. It's very apparent with lighten and a mid-grey background of course, because dark bits of the "Lighten" layer will not be shown over that background.

MyPaint composites differently to other programs because we start with a solid background, and all the editable layers are composited onto that. This results in lots of oddness for users because this behaviour is different to the way its own Merge Down operation works!

IMO we should support a real backgroundless display mode (with real alpha checks) and only support single merge operation, "Merge Visible", which is only enabled when the background is turned off. Then what you see before the merge will be precisely what you get after the merge with zero surprises. But maybe I'm being overly strict!

Maxy favours a Merge Down which picks up the background pixels, making all strokes solid. I'm not so sure. What if you them move the layer expecting it to be transparent?

[1] We use the lighten function from the SVG specifications because that is how OpenRaster is defined. Take a look at the yellow circle in


If the backdrop is empty, the top layer is just used, as if in Normal mode. It's what you get from MyPaint when you save as a transparent (backgroundless) PNG, but not when using the program because the background layer is a proper layer.

Notably, GIMP 2.6 (not sure about 2.8) does something different again: it somewhat weirdly composites the results of "effect" layers like Burn or Lighten using what looks like src-in and not src-over unless the effect layer is the bottom layer in the stack in which case it's treated as a Normal layer and not an effect.

For an effect layer, the "Top layer" above is the result of blending the colous of the bottom layer and the real top layer.

Andrew Chadwick <achadwick>
Project Administrator
Tue Nov 13 13:55:38 2012, original submission:

In particular, though the layer mode behaves correctly, interaction with background is wrong: pixels where there is no content in the layer beneath are applied as if they were using Normal mode.

Example document attached -- compare the result of merging the layer 'enlightenment' down with the display MyPaint gives before merging.

This may occur with other modes -- in particular I suspect Darken -- but I haven't had the time to do further tests yet.

David Gowers <ion9>
Project Member


Attached Files
file #16754:  20121114-001_a.ora added by ion9 (218kB - image/openraster)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by achadwick (Posted a comment)
  • -unavailable- added by ion9 (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri Jan 4 18:17:02 2013achadwickOpen/ClosedOpen=>Closed
    Sun Nov 25 13:27:35 2012martinxyzStatusConfirmed=>Fixed
    Sun Nov 18 10:34:25 2012martinxyzStatusNeed Info=>Confirmed
    Wed Nov 14 16:25:22 2012achadwickStatusNone=>Need Info
    Tue Nov 13 13:55:38 2012ion9Attached File-=>Added 20121114-001_a.ora, #16754
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup