Re: [Gimp-developer] Handling of transparent pixels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17-Dec-2003, usr352@xxxxxxxxxx wrote:
> 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).

Its only inexistant to the calculations. The RGB data doesnt go away, which is
what I think you mean. 
 
> 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.

Well, some image editors have alpha as a transparency mask, which is what would
be better imho. Its better to visualize stuff this way. 

> 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.

I think that all the alpha and transparency mask operations should be folded in
to just doing transparency mask, and then alpha on load be converted to
transparency masks.
 
> 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.

GIMP is exactly the same way. I have no way of doing alpha only operations,
except when hacking up the transparency mask. My suggestion above would fix
this. Colors are RGB, and Alpha is altered through the transparency mask.

> 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.

Having to use anti-erase is a pita. 

In addition to this, it should be possible to copy a transparency mask to a
RGB layer, something GIMP doesnt support afaik. (Which, then, it would appear
as a greyscale image)

-- 
Patrick "Diablo-D3" McFarland || unknown@xxxxxxxxx
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux