Raphaël Quinet <quinet@xxxxxxxxxx> wrote: >> You consider that in certain circumstances this behaviour could >> be considered a bug. > >Yes, because presenting undefined data to the user should be avoided. I mostly agree with you, but there are reasons for me wanting the feature implemented as the result of bug #127930. Here's my point of view of the situation. Conceptually, I agree that alpha = 0 means that the RGB value of the pixel is undefined. Alpha = coverage; coverage = 0 means no pixel is there. Gone. Inexistent. On the other hand, mask = 0 does NOT mean that the corresponding pixel is inexistent, as we already agree (I think). However both alpha and mask accomplish the same goal, i.e. opacity/transparency of individual pixels. Personally, the first time I saw it I found confusing and irritating to have two different elements for the same functionality. Being the things as they currently are, the problem that I see is that you can use alpha to do things that you can't do with mask, and vice versa. I would really like them to be just one, the Alpha Channel, treated just as any other channel, but that's nearly impossible for a number of reasons. As they are currently implemented, the only way to be able to get the advantages of both is to implement some mechanism for converting one into the other and vice versa. There was already one direction, accomplished with "Apply Mask". The only missing one was the reverse, which is what bug #127930 addresses. Now that I can convert from one to another and the other way around, I can take full advantage of both. I'm aware that this operation might expose undefined data, and I agree that there's some problem with that. Indeed I proposed an alternative implementation of #127930 in an earlier message that you haven't commented on, though now I doubt it's even useful. My current idea is rather to try to solve it by defining the guidelines for zero-alpha pixel handling as was mentioned earlier in this thread. In my previous message I suggested to specify them as undefined, but maybe it's not a good idea after all as you seem to defend. I tried PS to see how it handles Alpha. I became quite frustrated. Once I deleted a part of the image and saved and reloaded it, I found *no* way of increasing the opacity of partially transparent pixels, not to mention totally transparent ones, except by painting. All adjustment tools had RGB but no A. Maybe it's just that I'm missing something because I'm not experienced with it but now I think that PS is not my kind of program. But I have sometimes found myself needing to do alpha editing. Here's an example. I drew a closed figure in a layer and as an approximation I put a grayscale copy of it as a mask then I applied the mask (i.e. converted it to alpha) to continue work on it. I went on drawing; when working on the background I suddenly realized that there were small spots within the figure that were partially transparent and I wanted them fully opaque. The figure was complex; if I used the anti-erase I could neglect to opacize the whole figure. My alpha-to-mask script became very handy in that situation. With the threshold preview I could identify the spots that were not fully opaque and remove them. As a final note, I've run into the same request from Gimp users for such a mechanism as the one implemented in Bug #127930 several times already. Pedro Gimeno
