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 486902 - Remove the "add/remove alpha channel" option for layers
Remove the "add/remove alpha channel" option for layers
Status: RESOLVED DUPLICATE of bug 778523
Product: GIMP
Classification: Other
Component: User Interface
2.4.x
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 739361 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-10-15 18:11 UTC by michael grosberg
Modified: 2017-02-17 21:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description michael grosberg 2007-10-15 18:11:26 UTC
Reasoning:
1.Simpler is better (as long as it's still providing the same functionality).
2.Alpha channel per layer is confusing: for the uninitiated, it is hard to understand the difference between this and a layer mask, or this and adding a new channel which serves as an alpha channel for the entire image.
3.Removing an alpha channel from a layer is useful only on the background layer – and even that is debatable.
4.A layer with no alpha channel is almost the same size in KB as a layer with a completely white (opaque) alpha channel.

The competition (Photoshop)
1.The background layer is a special case – it is the only layer which can lose its alpha channel. It is always named "Background" in italics. It has a lock icons next to it but cannot be unlocked by the usual method (widget is grayed out). 
2.A background layer can be promoted to a normal layer from the layers menu or by renaming it.
3.A normal layer can be made into a background layer by menu command, and is then dropped to the bottom of the layer stack and loses its transparency.
4.The menu item for both actions is found under layernew, although no new layer is desired or created by this.
5.Renaming as a way to unlock the layer makes no sense and has no logical connection between action and consequence.
6.This solution is not intuitive, requires learning, and is not easily discoverable by newbies because of lack of clear on-screen indication, placement of menu item and lack of layer context menu item.

Solution:
1.remove the "add alpha" and "remove alpha" from menus
2.change behavior of layer lock - "lock alpha channel" – so that when eraser is used on a locked layer, pixels are erased to background color instead of  transparency (this is also a more reasonable behavior to be expected from a feature that promises to lock the alpha channel)
3.rename "lock alpha channel" to "lock layer" or "lock transparency"
4.by default, lock the first layer of a new document if the document is a loaded single-layer format (jpg, png etc) or a new document with white, background or foreground fill.
5. Remove the warning dialog when exporting to format which support opacity: only export opacity if the user unlocks the layer and changes the alpha channel.

Advantages:
1.A single concept to learn – layer locking.
2.The layer lock widget is easily visible, hence no confusion for newbies as to why they can't delete to transparency on background layer.
3.A  simpler app with shorter menus.
4.Application still provides the same functionality.


Other information:
Comment 1 Sven Neumann 2007-10-15 19:16:14 UTC
Nice description, but you should really not use Bugzilla for such ideas. Please discuss them on the gimp-developer mailing-list instead. Bugzilla is for ideas that have been decided on and that are scheduled for implementation, not for starting a discussion.
Comment 2 Michael Natterer 2007-10-15 19:23:54 UTC
It was as in Photoshop before and was explicitely changed to be
more flexible. Apart from that, the change the the eraser tool
sounds pretty useful to me. But as Sven said, you should discuss
such things on the mailing list so more people can participate.
Comment 3 michael grosberg 2007-10-15 20:53:23 UTC
OK, how do I remove this bug? resolve as invalid / wontfix / other?

I have problems posting to the list - I did try before posting it here (using Gmane), but I can try again. 
Comment 4 Raphaël Quinet 2007-10-16 07:48:17 UTC
Let's keep this bug report open for the moment, because the ideas are interesting anyway.  We can decide to close it or modify it later, depending on the results of the discussion on the gimp-developer mailing list.  I am tentatively setting it on the 2.6 milestone.
Comment 5 Pucelo 2007-10-28 01:54:28 UTC
Please, don't remove the "add alpha" and "remove alpha" from menus. I think that it is useful.

"Simpler is better (as long as it's still providing the same functionality)"
Is MS Paint better than GIMP? I think that simpler is less powerful. And removing this options, will decrease the functionality.

"Removing an alpha channel from a layer is useful only on the background layer
– and even that is debatable."

This is not true. This is very useful in not background layers with some filters. And in some situations, I can save RAM memory removing unneeded alpha channels in layers without transparency and thousands of pixels.

"2.Alpha channel per layer is confusing: for the uninitiated, it is hard to
understand the difference between this and a layer mask, or this and adding a
new channel which serves as an alpha channel for the entire image."

I understood it in less than five minutes. I am not a newie, and I think that GIMP mustn't be a program for uninitiated people only. Advanced users don't want a Tuxpaint.



A very interesting solution could be, hiding this options with a new configuration option in preferences. If a user wants to use it, he can reactivate it, and use it. This option in preferences, could be named "Show advanced options on alpha channel in layers". Advanced users will use it.

But please, don't remove it. It not confuses me, and I like (and need) layers without alpha channel.
Comment 6 Sven Neumann 2007-10-28 09:53:53 UTC
Pucelo, such discussion doesn't belong here. We have a mailing-list for this. And rest assured, you wouldn't even notice that add/remove alpha channel is gone. It is simply nothing that the user needs to care about.
Comment 7 Sven Neumann 2008-01-08 15:46:13 UTC
We should try to get the discussion on this going. Hopefully with some input from the UI team this could help to make GIMP easier to use, for newbies and pros.
Comment 8 peter sikking 2008-02-03 18:56:35 UTC
OK, I see couple of concepts here:

Looks like a cool way forward to me to have all layers always with alpha, even the bottom/background layer. The bottom layer simply gets it alpha filled in appropriately on creation (new image, open image).
I would not get smart with the alpha of a layer that gets moved down explicitly or implicitly to the bottom of the stack.

lock alpha (not to be confused with lock layer): after being explained for the umpteenth time what one does with that (lock the shapes of the graphics) on the irc, I think it simply needs a better name. lock alpha is a perfectly rational name to give it, but lock shapes is so much clearer.

use eraser on a locked alpha layer: better do nothing, instead of something smart. didn't we recently discussed giving proper feedback why nothing happens in this case (big fat text on the canvas?).

the catch seemed to be moved then to exporting later stacks with transparent holes to image formats that do not support transparency. 
Comment 9 david gowers 2008-02-03 22:20:55 UTC
I think that if we did what you are suggesting, peter, we would also need to consider 'cut' behaviour -- there are plenty of cases where the neutral color for a layer mode (for example, white is neutral for Multiply mode) is better than transparency -- the least of which is that drawing over transparency doesn't have at all the same effect as drawing over white (esp. when alpha is locked).
With just the change you propose, I would be forever fixing up the areas that should be neutral colored but ended up transparent when I wanted to move something.
'lock shapes' makes a lot of sense to me -- that is certainly how I think about it, despite having a sound technical understanding of alpha.
Comment 10 Michael Natterer 2008-02-04 11:21:16 UTC
I think we require the user to understand much more complex concepts
than simple transparency. I don't think abstracting it away entirely
does any good. As David says sometimes you simply *want* the eraser to
erase to some background color instead of transparency.

We should rather attempt to have clear indications whether the layer
has alpha or not, *other* than just the bold vs. normal layer name
in the layers dialog.
Comment 11 weskaggs 2008-02-04 21:35:05 UTC
I basically agree with Peter that it would be preferable for all layers to have alpha.  For clearing or erasing to a background color, there could be specific commands or options.

This would however be a real pain to handle for plug-ins that can't deal with alpha channels, which include a number of file-save and file-open plug-ins.  All of these would have to be rewritten if there was no longer any such thing as an alpha-less layer.
Comment 12 david gowers 2008-02-04 21:41:37 UTC
re comment #10
.. Indicate via the sensitivity of 'lock alpha' checkbutton?  I thought GIMP might
already do that, but it is not the case. In any case, I believe that is something GIMP should definitely do.
Comment 13 Martin Nordholts 2008-05-31 20:14:02 UTC
Didn't happen for 2.6 and I doubt anyone will get around to do it for 2.8, but let's put it on the 2.8 milestone anyway.
Comment 14 Leo 2009-02-08 09:23:21 UTC
This bug report promotes the concept to implicitely have layer transparancy.
I have written bug 569330 for the missing layer transparancy.
I want to link these reports to clarify the position of the users.


Subject: default transparancy in upper layers disappeared in Gimp 2.6.x
(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 15 Michael Schumacher 2009-02-09 09:53:57 UTC
... and if you had posted this on the gimp-developer list, someone might even read it.
Comment 16 Martin Nordholts 2010-01-15 20:00:03 UTC
According to the current estimates we will not have time to implement this for 2.8. Postponing to 2.10.
Comment 17 Martin Nordholts 2011-03-14 07:28:15 UTC
Low priority compared to things on our roadmap, moving off milestone
Comment 18 Michael Schumacher 2014-11-05 09:41:06 UTC
*** Bug 739361 has been marked as a duplicate of this bug. ***
Comment 19 mtarzaim 2014-11-05 11:19:59 UTC
I don't even understand why there is still a discussion about it...

It's obvious transparency must be on by default. It's already difficult for beginners to understand the concept of alpha channel (an invisible color? WTH!? ). And it's even more difficult for them to dive into the UI and find the right option in the right menu.

Same with the new image option. Transparency as background should be enabled by default. If you want a white bg, just add a layer and fill it with whatever color you need.

The main argument for gimp is photo montage, i.e layers. Therefore instant use of pictures transparency. There's no reason to force the user to add manually an alpha channel for every single layer in every single project he will ever do.

And the background argument is null. What if I want my projet export to be used in another project? I need to keep the transparent parts, even on the "background" layer.

I use rubber on my picture = I see immediate transparency on my picture.
One click = it works. Always aim for simplicity.
Comment 20 Michael Schumacher 2014-11-05 11:32:30 UTC
There wasn't a discussion about this, actually (for a bit over three years, as you can see from the date of the last comment 17). Without that, the state of anything tends to stay as it is.

As you can see in e.g. comment 8, comment 10 and comment 11, there are a few things to be worked out for any change to happen. 

The important thing is that someone has to be working on them.
Comment 21 Michael Natterer 2017-02-17 21:12:10 UTC
All this pro and contra here shows that we can't just ditch the option.

After fixing bug 778523, I'm going to resolve this one as a duplicate,
even though that's not exactly correct.

*** This bug has been marked as a duplicate of bug 778523 ***