GNOME Bugzilla – Bug 143315
Turning off alpha channel visibility should make alpha=255
Last modified: 2012-10-07 20:38:21 UTC
Someone mentioned this on IRC but didn't file a report. Currently when the alpha channel is turned off, the image goes away (0 opacity). It should instead give all pixels full opacity. (I'm not sure if this is a bug or an enhancement, but currently the alpha visibility toggle is pretty useless.)
Same thing happens in 2.0.1.
That's indeed a very old bug that needs to be fixed.
Well, this will be quite a nasty one. The relevant code is in paint-funcs/paint-funcs-generic.h, in several functions that take an argument called "affect" which is a boolean array determining which channels are affected. It looks like fixes would be needed in a number of spots there.
In the absence of someone actively working on this one, it doesn't make sense to keep it on the 2.2 milestone. Bumping to Future.
Created attachment 37264 [details] [review] A Patch that seems to fix the problem This is a patch that seems to fix the problem. It changes the functions that Bill Skaggs pointed to, and does what seemed right to me. I tested it and it seems to be working pretty nicely, from what I've tried.
A bit of testing -- the patch seems to do the right thing when there is just a single visible layer. When there are multiple layers, though, it would be expected to make the top layer opaque, and it doesn't.
SHLOMIF->BILL-SKAGGS: yes, I can reproduce the behaviour. I tried to trace the problem and it seems to be a problem in the combine_sub_region() function in app/paint-funcs/paint-funcs.c. My problem right now is that, for the life of me, I cannot find where this function renders the pixels in dest that belong to the non-alpha channels. I'll try to work on it a bit more.
I also wonder whether you shouldn't be setting the opacity to 100 instead of just removing the lines that set it to 0 -- but I haven't yet looked for problems this might cause.
Created attachment 37331 [details] [review] A Patch against CVS head that now also resolves what Bill reported This is a patch against CVS head that corrects the full transperency problem and also corrects what Bill Skaggs reported (that it doesn't make the top layer opaque). I did not fully tested it on all the configurations in combine_sub_region() (some of which don't make use of the macro I modified). I only have a vague understanding what I did, but I'm sure that if affect[alpha] is TRUE, the original behaviour is preserved.
Seems to work rather well but I found a corner case which doesn't seem to be handled correctly. Please load the XCF that I will attach and turn off alpha channel visibility. You should notice that the top layer doesn't become completely transparent.
Created attachment 38281 [details] XCF image showing a problem
Noting that the current behavior is totally and absolutely useless (turning off the alpha channel gives a completely transparent image no matter what), it might be reasonable to let Shlomi commit his changes and work on issues within cvs. This would prevent things from bitrotting or getting lost.
That's Shlomi's decision; iirc he has CVS write access.
Created attachment 38328 [details] [review] A Patch against CVS head that now also resolves what Sven reported This is an updated patch against CVS head that also resolves what Sven reported.
Comment on attachment 38328 [details] [review] A Patch against CVS head that now also resolves what Sven reported OK, per Bill Skaggs' request, I commited this patch to the CVS. This is so we can get as much input as possible on this patch, and problems user encounter with it.
Works nicely for the things I have tried. So, let's call it FIXED unless there is some reason to think otherwise.
For purposes of cross-reference, note that bug #307213 seems to have been caused by the changes made here.
I think this change was made in the wrong place. It should only affect projection code, but was done in a place which modifies image data and is used for much more that just projection compisiting. It should IMHO be reverted and fixed differently.
Reverted the patch: 2005-11-09 Michael Natterer <mitch@gimp.org> * app/paint-funcs/paint-funcs-generic.h * app/paint-funcs/paint-funcs.c: reverted patch which makes alpha=255 when turned off because these functions are not only used for display projection. Re-opens bug #143315. Fixes bug #307213.
well, hopefully the following belongs to here: make a selection not with the rectangular tool (elliptic, lasso, color...) copy this selection to a new image. in this new image switch off the alpha-channel. what you get is a rectangular image in the bounds of the selection you've made in the source image. this is new to 2.3.5. it doesn't happen in 2.2.8.
Nope, this comment doesn't belong here because the change in the 2.3 tree has been reverted in the meantime. Please ignore comment #20.
Bumping target to "Future" because 2.4 is approaching, and any change that solves this issue is going to be very intrusive and require quite a bit of testing.
*** Bug 595851 has been marked as a duplicate of this bug. ***
Fixed in master: commit d169244955128e1fd5eeeebc2797e4677c1a2135 Author: Michael Natterer <mitch@gimp.org> Date: Sun Oct 7 22:36:42 2012 +0200 Bug 143315 - Turning off alpha channel visibility should make alpha=255 When the alpha channel is "invisible", make it 1.0 not 0.0. app/operations/gimpoperationmaskcomponents.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)