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 569330 - No alpha channel by default and false alpha channel created
No alpha channel by default and false alpha channel created
Status: RESOLVED NOTABUG
Product: GIMP
Classification: Other
Component: General
2.6.3
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2009-01-27 13:25 UTC by terzag
Modified: 2009-02-08 18:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description terzag 2009-01-27 13:25:44 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).
Comment 1 Michael Schumacher 2009-01-27 13:54:55 UTC
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.
Comment 2 Leo 2009-01-29 09:05:42 UTC
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).
Comment 3 Michael Schumacher 2009-01-29 16:05:30 UTC
The fact that layers may not have an alpha channel is not a bug.
Comment 4 terzag 2009-01-29 16:16:50 UTC
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
Comment 5 Michael Schumacher 2009-01-29 16:23:05 UTC
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.
Comment 6 terzag 2009-01-29 16:40:51 UTC
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 ?
Comment 7 Michael Natterer 2009-01-29 16:44:46 UTC
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.
Comment 8 terzag 2009-01-29 16:58:09 UTC
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 ?
Comment 9 Leo 2009-01-29 17:13:56 UTC
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?
Comment 10 Michael Natterer 2009-01-29 17:44:19 UTC
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?
Comment 11 terzag 2009-01-29 17:57:52 UTC
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.
Comment 12 Leo 2009-01-29 18:05:59 UTC
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?
Comment 13 Martin Nordholts 2009-01-29 18:16:04 UTC
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
Comment 14 Michael Natterer 2009-01-29 18:53:05 UTC
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.

Comment 15 Sven Neumann 2009-01-29 22:27:47 UTC
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.
Comment 16 Leo 2009-02-08 09:09:11 UTC
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.
Comment 17 Martin Nordholts 2009-02-08 09:17:14 UTC
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?
Comment 18 david gowers 2009-02-08 11:06:28 UTC
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 )


Comment 19 Sven Neumann 2009-02-08 16:43:25 UTC
The point is that we don't have such discussion in the bug-tracker. They need to happen on the gimp-developer mailing-list.
Comment 20 Martin Nordholts 2009-02-08 17:12:27 UTC
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.
Comment 21 Sven Neumann 2009-02-08 18:51:32 UTC
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.