GNOME Bugzilla – Bug 569330
No alpha channel by default and false alpha channel created
Last modified: 2009-02-08 18:51:32 UTC
Using Gimp 2.6.3 In Ubuntu "Intrepid Ibex" 8.10. Same behaviour has been confirmed to me from someone using Gimp 2.6.4. When opening an image, it gets no alpha channel (I think it automatically did in previous Gimp versions). If I duplicate the default layer, both layers get an alpha channel. But this alpha channel doesn't work : selecting a part of the layer and emptying it (del key) paints the selection with the background color instead of transparency. If I add an alpha channel to the default layer before duplicating it, all works as expected. It also happens when creating a new image rather than opening one. It seems like the alpha channel appearing when duplicating the layer isn't real : if I select "create an alpha channel" for the duplicated layer, it works as expected (it doesn't get a second alpha channel and can get transparency).
No alpha channel by default is intentional. The fact that the image does have an alpha channel (or component) that is not available in any layer at the moment is confusing, though.
Gimp 2.6.4 on Windows XP has the same problem: After opening a jpg-file as layer, that layer does not get transparancy - adding an alpha channel cures the problem. However, opening a png-file als layer works normally: The layer gets transparancy (the Delete-key erases the selected area, by which the selected area becomes transparant).
The fact that layers may not have an alpha channel is not a bug.
The problem is that when duplicating a layer, a false alpha channel is created (on each layer). In previous versions, I could duplicate a layer (or paste a picture and create a new layer from it) and remove parts of the one on top, showing the layer underneath through the cut parts. As far as I understand it, an alpha channel was automatically created. With the current Gimp version, the same operations lead to painting parts of the top layer with the background color instead of cutting into it
The RGBA components displayed in the layers dialog do apply to the whole image, not a single layer. Again, the fact that layers may not have an alpha channel - and do not get one unless the user (or a plug-in or script) adds one is an intentional change and no bug.
I'm not sure to understand : do you confirm that in previous versions of Gimp (up to 2.4.x), creating a new layer added an alpha channel but it isn't the case anymore in 2.6.X on purpose ? Or am I misunderstanding ?
There is no bug. There is a difference between a layer's alpha channel and the image's. The image's alpha channel is just a virtual thing that pops up as soon as compositing of layers can result in transparency. You can acheive that by having two layers without alpha channel and reducing the upper's opacity. A layer's alpha channel is something that lives within the layers actual pixels. You can add that alpha channel to each layer individually, and you can also remove it again, using the "Flatten layer" option. And you are right, in previous versions, any layer apart from the bottom one automatically got an alpha channel, this was changed on purpose.
Ok. I don't think this is a logical behaviour : people expect that stacked layer, when cut-through, should show the layer beneath (or is it just me ?). I don't understand the logic behind this change. Do you plan to reintroduce the original behaviour, eventually as an option in the preferences ?
Clarification request: This is the situation of Gimp 2.4.x: 1. Opening a new image as background, does not get transparancy (alpha channel?) 2. Opening an image as layer does get transparancy 3. Duplicating a layer (with transparancy) also gets transparancy Changes for Gimp 2.6.4: 2. Opening an image as layer gets no transparancy when it is a *.JPG - file (an *.PNG file gets transparancy as before) I have no information why this logic has been changed. The old logic makes more sence to me. Could you direct me to the change request, so I can understand the motivation?
No: opening *any* image file as layer --> layer gets what's in the image opening *any* image file without alpha channel --> layer does not have an alpha channel opening *any* image file with alpha channel --> layer does have an alpha channel duplicating *any* layer --> layer is an exact copy (nothing added or removed) What exactly is not logical here?
What isn't logical is that people understand the layers as an analogy of a stack of pictures/sheets : take a pile of (real) photos and cut through the one on top : you'll the see the one just behind through the hole. This is the behaviour used by every image editing software that manipulates layers and was the case with Gimp prior to v. 2.6. The change of behaviour is logical from a "digital picture properties" point of view, not from a usability point of view.
To comment #10: Thank you for this clear explanation. It makes sense. However, for practical use, an option in the preferences as suggested in comment #8 would be welcome. Can this bug-report be forwarded as feature request, or do you not agree to this?
IMO the proper solution for this is to always have an alpha channel or at least make it look like that is the case from a user point of view. Manually managing alpha channels is such a bore. There already is a feature request for this so we don't need to create a new one: Bug 486902 – Remove the "add/remove alpha channel" option for layers
There *is* a difference between a stack of slides and a stack of paper. And there *is* a difference between erasing to transparency and erasing to background, such as there is a difference between erasing on paper with an eraser and cutting a hole in the paper.
There is no alpha channel if you duplicate a layer without alpha channel in 2.6. Not a real alpha channel and not a false one. And yes, this change is intentional.
It took some time to come to following conclusion: Subject: default transparancy in upper layers disappeared (you only get transparancy if the source image you add has this feature) Pro (or why the change was introduced): 1. unclear - possibly a theoretical consideration 2. background layer is treated the same way as top layer (?) Contra: 1. the user must understand which types of source images have transparancy 2. the user must manually add transparancy = additional burden 3. a sudden interface change, away from the industry standard 4. a jpg image has no transparancy, but also no background color, so something is added 5. there is already a tool to fill to the background color Result: 1. The learning curve is increased (newcommers are now already overwhelmed) 2. People using Photoshop, are less inclined to step over. They could use this very recognisable deviation as motivation with "what's next?" Opinion: I see no application where an upper layer would NOT need transparancy: It is part of the design: Images need to be imported in the design, so the design is key, not the limitations of the imported image. i.e. if you import an image with 8 bit colors, it should be converted. In the same way, the missing feature (transparancy) must be added for jpg. I vaguely remember that some image-formats have a background color (an 'extra' feature). In line with your comment #10, you claim that in that case you must preserve that background color only for that layer, so you end up that a layer may have two background colors? In a similar way, OpenOffice.Org could decide to use white as default pen colour, whith the motivation that pens exist in so many colours, and the paper could be of any colour too, so that the user must first select a pen colour. I give basic training to beginners. I keep away from any advanced feature, because it is already a steep learning curve. Upto now, I could get away by not explaining anything about an alpha channel. This happens also for other programs like i.e. MS Word: most advanced features remain unused until the user has sufficient skills. Intensive users use most likely Photoshop due to peer pressure, so newcommers is target Epilog: With this long explanation, I hope to reopen the discussion and open the way to introduce at least an option parameter, which preferably defaults in transparancy in all (upper) layers. --> and not to start a discussion on every point I made <-- The option that all layers have default transparancy also looks fine: Adding layers is a basic skill, so adding a white layer as background image looks quite logical.
I agree with Leo. Even though it might be logical from our point of view as programmers to not add an alpha channel to a duplicated layer with a source layer without alpha, it's not very useful. When is it useful to not have an alpha channel added to the duplicated layer, especially considering that the duplicated layer is put on top of the source layer?
All I can say is that, with my drawing and pixeling, after 2.6 I rejoiced, because I was not required to constantly remove alpha channels in order to get useful erasing behaviour. SO, Pros: 1. Consistent behaviour -- when dragging and dropping a layer, or duplicating a layer, 2. Predictable behaviour -- Edit->Clear, Select by Color, and a range of other tools will have the same effect on a duplicated / dropped layer as on the original layer. Data will not be silently mangled into a different form. Theoretically, there are plenty of people who rely on the opposite behaviour. In fact, the only people I've seen who rely on the opposite behaviour are found in this bug and bug #486902. Instead, I've seen more reliance on layer masks to provide similar functionality I think that files loaded as layers should have transparency added always, and in all other cases, the transparency status of the original layer should be preserved. While not as consistent as I'd like, this strikes me as a reasonable compromise. This addresses Con #1,2; 3 is irrelevent (good and bad behaviour stand on their own), 4 is incorrect (confuses image background, found in most/all images, with layer background, found only in multilayer images), and 5 is irrelevant (filling with background does not begin to address the difficulties with working on a layer with wrongly added alpha. See http://bugzilla.gnome.org/show_bug.cgi?id=486902#c9 )
The point is that we don't have such discussion in the bug-tracker. They need to happen on the gimp-developer mailing-list.
You are right in that this should be discussed on gimp-developer, but we can't close this as NOTABUG until we have agreed that it is NOTABUG.
We decided this change all together before GIMP 2.6. The implemented behavior is exactly what was decided for 2.6. Of course we can change our mind after a discussion on the mailing-list and change it again in a future GIMP release. But for now this is clearly NOTABUG. Actually one could also close it as INVALID as the bug report incorrectly claims that a 'false' alpha channel would be created.