Re: [Gimp-developer] Handling of transparent pixels
On Sunday 21 December 2003 18:37, [EMAIL PROTECTED] wrote: > Raphaël Quinet <[EMAIL PROTECTED]> wrote: (...) > >> I actually think Joao S. O. Buenos patch to the PNG plug-in is a > >> nice addition/work around the optimization problem - I have yet > >> to try it out, though. > > > >I haven't tried it either, but it could indeed be a nice addition > > to the PNG plug-in. > > And what about the TGA and the TIFF and the > formats? Isn't it > better to solve the issue in a more general way, so that the user > doesn't get confused if such-and-such load plug-in doesn't include > the option to load the alpha as a mask? > Actually, all my patch does is to make avalilable an extra option on the PNG save dialog - a "save transparent pixel color values", which is true by default. It is an extra do the PNG save that doesn't break any other thing, and give to the user control that would only be achievable by some maneuvers of making a selection based on the alpha channel, and zeroing the colors inside it, and which is useful, for instance, to make the file get better compression. If it is found to be THAT useful, it could be moved to the GIMP preferences, but either way, each file format's save plugin would have to be changed to get aware of that. In any case this would be a Gimp 2.2 matter. (And I think BUG 129472 could be merged in just now, in time to the first pre-2.0 without breaking anything) Regards, JS -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Patrick McFarland <[EMAIL PROTECTED]> 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. I mean "conceptually" as I emphasize in my quote above. It's never actually inexistant; there are bytes that hold values for R, G and B and the value of a byte is always defined and existant. >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. That's equivalent to just use alpha and treat it as a channel just like R, G and B are, letting the user to paint in the channel, as I already suggested. >GIMP is exactly the same way. I have no way of doing alpha only operations, >except when hacking up the transparency mask. Wrong. You can manipulate the Alpha channel by using Levels, Curves, Histogram and even Threshold Alpha. The latter requires a separate plug-in, though, since the Threshold tool does not work with the Alpha channel even if it does with the R/G/B ones. And there's of course the eraser and its controversial counterpart anti-erase tools. >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) Copy and Paste works in 1.3 for this task. In 1.2 you can Paste as New, then copy again in the new image and paste back in the original image. Pedro Gimeno ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet <[EMAIL PROTECTED]> wrote: >But as you mention a "proposed change", I will just repeat that this >discussion started because of a change that was introduced during the >feature freeze and that is (IMHO) controversial and goes against the >model that we should try to promote. That's a point where we diverge. I've found some users telling me that sometimes they use Photoshop, sometimes Gimp, depending on what they're intending to do. That's because both do things in different ways. If we try to just clone Photoshop's features, we'll be always one step before it. I think that offering the feature in bug #127930 doesn't break anything to the user. > I was hoping that more >developers would see that the rest of the world around us (e.g., >Photoshop) does things in the right way That's not the right way in my opinion. If I want to make a certain shape look sharper in Photoshop, I can't use a tool like the central slider in the Levels tool in Gimp. Are you sure that that is the "correct" behavior? > and that we should not >introduce new features that have not be thought out carefully and that >break this model The model was already broken before the addition. Anti-erase, Curves, Levels and the plug-in-threshold-alpha with -1 arg hack can all be used to resurrect totally and partially invisible pixels. >Interestingly, the only new arguments (from Pedro, about Photoshop) >are actually supporting what I wrote, even if Pedro does not like it. That was not "the only new argument"; read my message again because it seems that you overlooked some. My new arguments were: - Photoshop does it (that's supporting your argument, provided that "others do it" means supporting your argument). - There are things that can be done only by using alpha and things that can be done only by using layer masks (more on this later), and a means of conversion between them is desirable so that one can take advantage of both and not be limited by what can be done with the flavour he's using. - I have found practical situations where I needed to edit the alpha channel, and the way that Photoshop does things wouldn't have helped me. I even gave an actual example. - Other users have asked me for such a feature as the one implemented in bug #127930, so there's a real need for it in the users' side. >> I actually think Joao S. O. Buenos patch to the PNG plug-in is a nice >> addition/work around the optimization problem - I have yet to try it >> out, though. > >I haven't tried it either, but it could indeed be a nice addition to >the PNG plug-in. And what about the TGA and the TIFF and the formats? Isn't it better to solve the issue in a more general way, so that the user doesn't get confused if such-and-such load plug-in doesn't include the option to load the alpha as a mask? > But alas this is far from solving the real problem, >which is a problem of model/perception. The real problem is that some >GIMP developers and users see alpha as a simple hiding mechanism, >which is wrong (or not always right, depending on your point of view). As Mask and Alpha are quite different things, are you saying that the Apply Mask option should be removed? Or the Create Mask as a Copy of Alpha option? Why should they exist in the first instance, if they're so different and so unrelated? (and why does PS have them?) >As this will be my last message in this thread, I would like to end it >with a question (but I suggest that you do not respond - just think >about it): Why do we need layer masks in the GIMP? Wouldn't it be >easier to paint directly into the alpha channel and simply get rid of >this intermediate step (mask)? Quoting myself (as you seem to have missed it): "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." > Why were masks introduced in the first >place? mmm... because Photoshop had them? }:-) Seriously though, I agree that they're conceptually different and for this reason they don't behave in the same way. This leads to what I already said: there are things that can be done only by using alpha and things that can be done only by using the layer mask. Which, in turn, leads to the need for some mechanism to convert one into the other and vice versa, addressed by bug #127930. I'll just mention some of the things that come to my mind that can be done with Alpha but not with a layer mask: - Use the Eraser as a quick way to hide pixels. With Mask, you have to select the mask, change to the Brush tool, change the current FG color (which you probably were using for other purposes), change the current brush (which you probably were using for other purposes), ensure that the brush options are suitable for the erase operation (or lose your previous settings which you probably were using for other purposes), then paint. - Apply filters that behave consistently to their weighted R,G,B. The filters in the Distorts sectio
Re: [Gimp-developer] Handling of transparent pixels
On Tue, 16 Dec 2003 20:37:30 +0100, Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: > On Tue, 2003-12-16 at 17:59, Raphaël Quinet wrote: > > Basically, the model that we should promote is: > > - layer mask=> hiding mechanism, reversible > > - alpha channel => pixels that are cleared have undefined RGB data, > >not reversible (except for undo) > > > > Breaking this model should be avoided, except in very special cases > > (i.e. obscure features for hackers). > > I'm sorry, Raphaël, but I do not agree with you on this issue either. I > don't see why we should limit the gimp when there is no, at least to me, > obvious reason to do so. Of course I see this from a different point of view: by avoiding a mistake that was recently introduced, I am trying to make sure that the GIMP will not be limited in the future by the constraints that are implied by an incorrect perception of the alpha channel. With the right model, we can make the GIMP more efficient. > I think you will have to accept the fact that this proposed change will > not make it into gimp, at least not at this point in development. This discussion is not so much about a specific change, but more about what model or perception we should promote now and in the future. But as you mention a "proposed change", I will just repeat that this discussion started because of a change that was introduced during the feature freeze and that is (IMHO) controversial and goes against the model that we should try to promote. I was hoping that more developers would see that the rest of the world around us (e.g., Photoshop) does things in the right way and that we should not introduce new features that have not be thought out carefully and that break this model (especially when the same results can be achieved in a better way, with a different implementation). > Allow > me to refer to the minutes of the gimpcon meetings - > http://developer.gimp.org/gimpcon/2003/minutes-1.html#decisions - where > we agreed not to continue discussions just for the sake of the > discussion. I think we have all had a chance to comment on the proposed > changes at this point, and I suggest that we leave it be. Yes, I thought about that. That's why I waited a bit before posting what will be my last contribution to this discussion (for this year, at least). I wanted to be see if anybody would post new arguments. Interestingly, the only new arguments (from Pedro, about Photoshop) are actually supporting what I wrote, even if Pedro does not like it. > I actually think Joao S. O. Buenos patch to the PNG plug-in is a nice > addition/work around the optimization problem - I have yet to try it > out, though. I haven't tried it either, but it could indeed be a nice addition to the PNG plug-in. But alas this is far from solving the real problem, which is a problem of model/perception. The real problem is that some GIMP developers and users see alpha as a simple hiding mechanism, which is wrong (or not always right, depending on your point of view). Perceptions are unfortunately very hard to change. As this will be my last message in this thread, I would like to end it with a question (but I suggest that you do not respond - just think about it): Why do we need layer masks in the GIMP? Wouldn't it be easier to paint directly into the alpha channel and simply get rid of this intermediate step (mask)? There are no conceptual differences between the alpha channel and masks (except for the one at the center of this discussion) so why do we need both if the same operations could be performed with both? Why were masks introduced in the first place? According to the books that I read (or just browsed) about Photoshop and other programs, a similar question can be easily answered for those programs: although both the alpha channel and the masks influence the opacity of the pixels, a mask is usually associated with visibility while alpha is usually associated with presence (and one cannot increase the presence of something that is not there). That's why the masks are there, to allow the user to increase or decrease the visibility of the pixels at will without any loss of information. But if any changes are commited to the alpha channel, then the opacity of the pixels cannot be increased anymore (except by painting over them or undoing their removal). The authors of these programs (especially Photoshop) were very careful about applying this model in a consistent way throughout the application. That's why masks are not treated in the same was as the alpha channel. That's why one is not encouraged to edit the alpha channel directly (there are ways around that if you know how to do it). If you think about it, I believe that it makes a lot of sense. Also, instead of promoting an "anti-erase" mode, someone invented an "undo brush" that can perform the same functions and even much more in most cases. They carefully avoided to break this model (masks for visibility/hid
Re: [Gimp-developer] Handling of transparent pixels
On Tuesday 16 December 2003 21:44, Patrick McFarland wrote: > > 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. Curves Tool, It is the alpha manipulation per excellence, IMO. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On 17-Dec-2003, [EMAIL PROTECTED] 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 || [EMAIL PROTECTED] "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 signature.asc Description: Digital signature
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Stephen J Baker wrote: I would rather hide that widget from Joe Public to avoid confusing him than to unnecessarily destroy valuable data. Let me say this one more time: If GIMP produces truly undefined data where Alpha is zero - then GIMP will become utterly useless for painting texture maps for 3D graphic applications. That's DEVASTATING to a large number of your users. Let me be clear, and hopefully just one more time. As far as I'm concerned, we're never going particularly out of our way to willfully smash/destroy/eat/zero data belonging to a value that has that become undefined -- but for any number of reasons (mostly optimizations of some sort) it happens, and will increasingly happen in the future of GIMP as a pixel's VALUE becomes further abstracted from its REPRESENTATION (example: is your favourite 10,0,80 HSV pixel being passed between GEGL stages as HSV, XYZ, L*a*b* or RGB? That will depend, and you will never know). The question is, should we expose non-power-user tools (one tool in particular, in my mind) that give the illusion that a pixel's raw byte representation is precious to the GIMP core? If your alpha channel is really a mask, use a mask. If your alpha channel is really an aux channel (i.e. specular index map), use an aux channel. If you are a power-user and willing to take your chances with alpha and particular power-user tools, know the risk and take your chances. If your favourite file-format plugin does not export and import alpha channels that are spec'd to contain non-destructive transparency data as layer masks, take it up with the author of your favourite file-format plugin. GIMP will always be (utterly) useful for painting texture maps for 3D graphics applications, but if you want and need a TRULY orthogonal (in the colourspace sense) channel in which to put your decal mask (or other attributes) then put it in one of the various supported GIMP data channels which are better suited to this purpose, if you wish your process to be futureproof. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Consume Less, Live More ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Tue, Dec 16, 2003 at 05:55:06PM -0200, "Joao S. O. Bueno" <[EMAIL PROTECTED]> wrote: > Actually, this will be quite possible with the "custom layer mode" I > was cooking a couple months ago, and which I plan do revive to Gimp Right, still I disagree in practise, and here is why: While "it can be done" with the custom layer mode is true, the problem is not the implementation, but the user-interface. The model I was referring to (that is not going to be implemented too soon, if at all) would work somewhat like "whenever the user does something, the operation is added to the pipe/tree for the image. if necessary the user can revisit any stage of the tree and change parameters or insert new steps." This poses a computing problem (it might be too slow/use too much memory for caching etc.) and also a UI problem (how can I make this accessible to the user in an easy way). Incidentally, this is (in a pipe not tree way) how the display app of ImageMagick works, but it's often overlooked. I can resize an image as often as I want (and display will do it in LQ mode quickly for me), but only when I hit the apply menu will it actually resize the underlying image data, keeping highest possible (for imagemagick) quality. > One will just have to write the effect (if he's writiing from scracth, The "just" is the problem. I can do it without custom layer modes, too, I just have to write the program. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet wrote: On Tue, 16 Dec 2003 10:31:29 -0200, "Joao S. O. Bueno" <[EMAIL PROTECTED]> wrote: You could maybe just add (or ask someone to add) a "zero-out transparent pixels" on the layers menu. [...] I do not care (yet) about clearing the transparent pixels, destroying color data, using pre-multiplied alpha or all the (un)related things that were mentioned in recent messages. I care about the message that we are giving to the user about the alpha channel: the correct way to present the alpha channel is that a pixel with alpha=0 has an undefined color. The GIMP should be free to keep the RGB data of transparent pixels intact or to destroy it if necessary. Above you said "I do not care about [...] destroying color data", now you say that the GIMP should be free to destroy RGB data. No offense, but that does make it easier to misunderstand you. After reading many posts about this topic, I'm still not sure I understand what you are saying. As far as I understand it, I disagree. [...] Basically, the model that we should promote is: - layer mask=> hiding mechanism, reversible - alpha channel => pixels that are cleared have undefined RGB data, not reversible (except for undo) Breaking this model should be avoided, except in very special cases (i.e. obscure features for hackers). I *really* don't see why. The way I see it is that in general things should be kept orthogonal as much as possible, unless there are good reasons to do otherwise. In RGBA we have four values named R, G, B and A, and it is perfectly possible to change any single one of them without affecting the others. That's orthogonality, and it is a nice feature to have. What is the advantage of RGB data suddenly being undefined? -- "Codito ergo sum" Roel Schroeven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Tue, Dec 16, 2003 at 07:51:13PM +, "Adam D. Moss" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
> >While I sometimes find the erase tool conceptually difficult to use
> >(maybe because it's so unusual), the question is wether this is just a
> >weird added feature (as most people including me _seem_ to view it), or
> >something that hinders people.
>
> Oh yeah, I don't know if you simply made a typo, but 'erase'
> isn't a problem, while 'unerase' is. Not a 'your app will
No, I was referring to the "erase tool" (actually "Eraser") since I was
too lazy to check how the unerase option is called ("Anti-Erase" here).
Sorry for making you guess.
I fully agree with what you say, othwerwise (I think :).
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Stephen J Baker wrote: [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: To just throw in another personal opinion: The behaviour you describe wrt. saturation would be hilarious. It's even implemented that way in current gimp _until_ you say "OK". After which you have to (comparatively) clumsily have to re-adjust it. If the underlying data representation was HLS rather than RGB, doing this would not be ludicrous - it would be expected. OTOH, if the underlying representation WAS HLS then doing something like taking all the green out of the picture - then putting it back without affecting the hue would seem ludicrous. (Sorry - that should have been "...putting it back without affecting the RED would seem ludicrous.") --- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. --- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: To just throw in another personal opinion: The behaviour you describe wrt. saturation would be hilarious. It's even implemented that way in current gimp _until_ you say "OK". After which you have to (comparatively) clumsily have to re-adjust it. If the underlying data representation was HLS rather than RGB, doing this would not be ludicrous - it would be expected. OTOH, if the underlying representation WAS HLS then doing something like taking all the green out of the picture - then putting it back without affecting the hue would seem ludicrous. While I sometimes find the erase tool conceptually difficult to use (maybe because it's so unusual), the question is wether this is just a weird added feature (as most people including me _seem_ to view it), or something that hinders people. It's certainly unexpected - but it's useful. I would rather hide that widget from Joe Public to avoid confusing him than to unnecessarily destroy valuable data. Let me say this one more time: If GIMP produces truly undefined data where Alpha is zero - then GIMP will become utterly useless for painting texture maps for 3D graphic applications. That's DEVASTATING to a large number of your users. --- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. --- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Actually, this will be quite possible with the "custom layer mode" I was cooking a couple months ago, and which I plan do revive to Gimp 2.2 .. As an effect that applyes to the layer itself,like the "dissolve" layer mode, instead of on combinations, it is doable there. One will just have to write the effect (if he's writiing from scracth, here will be a handfull of pre-made custom layer modes) ST=0; VT=V1; LT=L1 , to mean that targets HSV are set to zero, self, and self, respectively. The RGBA values per pixel are kept unchanged by the Custom Layer Mode. On Tuesday 16 December 2003 17:40, Adam D. Moss wrote: > [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: > > However, the "layer effects" people want is (in my eyes) exactly > > that: apply some saturation effect to a layer that you can later > > change without loss of fidelity. > > And that'd be pretty groovy, and it'd work BECAUSE the > layer effect is conceptually (and in reality) a separate > processing step rather than an attribute of the data it > applies to. This is precisely how I see the layer mask > versus the alpha channel. > > --Adam - ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet wrote: I care about the message that we are giving to the user about the alpha channel: the correct way to present the alpha channel is that a pixel with alpha=0 has an undefined color. The GIMP should be free to keep the RGB data of transparent pixels intact or to destroy it if necessary. Hackers may be aware of whether the GIMP will keep the RGB data or not for such and such operation, but we should avoid adding features that explicitely require one or the other to happen. Firstly, I'd strongly debate the idea that only 'Hackers' need that RGB data that's hidden by the alpha plane. Anyone who paints textures to apply to 3D models is going to need those RGB values to be in good shape when the file is written out. With the increasing prevelence of games that are user-customisable, I think an increasing proportion of GIMP users will care greatly about this feature. Either way, having to keep a mental image of what operations will screw up my texture to the point of unusability and which ones will preserve it is not something that I could live with. I've been a user (and sometimes - author) of paint programs since the Quantel Paintbox back in the early 1980's - so I'm guessing I fit your idea of a power user. IMHO, Alpha should be treated just exactly like R, G and B (or C, M, Y and K) are treated. I should be able to paint into the alpha plane (which is in effect what the GIMP eraser tool does). I think the way that the alpha plane is treated as special is a large part of the problem here. Basically, the model that we should promote is: - layer mask=> hiding mechanism, reversible - alpha channel => pixels that are cleared have undefined RGB data, not reversible (except for undo) Breaking this model should be avoided, except in very special cases (i.e. obscure features for hackers). I don't think painting texture maps should be considered an obscure or special case undertaken only by deep guru's. If you think of this as an operation that many of your users will be doing, your argument falls to the ground. --- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. --- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: While I sometimes find the erase tool conceptually difficult to use (maybe because it's so unusual), the question is wether this is just a weird added feature (as most people including me _seem_ to view it), or something that hinders people. Oh yeah, I don't know if you simply made a typo, but 'erase' isn't a problem, while 'unerase' is. Not a 'your app will crash' sort of problem by any means, more a matter of exposing the user to implementation details and fluffy conceptual wrongness, actively encouraging the wrong tool (alpha) for the job (masking), and implying that 'undefined' data is sacred whereas it hasn't strictly been for a very long time now (and in some tools and usage patterns NEVER has been, but users don't even question these because the UI never encouraged these usage patterns). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Consume Less, Live More ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Hi, On Tue, 2003-12-16 at 17:59, Raphaël Quinet wrote: > Basically, the model that we should promote is: > - layer mask=> hiding mechanism, reversible > - alpha channel => pixels that are cleared have undefined RGB data, >not reversible (except for undo) > > Breaking this model should be avoided, except in very special cases > (i.e. obscure features for hackers). I'm sorry, Raphaël, but I do not agree with you on this issue either. I don't see why we should limit the gimp when there is no, at least to me, obvious reason to do so. I think you will have to accept the fact that this proposed change will not make it into gimp, at least not at this point in development. Allow me to refer to the minutes of the gimpcon meetings - http://developer.gimp.org/gimpcon/2003/minutes-1.html#decisions - where we agreed not to continue discussions just for the sake of the discussion. I think we have all had a chance to comment on the proposed changes at this point, and I suggest that we leave it be. I actually think Joao S. O. Buenos patch to the PNG plug-in is a nice addition/work around the optimization problem - I have yet to try it out, though. Sincerely, ./Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: However, the "layer effects" people want is (in my eyes) exactly that: apply some saturation effect to a layer that you can later change without loss of fidelity. And that'd be pretty groovy, and it'd work BECAUSE the layer effect is conceptually (and in reality) a separate processing step rather than an attribute of the data it applies to. This is precisely how I see the layer mask versus the alpha channel. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Consume Less, Live More ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Mon, Dec 15, 2003 at 10:45:56PM +, "Adam D. Moss" <[EMAIL PROTECTED]> wrote: > it's quite equivalent to letting the user take the saturation > knob down to zero and then coming back later, turning up > the saturation again and wondering where the original colours To just throw in another personal opinion: The behaviour you describe wrt. saturation would be hilarious. It's even implemented that way in current gimp _until_ you say "OK". After which you have to (comparatively) clumsily have to re-adjust it. Being able to change the saturation later by moving it up again would be rather desirable, even if it will not likely to be done that way for the next decade or so. However, the "layer effects" people want is (in my eyes) exactly that: apply some saturation effect to a layer that you can later change without loss of fidelity. > mask. The solution to just about all the 'I want my RGB data > preserved orthogonally to the alpha in my file!' objections is to Orthoginality is a different argument (and can be rather valid, too). Tools in the current gimp don't work like alpha behaves. If you press OK, the old image is gone. While I sometimes find the erase tool conceptually difficult to use (maybe because it's so unusual), the question is wether this is just a weird added feature (as most people including me _seem_ to view it), or something that hinders people. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
I'll throw my opinion into the mix FWIW. I disagree with Raphael that RGB values for alpha=0 should be undefined. If alpha is subsequently adjusted, then the original RGB values must be preserved whenever possible so that the reduced transparency can be effected and produce the correct result. Therefore, in concept I don't completely agree with Rafael's comment that RBG values are undefined when alpha=0. Rather, the RGB values should be treated whenever possible to yield the proper result as if taking the limit as alpha approaches 0, rather than strictly stating that RGB values are undefined when alpha=0. This would provide the most useful and expected results, and greatest functionality for the user. I am coming in late on this thread, and may have missed something, so please forgive me if my opinions are off the mark for some reason. s/KAM - Original Message - From: "Raphaël Quinet" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 16, 2003 10:59 AM Subject: Re: [Gimp-developer] Handling of transparent pixels On Tue, 16 Dec 2003 10:31:29 -0200, "Joao S. O. Bueno" <[EMAIL PROTECTED]> wrote: > You could maybe just add (or ask someone to add) a "zero-out > transparent pixels" on the layers menu. [...] Sigh! It is a bit frustrating for me to see that you haven't understood what the main problem is (from my point of view). Maybe this thread has been going on for too long... Anyway, one more try: I do not care (yet) about clearing the transparent pixels, destroying color data, using pre-multiplied alpha or all the (un)related things that were mentioned in recent messages. I care about the message that we are giving to the user about the alpha channel: the correct way to present the alpha channel is that a pixel with alpha=0 has an undefined color. The GIMP should be free to keep the RGB data of transparent pixels intact or to destroy it if necessary. Hackers may be aware of whether the GIMP will keep the RGB data or not for such and such operation, but we should avoid adding features that explicitely require one or the other to happen. I think that Adam has posted a nice explanation, so I will not repeat it. Daniel Rogers had also some positive comments in Bugzilla. Basically, the model that we should promote is: - layer mask=> hiding mechanism, reversible - alpha channel => pixels that are cleared have undefined RGB data, not reversible (except for undo) Breaking this model should be avoided, except in very special cases (i.e. obscure features for hackers). -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Tue, 16 Dec 2003 10:31:29 -0200, "Joao S. O. Bueno" <[EMAIL PROTECTED]> wrote: > You could maybe just add (or ask someone to add) a "zero-out > transparent pixels" on the layers menu. [...] Sigh! It is a bit frustrating for me to see that you haven't understood what the main problem is (from my point of view). Maybe this thread has been going on for too long... Anyway, one more try: I do not care (yet) about clearing the transparent pixels, destroying color data, using pre-multiplied alpha or all the (un)related things that were mentioned in recent messages. I care about the message that we are giving to the user about the alpha channel: the correct way to present the alpha channel is that a pixel with alpha=0 has an undefined color. The GIMP should be free to keep the RGB data of transparent pixels intact or to destroy it if necessary. Hackers may be aware of whether the GIMP will keep the RGB data or not for such and such operation, but we should avoid adding features that explicitely require one or the other to happen. I think that Adam has posted a nice explanation, so I will not repeat it. Daniel Rogers had also some positive comments in Bugzilla. Basically, the model that we should promote is: - layer mask=> hiding mechanism, reversible - alpha channel => pixels that are cleared have undefined RGB data, not reversible (except for undo) Breaking this model should be avoided, except in very special cases (i.e. obscure features for hackers). -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
PNG zeroing transparent pixels. Was.. Re: [Gimp-developer] Handling of transparent pixels
Ok, I managed to change my png plugin to handle cleaning out all transparent pixels. What do you say? Is it interesting to go in right now? If it is a PNG recomendation, then it might be a nice add on, and it is small enough to go in even now, before the first pre-2.0. a 640x480 pix image with a transparent hole of about half it's size got a 15% file size decrease. I will polish my changes a little and submit the patch do bugzilla. If anyone wanna try it, just tell me now. JS -><- On Tuesday 16 December 2003 10:31, Joao S. O. Bueno wrote: > Raphael, can I ask you a thing? > > > You could maybe just add (or ask someone to add) a "zero-out > transparent pixels" on the layers menu. > > This will make you possibly happy, and will NOT arbitrarily throw > away data that is relevant to more than one group of users as this > thread had shown. > > Maybe, if you want to be really picky and selfish about this - > there are far more usability issues in GIMP as it is now - them > instead of a menu option one have to actively click, there could be > added an entry in preferences. Something like "Automatically > destroy color data from transparent pixels". Or some name equally > "warnfull" about what it does. > > With that, GIMP could be kept for Image Manipulation thats why we > use it for. > > However, I would agree that such an __option__ - to zero out data > pixels - should be added to the .png save filter. > > > JS > -><- > > > > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > You could maybe just add (or ask someone to add) a "zero-out > transparent pixels" on the layers menu. There's a perl script in gimp-perl which does just that: Image->Alpha->Clear Alpha Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphael, can I ask you a thing? You could maybe just add (or ask someone to add) a "zero-out transparent pixels" on the layers menu. This will make you possibly happy, and will NOT arbitrarily throw away data that is relevant to more than one group of users as this thread had shown. Maybe, if you want to be really picky and selfish about this - there are far more usability issues in GIMP as it is now - them instead of a menu option one have to actively click, there could be added an entry in preferences. Something like "Automatically destroy color data from transparent pixels". Or some name equally "warnfull" about what it does. With that, GIMP could be kept for Image Manipulation thats why we use it for. However, I would agree that such an __option__ - to zero out data pixels - should be added to the .png save filter. JS -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Mon, 15 Dec 2003 20:30:06 +0100, David Neary <[EMAIL PROTECTED]> wrote: > Raphaël Quinet wrote: > > The whole point of this discussion was based on the fact that because > > we use post-multiplied alpha, there is some ambiguity about whether > > the average user is supposed to know and rely on the RGB values of > > transparent pixels. If we had been using pre-multiplied alpha, then > > there would be no reason for any debate, because all transparent > > pixels would have R, G and B = 0. > > You believe that allowing the RGB data behind transparent pixels to > be exposed might be confusing to some users - so far in the > thread you are the only one who has asserted this. This is close to what I wrote, but not quite. My main concern is not that some users might be confused, but that the new feature that was recently introduced implies that the users should percieve the alpha channel as a simple hiding mechanism, which is wrong. I will not repeat all arguments, but basically "alpha = hiding" may be true (currently) for the images that were edited in one session, but may not be true for images loaded from disk or processed by some plug-ins. On the other hand, the concept "alpha = undefined" is safer and works in all cases. In addition, it allows us to optimize some parts of the GIMP (or GEGL) later. > You consider that in certain circumstances this behaviour could > be considered a bug. Yes, because presenting undefined data to the user should be avoided. In this case "undefined" is taken from the user's point of view: the value of the data depends mostly on arbitrary implementation decisions and the average user should not have to be aware of these internal details. GIMP developers and advanced users may take advantage of their knowledge of the GIMP internals, but this should not be expected from most users. > Others have stated that there are several applications where > transparent data is stored across sessions, and that this data is > indeed useful, and not at all undefined. This is true in some cases, but not all. I am mostly concerned about the cases for which this is not true. By promoting a perception of the alpha channel that is not always correct, we are encouraging the user to expect some things that cannot be guaranteed. This can indirectly lead to data loss if the user's expectations cannot be fulfilled now or in the future. I would prefer to follow the principle "better be safe than sorry" and leave the advanced features to hackers and advanced users who have a better knowledge of the current GIMP internals. > Perhaps > we could have a filter that pre-multiplies layers by their alpha > channel? That would be trivial to write, and would address > Raphalël's concerns, while staying true to the principle I > outlined. I don't see how using pre-multiplied alpha would help. This would be a regression and it would not solve any problems, AFAIC. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
David Neary wrote: For the moment, unless I am mistaken, you are the only person to have stated that they consider the current behaviour wrt transparency flawed. I'd just like to say that I somewhat agree with Raphaël. Using alpha for 'hiding' and unhiding is conceptually wrong, it's quite equivalent to letting the user take the saturation knob down to zero and then coming back later, turning up the saturation again and wondering where the original colours have gone. I've said it before: an RGBA pixel isn't just an RGB pixel with a handy auxilliary channel. Alpha is the glass you draw upon; it accumulates coverage of a certain colour, but the colour of the glass itself is undefined. BUT, it's not the user's fault that GIMP hasn't really historically given this much thought, and has exposed tools and plugins which more or less pretend that the alpha channel is just another layer mask. The solution to just about all the 'I want my RGB data preserved orthogonally to the alpha in my file!' objections is to load and save the alpha as a layer mask, because that's precisely what people are wanting the alpha channel to be. That layer masks aren't quite as convenient to modify as alpha channels (that is to say, there isn't a tool that implicitly draws onto a layer mask a la eraser) is one of the reasons that people are going to keep abusing alpha. Right now probably isn't a good time to go crazy and change anything to accommodate (I'd still kinda like the deceptive anti-erase to go away, but don't mind stuff such as 'levels' working on the alpha channel on the understanding that it's a relatively power-user thing to do and that power-users understand that the resurrected RGB values of a 0-alpha pixel may not be as expected). (For the record, there have existed in the GIMP core for years some optimizations that skip RGB processing for certain sections of completely-transparent image regions, which can cause -- albeit under conditions in which the user is least likely to care -- regions of transparency in a composited image to 'go undefined'. No-one seems to have noticed or at least cared yet.) Regards, --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Consume Less, Live More ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Hi Raphaël, I think everyone has more or less had their say on the thread - can I just sum up the salient points? Raphaël Quinet wrote: > I agree. This is what the GIMP does and I was definitely not > suggesting to change this, so I think that you misunderstood what I > wrote. The GIMP will keep on using post-multiplied alpha in the > future, and this is a good thing. > > The whole point of this discussion was based on the fact that because > we use post-multiplied alpha, there is some ambiguity about whether > the average user is supposed to know and rely on the RGB values of > transparent pixels. If we had been using pre-multiplied alpha, then > there would be no reason for any debate, because all transparent > pixels would have R, G and B = 0. You believe that allowing the RGB data behind transparent pixels to be exposed might be confusing to some users - so far in the thread you are the only one who has asserted this. You consider that in certain circumstances this behaviour could be considered a bug. Others have stated that there are several applications where transparent data is stored across sessions, and that this data is indeed useful, and not at all undefined. Personally I have stated that we should never destroy or modify data without explicit user action to that effect. For the moment, unless I am mistaken, you are the only person to have stated that they consider the current behaviour wrt transparency flawed. Can I propose, then, that we keep the current behaviour? Perhaps we could have a filter that pre-multiplies layers by their alpha channel? That would be trivial to write, and would address Raphalël's concerns, while staying true to the principle I outlined. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Mon, 15 Dec 2003 07:43:39 -0600, "Stephen J Baker" <[EMAIL PROTECTED]> wrote: > Raphaël Quinet wrote: > > I don't see how this would happen, except if the downsampling filter > > would be incorrectly processing the R, G, B and A values independently > > (without weighting by A), which is obviously incorrect. > > Well, it's not "obviously incorrect" unless you assume that RGB's are > pre-multiplied by alpha. It looks like you misunderstood what I wrote. I don't know if this is the case here, but a frequent mistake is to confuse how the RGBA values are stored (with or without pre-multiplication of R, G and B by A) and how these values are used in compositing, subsambpling, etc. The best way to store the data is to store it with full precision, so it should be post-multiplied, not pre-multiplied. But when the pixels are used in compositing operations, then they should be multiplied by their alpha values (if possible, using a higher precision for the intermediate steps), otherwise the color of partially or fully transparent pixels would bleed into the neighboring pixels. This is what I described as the "obviously incorrect" way to process these pixels. This is also what has been fixed in a number of GIMP plug-ins by David Necas and others in: http://bugzilla.gnome.org/show_bug.cgi?id=70335 Note that this is exactly what the GIMP does: store the source pixels and the results with post-multiplied alpha, but use the correct weighting for the operations that combine several pixels. > There is actually a GOOD reason to use post-multiplied alpha - and that > is that pre-multiplying RGB by alpha destroys information that might come > in useful later on. If you can choose to postpone the destruction of > data - then that's generally a good thing to do. I agree. This is what the GIMP does and I was definitely not suggesting to change this, so I think that you misunderstood what I wrote. The GIMP will keep on using post-multiplied alpha in the future, and this is a good thing. The whole point of this discussion was based on the fact that because we use post-multiplied alpha, there is some ambiguity about whether the average user is supposed to know and rely on the RGB values of transparent pixels. If we had been using pre-multiplied alpha, then there would be no reason for any debate, because all transparent pixels would have R, G and B = 0. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Mon, Dec 15, 2003 at 07:43:39AM -0600, Stephen J Baker wrote: > But that assumes that alpha is pre-multiplied into the RGB's - which is > not the case for either DirectX or OpenGL's hardware texturing. Both OpenGL and DirectX can handle premultiplied alpha just fine. Just use additive blending and off you go. :-) The problem is of course that you lose a lot of precision when everything has to be stored in 8-bit-per-channel bitmaps after the multiplication. > The standard OpenGL MIPmap generator does not do as you suggest it should. There is no "standard OpenGL mip-map generator". gluBuild2DMipMaps is a part of the GL Utility kit (GLU), not OpenGL, and it usually does its work in software anyhow (quite slowly, and with mediocre quality). You have an OpenGL extension (GL_SGIS_mipmap_generate IIRC) that does automatic filtering, but the exact filtering method is somewhat undefined. /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet wrote:
On Fri, 12 Dec 2003 14:41:08 -0600, "Stephen J Baker" <[EMAIL PROTECTED]> wrote:
MIPmapping works by creating successively reduced resolution images -
each (typically) half the resolution of the previous one.
When a MIPmapped image has alpha, this down-filtering produces semi-translucent
pixels in areas of the image that were formerly completely transparent.
I don't follow your argument. Even the simplest downsampling
techniques ("nearest neighbors", no linear or cubic interpolation)
work by combining the weighted values of the pixels (all colors are
weighted by their opacity). So the relative weight of a fully
transparent pixel is zero, which means that if you are filtering four
pixels (half resolution) and three of them are transparent, then the
result will only have the contribution of the fourth pixel, with a
lower opacity (1/4). The fully transparent pixels will not contribute
to the downsampled result.
But that assumes that alpha is pre-multiplied into the RGB's - which is
not the case for either DirectX or OpenGL's hardware texturing.
If my down-filtering (for MIPmaps) worked as you suggest then pixels
with (say) 50% alpha wouldn't carry as much weight as they should.
So, no - we cannot do as you suggest.
The standard OpenGL MIPmap generator does not do as you suggest it should.
If GIMP were to do something like (say) making all the transparent pixels
be solidly black, you'd see a dark halo. This is a really common problem
and GIMP is the tool that saves you.
I don't see how this would happen, except if the downsampling filter
would be incorrectly processing the R, G, B and A values independently
(without weighting by A), which is obviously incorrect.
Well, it's not "obviously incorrect" unless you assume that RGB's are
pre-multiplied by alpha.
Whilst I might be pursuaded that pre-multiplied Alpha was a good idea,
I (and everyone else who works with realtime hardware) do not have a
choice in the matter since that's how the API's are specified - and
how the underlying hardware is implemented.
There is actually a GOOD reason to use post-multiplied alpha - and that
is that pre-multiplying RGB by alpha destroys information that might come
in useful later on. If you can choose to postpone the destruction of
data - then that's generally a good thing to do.
If some other software has the same bugs as some of these plug-ins, I
don't think that it is the GIMP's job to make sure that the software
works despite its bugs.
But it's not a bug to choose to post-multiply alpha - it's a design choice.
I would argue that if GIMP were to uniformly support post-multiplied alpha,
then any application that required pre-multiplied alpha could trivially
fix it. However, for applications (including **ALL** realtime/interactive
3D applications) that absolutely must have post-multiplied alpha, giving
us the data in the pre-multiplied form makes GIMP virtually unusable.
Please don't do this!
Of course we should not break it on purpose
if we have no good reason to do it (i.e., if there is no other benefit
in clearing the transparent pixels) but we should not be prevented
from improving the GIMP even if that triggers some pre-existing bugs
in some other software. We can implement specific workarounds if
someone thinks that it is worth it, though.
I strongly implore you to retain post-multiplied alpha.
---
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
---
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.link.com
Home: [EMAIL PROTECTED] http://www.sjbaker.org
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Hi Raphael, Raphaël Quinet wrote: > Well, I am still not sure about what was the real source of the > problem mentioned in that bug report. Quite simply, Photoshop (according to the bug submitter) does not pre-multiply RGB data by the alpha channel when saving, which allows the complete data to be retrieved afterwards. This is perhaps an option, but that was the origin of the problem. The submitter expected the GIMP to do the same thing. > According to the > second comment from the reporter, it looks like Photoshop is able to > decode both types of images correctly (with and without pre- > multiplication) So do we - but at load time, we pre-multiplied the RGB values (as prescribed in the standard), so the behind-the-alpha data was destroyed. Actually, without going into details, I think it could be considered correct to do this on save, but to read the data in the file as-is (that is, without pre-multiplication). That is, we assume that this operation was done by the application that created the image, and we read whatever's in the file. Part of the patch I attached to that bug would do this, if it were desirable. > so I suspect that the real problem comes from some > exotic option that we (or libtiff) do not use and that would allow us > to save the image with full RGBA information. Nope - according to the latest tiff standard I could find, we're unequivocally doing the right thing on save. > It > may be an undocumented extension - TIFF is known to be full of these. Ah - if you say so :) > Well, I'd rather be non-violent... ;) Of course, we should not > destroy data if we have no good reason to do it. On the other hand, > we should not lock ourselves in a situation that would prevent us from > destroying this data if that could bring other advantages. The fundamental rule that I thinkl we should follow is that modifying any 3rd party or user data should require an explicit action from the user (switching a toggle to optimize the image, for example, or toggling a preference to do alpha pre-multiplying, or somesuch). If the user does not request it, we should not touch his data just because we think that might be what he would expect. > Exposing internal data to the average user means that we would not be > allowed to some of this internal stuff later. Nonesense. Applications change their behaviour all the time - free software projects more than most. If we decide to provide features like layer auto-growing in the future, then we can do so. Saying that one 20 line patch will prevent us from doing something is just wrong. Also, I do not consider the data we're talking about to be internal, or undefined. It is simply data which is not visible in the projection. The undo brush sounds like it would be a nightmare to implement and get to act reasonably... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Hi Stephen, Stephen J Baker wrote: > What GIMP does now is just fine - what might be nicer would be some kind > of toggle to temporarily show the entire image as opaque (without actually > destroying the value of the alpha buffer). Raphaël will probably kill me for advertising a feature he considers a bug, but anyway... you can now do this by converting the alpha channel to a layer mask, and hiding the layer mask in the usual manner. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Fri, 12 Dec 2003 14:41:08 -0600, "Stephen J Baker" <[EMAIL PROTECTED]> wrote:
> MIPmapping works by creating successively reduced resolution images -
> each (typically) half the resolution of the previous one.
>
> When a MIPmapped image has alpha, this down-filtering produces semi-translucent
> pixels in areas of the image that were formerly completely transparent.
I don't follow your argument. Even the simplest downsampling
techniques ("nearest neighbors", no linear or cubic interpolation)
work by combining the weighted values of the pixels (all colors are
weighted by their opacity). So the relative weight of a fully
transparent pixel is zero, which means that if you are filtering four
pixels (half resolution) and three of them are transparent, then the
result will only have the contribution of the fourth pixel, with a
lower opacity (1/4). The fully transparent pixels will not contribute
to the downsampled result.
> If GIMP were to do something like (say) making all the transparent pixels
> be solidly black, you'd see a dark halo. This is a really common problem
> and GIMP is the tool that saves you.
I don't see how this would happen, except if the downsampling filter
would be incorrectly processing the R, G, B and A values independently
(without weighting by A), which is obviously incorrect. We had a
bunch of bug reports about GIMP plug-ins doing this incorrectly and
many of them have already been fixed thanks to the contributions of
David Necas (yeti) and others. Follow the dependencies from:
http://bugzilla.gnome.org/show_bug.cgi?id=70335
If some other software has the same bugs as some of these plug-ins, I
don't think that it is the GIMP's job to make sure that the software
works despite its bugs. Of course we should not break it on purpose
if we have no good reason to do it (i.e., if there is no other benefit
in clearing the transparent pixels) but we should not be prevented
from improving the GIMP even if that triggers some pre-existing bugs
in some other software. We can implement specific workarounds if
someone thinks that it is worth it, though.
-Raphaël
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Wed, 10 Dec 2003 16:13:48 +0100, Dave Neary <[EMAIL PROTECTED]> wrote: > In any case, masks and alpha channels are also used to hide data across > sessions for several file formats (eg. png), and we have ven had a bug > report against the GIMP > (http://bugzilla.gnome.org/show_bug.cgi?id=82882) because someone > expected this behaviour from the tiff plug-in (apparrently this is > provided by other programs). Well, I am still not sure about what was the real source of the problem mentioned in that bug report. It looks like the GIMP uses pre-multiplied alpha when saving this type of TIFF files (and it seems to be correct, according to the standard that you quoted) while some other software does not pre-multiply by alpha. According to the second comment from the reporter, it looks like Photoshop is able to decode both types of images correctly (with and without pre- multiplication) so I suspect that the real problem comes from some exotic option that we (or libtiff) do not use and that would allow us to save the image with full RGBA information. There is probably a flag that we do not parse and do not set that would allow this. It may be an undocumented extension - TIFF is known to be full of these. > > 2) For the pixels that have been obtained from an external source, > >then the "hiding" concept does not fit because the RGB data is > >undefined. > > This is where we start to voilently diverge :) I disagree that this is > the case. It may be considered to be the case in some specific > circumstances, but in general, we should not destroy data, IMHO. Well, I'd rather be non-violent... ;) Of course, we should not destroy data if we have no good reason to do it. On the other hand, we should not lock ourselves in a situation that would prevent us from destroying this data if that could bring other advantages. Exposing internal data to the average user means that we would not be allowed to some of this internal stuff later. Note that it may be different if we talk about advanced users: they can fiddle with internal data because they know a bit of what is under the hood and they also know that the implementation might change in the future. > As a matter of interest, how would an undo brush work? I'm having > trouble getting my head around the idea. We don't have to implement this in the same way as Photoshop or other programs do, but the basic idea would be something like this: - You select the undo brush with a suitable brush size, shape and other parameters. - You select one of the steps in the undo history. - You start painting with your brush in the image. The area covered by your brush is replaced by the corresponding area in the older version of the image. So if you erased something by mistake of if you were too generous while painting along some edge, you can easily restore it. You can restore some small details or do a partial merge by selecting the appropriate size and opacity of the brush. Note that I am not sure about the implementation details because I have never used it. I only read some descriptions of how it works and how it can be very useful for making small corrections to an image. There are many details that would have to be solved before implementing this. For example, we should make sure that the undo step from which we copy pixels is not discarded from the undo history even if we paint with the undo brush in several strokes. Also, how do we select the correct source pixels in the undo history if the image was scaled, rotated or translated? What about the undo steps consisting in the removal of a layer? We should probably not allow all undo steps to be selected as the source of the pixels for the undo brush. So there are still a number of open questions, but the undo brush looks like a very useful feature. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Tue, 9 Dec 2003 21:56:58 +0100, Simon Budig <[EMAIL PROTECTED]> wrote: > [...] We always had the general approach to empower the GIMP > user to do non-obvious stuff. Right now we don't discard RGB-information > when A=0 in the core, and stuff like Anti-Erase usually just works good > for power users. Yes, but as you wrote yourself, this is for power users. The Anti-Erase mode is currently presented as an option in the Erase tool. This would be rather different if it had been placed as a separate tool in the toolbox. > The new Alpha-to-mask feature you are complaining about > in #127930 works and empowers users to handle Tribes2 textures. > The point that you perceive this as an abuse of the PNG format is > irrelevant: PNG does not discard the RGB information by itself, and > there is no point in preventing our users to use it. I think that in this case, the way this new feature for power users is implemented and presented can be detrimental to the perception that all other users have of the alpha channel. Basically, this new feature only works with the model "alpha = hiding", and this is wrong in some cases. It would be better for us to promote a different model: "alpha=0 => gone (but you can use undo)" because this would work better for most users. If we have options for advanced users and hackers, then they should not be presented among a set of other options without side-effects (such as the other options in the mask creation dialog). [...] > > This is is why I was suggesting to remove the bug introduced by > > #127930 before it makes it into a stable release, > > Let me emphasize this: > > THIS IS NOT A BUG! > > A bug is not defined as "might lead to unexpected results when used in a > very specific manner". If the results are unexpected then yes, it is a bug. This can be solved by producing different (more correct) results, or by producing the same results but making sure that they are expected, not unexpected. The second case could be related to UI bugs. The problems in the user interface and user interaction model should not be ignored. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
The value of the RGB of transparent pixels is crucial for applications involving realtime MIPmapped textures...pretty much all 3D games for example. MIPmapping works by creating successively reduced resolution images - each (typically) half the resolution of the previous one. When a MIPmapped image has alpha, this down-filtering produces semi-translucent pixels in areas of the image that were formerly completely transparent. At these locations, the colour you see will be a down-filtered version of the higher resolution image. It it therefore ESSENTIAL that the pixels in the areas outside of the opaque parts of the image can also be painted - and have user controllable RGB values. What GIMP does now is just fine - what might be nicer would be some kind of toggle to temporarily show the entire image as opaque (without actually destroying the value of the alpha buffer). If GIMP were to do something like (say) making all the transparent pixels be solidly black, you'd see a dark halo. This is a really common problem and GIMP is the tool that saves you. --- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. --- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
(Sorry for yet another long mail. I will try to be more concise in my other replies, by not repeating the points already stated here.) On 09 Dec 2003 20:32:25 +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Raphaël Quinet <[EMAIL PROTECTED]> writes: > > 2) For the pixels that have been obtained from an external source, > >then the "hiding" concept does not fit because the RGB data is > >undefined. > > There is no such thing as undefined RGB data. GIMP doesn't use > premultiplied data, so the data is always there and I don't think you > can argue that it would be undefined. Well, of course there is always some data there. The value of every pixel is always set by the GIMP or by the plug-in that loads the file or obtains the data from an external source. My point was that the RGB data is undefined *from the user's point of view*. Or to put it in another way, the value of the RGB data for some of the transparent pixels (mainly those that were made transparent outside the GIMP) is arbitrary and could change if: - some internal implementation details of the GIMP (or GEGL) change, - some internal implementation details of the plug-in change, - the file is saved and re-loaded (the load and save plug-ins could be different), - the file is processed by some other software, - the RAM or CPU is exposed to cosmic rays or alpha radiation. ;-) > >- Some other formats (e.g., RGBA PNG) store full RGBA data, so the > > transparent pixels may contain some RGB values. However, these > > values may be discarded by other image processing software or by > > tools such as pngcrunch. A GIMP plug-in could also discard the > > color of transparent pixels while loading or saving an image in > > order to improve the compression. > > The RGB data can hardly be discarded, it can only be replaced with > other data. I agree. I know that the pixels will not suddenly disappear, but what happens to the RGB data is an arbitrary decision. Most of the standards for image formats do not require the RGB data of fully transparent pixels to be preserved when saving the image, and what we and other software authors do with it is an implementation detail. In most cases (not all cases, I agree), the user will not and should not know what happens to these pixels. If we consider the example of RGBA PNG files mentioned above, the PNG specification says: "The alpha channel can be regarded either as a mask that temporarily hides transparent parts of the image, or as a means for constructing a non-rectangular image." If the image matches the first case, then we should preserve the RGB data. If the image matches the second case better, then the PNG specification recommends: "fully transparent pixels should all be assigned the same color value for best compression." Of course, the best match (first or second case) depends on the history of the image (how it was acquired and edited) and the intent of the user. So the best solution for PNG could be to add an option in the save plug-in allowing the user to select if the RGB data of transparent pixels should be cleared or not. But this is just a guideline (not a requirement) for the PNG file format and we can choose to follow it or not. The plug-ins for other file formats or the other programs manipulating PNG images could arbitrarily clear or preserve the RGB data of transparent pixels. > >- In some other formats (e.g., WAD textures), the transparent > > pixels are simply not stored: they are defined as a number of > > pixels to skip in the current row or column, so there is not even > > a concept of "default color" for these pixels. In this case, the > > RGB values depend only on internal implementation details of the > > plug-in used to load the file. > > We should probably set up a policy on how plug-ins should implement > this then. The policy could say that transparent pixels should be left > untouched (leaving it up to libgimp to initialize them) or > alternatively be initialized to 0. Yes, this is a good idea. However, this is just something that we would choose to do now and we could select a different policy in the future if that could bring other advantages. Setting the color to black is probably a good choice, but I don't think that the user has to be aware of this. > > So the concept "alpha = hiding" does not work for case (2). In > > addition, even case (1) has some problems because sticking to that > > model would prevent the GIMP or GEGL from optimizing the memory usage > > by clearing and freeing tiles that are fully transparent (this would > > be useful if we want to implement layers that grow and shrink on > > demand, as requested in bug #93639 and bug #98776). > > This is indeed an interesting point. Basically the only advantage that > I could find in your concept so far but indeed a compelling one. Thanks. Note that even if this could be important in the future, I did not want to insist too
Re: [Gimp-developer] Handling of transparent pixels
Hi, Raphaël Quinet wrote: One thing that has not been mentioned in this discussion so far is that there are two kinds of transparent pixels: those that have been made transparent during the current GIMP editing session, and those that were already transparent when the file was loaded from disk or obtained from a plug-in. Like nomis and Sven, I don't see there being any inherent difference here. 1) For the pixels that have been made transparent during the current editing session, one point of view could be to consider the alpha channel as a "hiding mechanism" that does not modify the RGB data. However, if the goal is to be able to un-erase some pixels that were accidentally made transparent, then an "undo brush" would be a more appropriate solution to that problem. So the concept of "hiding without destroying" is not really necessary if the same data can be retrieved from the undo history with the same convenience. I don't follow your logic here. It is undoubtedly useful to consider an alpha channel as a way to hide data, therefore it is not necessary to modify data in the RGB channel when we modify the A channel. In any case, masks and alpha channels are also used to hide data across sessions for several file formats (eg. png), and we have ven had a bug report against the GIMP (http://bugzilla.gnome.org/show_bug.cgi?id=82882) because someone expected this behaviour from the tiff plug-in (apparrently this is provided by other programs). 2) For the pixels that have been obtained from an external source, then the "hiding" concept does not fit because the RGB data is undefined. This is where we start to voilently diverge :) I disagree that this is the case. It may be considered to be the case in some specific circumstances, but in general, we should not destroy data, IMHO. Not destroying it means, inevitably, allowing it to be manipulated. Your suggestion amounts to pre-multiplying RGB by alpha regardless of the file format, and I consider that just wrong. Beyond the next release, this is also why we should consider removing the "anti-erase" mode of the eraser tool in a future release and replace it by an undo brush. As a matter of interest, how would an undo brush work? I'm having trouble getting my head around the idea. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet ([EMAIL PROTECTED]) wrote: > Here is a long overdue and long-winded update to the discussion about > editing the alpha channel and how transparent pixels should be > handled... Let me respond to this. I don't think, that your proposal is as urgent as you make it and I seriously believe that it has a fatal flaw. > One thing that has not been mentioned in this discussion so far is > that there are two kinds of transparent pixels: those that have been > made transparent during the current GIMP editing session, and those > that were already transparent when the file was loaded from disk or > obtained from a plug-in. I fail to see why this is such a fundamental difference. > 1) For the pixels that have been made transparent during the current >editing session, one point of view could be to consider the alpha >channel as a "hiding mechanism" that does not modify the RGB data. >However, if the goal is to be able to un-erase some pixels that >were accidentally made transparent, then an "undo brush" would be a >more appropriate solution to that problem. So the concept of >"hiding without destroying" is not really necessary if the same >data can be retrieved from the undo history with the same >convenience. As you wrote: "However, if". While a undo brush certainly would be a nice thing to have, it certainly does not cover the same area as an anti-erase mode. > 2) For the pixels that have been obtained from an external source, >then the "hiding" concept does not fit because the RGB data is >undefined. For the files loaded from disk, the RGB values of >transparent pixels depend on the file format, on the programs that >have previously processed the file, on the current implementation >of the plug-in, etc. There are several cases: [...] > So the concept "alpha = hiding" does not work for case (2). So you basically claim that our uncertainity of what happens to the data outside the GIMP makes it impossible for us to work with that data inside the GIMP. This is nonsense. We always had the general approach to empower the GIMP user to do non-obvious stuff. Right now we don't discard RGB-information when A=0 in the core, and stuff like Anti-Erase usually just works good for power users. The new Alpha-to-mask feature you are complaining about in #127930 works and empowers users to handle Tribes2 textures. The point that you perceive this as an abuse of the PNG format is irrelevant: PNG does not discard the RGB information by itself, and there is no point in preventing our users to use it. > In addition, even case (1) has some problems because sticking to that > model would prevent the GIMP or GEGL from optimizing the memory usage > by clearing and freeing tiles that are fully transparent (this would > be useful if we want to implement layers that grow and shrink on > demand, as requested in bug #93639 and bug #98776). Right, we need to think about it, when we actually implement that fancy compression stuff. I'd love to know if layers really shrink automatically in Photoshop. When we implement this I certainly would let the user decide, if he wants automatic shrinking or not. > It is better to consider the transparent pixels to have undefined RGB > values and to make sure that these RGB values are never exposed to the > user (that would be a bug). I strongly disagree here. Just because we cannot rely on external tools to handle the RGB information for A=0 in a consistent manner, that does not mean that we should prevent the usage of that information. The user has to select the tools he want to use. And it is his responsibility to select his toolchain to handle that case in the way he wants to get it handled. Gimp should not artificially limit the way the user wants to interact with invisible information. > Other well-known programs have solved the > problem of un-erasing pixels by introducing an undo brush. I would > like the GIMP to reach or exceed the quality of these professional > programs by making sure that the features are implemented in the right > way instead of introducing new bugs. Undo Brush can only work if there actually *is* an undo history. Since Gimp might get used together with external tools this is not always the case, making it necessary to have other ways to reveal potentially important information (for pixels where A was =0). > This is is why I was suggesting to remove the bug introduced by > #127930 before it makes it into a stable release, Let me emphasize this: THIS IS NOT A BUG! A bug is not defined as "might lead to unexpected results when used in a very specific manner". > and instead > implement what I suggested in bug #128118. Beyond the next release, > this is also why we should consider removing the "anti-erase" mode of > the eraser tool in a future release and replace it by an undo brush. As mentioned above the scope of these two tools is not the same. > This would improve the quality of the GIMP and
Re: [Gimp-developer] Handling of transparent pixels
Hi, RaphaÃl Quinet <[EMAIL PROTECTED]> writes: > One thing that has not been mentioned in this discussion so far is > that there are two kinds of transparent pixels Transparent pixels are transparent pixels. There are no two kinds of transparent pixels; that would be a strange concept to introduce. > 2) For the pixels that have been obtained from an external source, >then the "hiding" concept does not fit because the RGB data is >undefined. There is no such thing as undefined RGB data. GIMP doesn't use premultiplied data, so the data is always there and I don't think you can argue that it would be undefined. >- Some indexed formats (e.g., GIF) associate a default color with > the transparent areas to be used by programs that are not able to > handle transparency correctly. Note that nothing requires a GIMP > plug-in to store this color in the image, because the GIMP > supports transparency. If such a background color is specified, transparent pixels should be filled with this color. Otherwise black seems like a good choice, but see below. >- Some other formats (e.g., RGBA PNG) store full RGBA data, so the > transparent pixels may contain some RGB values. However, these > values may be discarded by other image processing software or by > tools such as pngcrunch. A GIMP plug-in could also discard the > color of transparent pixels while loading or saving an image in > order to improve the compression. The RGB data can hardly be discarded, it can only be replaced with other data. >- In some other formats (e.g., WAD textures), the transparent > pixels are simply not stored: they are defined as a number of > pixels to skip in the current row or column, so there is not even > a concept of "default color" for these pixels. In this case, the > RGB values depend only on internal implementation details of the > plug-in used to load the file. We should probably set up a policy on how plug-ins should implement this then. The policy could say that transparent pixels should be left untouched (leaving it up to libgimp to initialize them) or alternatively be initialized to 0. > So the concept "alpha = hiding" does not work for case (2). In > addition, even case (1) has some problems because sticking to that > model would prevent the GIMP or GEGL from optimizing the memory usage > by clearing and freeing tiles that are fully transparent (this would > be useful if we want to implement layers that grow and shrink on > demand, as requested in bug #93639 and bug #98776). This is indeed an interesting point. Basically the only advantage that I could find in your concept so far but indeed a compelling one. > This is is why I was suggesting to remove the bug introduced by > #127930 before it makes it into a stable release, and instead > implement what I suggested in bug #128118. Beyond the next release, > this is also why we should consider removing the "anti-erase" mode of > the eraser tool in a future release and replace it by an undo brush. > This would improve the quality of the GIMP and make sure that the > users do not consider the alpha channel to be something that it cannot > be (not always, at least). I don't see why you want to limit GIMP in this way. It is an image manipulation program. Manipulation IMO includes being able to reveal the content of transparent areas. The information is there; why shouldn't the user be able to use it? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Handling of transparent pixels
Here is a long overdue and long-winded update to the discussion about editing the alpha channel and how transparent pixels should be handled... One thing that has not been mentioned in this discussion so far is that there are two kinds of transparent pixels: those that have been made transparent during the current GIMP editing session, and those that were already transparent when the file was loaded from disk or obtained from a plug-in. 1) For the pixels that have been made transparent during the current editing session, one point of view could be to consider the alpha channel as a "hiding mechanism" that does not modify the RGB data. However, if the goal is to be able to un-erase some pixels that were accidentally made transparent, then an "undo brush" would be a more appropriate solution to that problem. So the concept of "hiding without destroying" is not really necessary if the same data can be retrieved from the undo history with the same convenience. 2) For the pixels that have been obtained from an external source, then the "hiding" concept does not fit because the RGB data is undefined. For the files loaded from disk, the RGB values of transparent pixels depend on the file format, on the programs that have previously processed the file, on the current implementation of the plug-in, etc. There are several cases: - Some indexed formats (e.g., GIF) associate a default color with the transparent areas to be used by programs that are not able to handle transparency correctly. Note that nothing requires a GIMP plug-in to store this color in the image, because the GIMP supports transparency. - Some other formats (e.g., RGBA PNG) store full RGBA data, so the transparent pixels may contain some RGB values. However, these values may be discarded by other image processing software or by tools such as pngcrunch. A GIMP plug-in could also discard the color of transparent pixels while loading or saving an image in order to improve the compression. - In some other formats (e.g., WAD textures), the transparent pixels are simply not stored: they are defined as a number of pixels to skip in the current row or column, so there is not even a concept of "default color" for these pixels. In this case, the RGB values depend only on internal implementation details of the plug-in used to load the file. So the concept "alpha = hiding" does not work for case (2). In addition, even case (1) has some problems because sticking to that model would prevent the GIMP or GEGL from optimizing the memory usage by clearing and freeing tiles that are fully transparent (this would be useful if we want to implement layers that grow and shrink on demand, as requested in bug #93639 and bug #98776). It is better to consider the transparent pixels to have undefined RGB values and to make sure that these RGB values are never exposed to the user (that would be a bug). Other well-known programs have solved the problem of un-erasing pixels by introducing an undo brush. I would like the GIMP to reach or exceed the quality of these professional programs by making sure that the features are implemented in the right way instead of introducing new bugs. This is is why I was suggesting to remove the bug introduced by #127930 before it makes it into a stable release, and instead implement what I suggested in bug #128118. Beyond the next release, this is also why we should consider removing the "anti-erase" mode of the eraser tool in a future release and replace it by an undo brush. This would improve the quality of the GIMP and make sure that the users do not consider the alpha channel to be something that it cannot be (not always, at least). -Raphaël P.S.: I would also like to add that this discussion applies also to the pixels that are partially transparent, not only those with alpha=0. For a pixel with alpha=1, the only thing that matters for the R, G and B values is whether they are greater or lower than 128 because the result after composition would be the same. A program could decide to replace any value between 0 and 127 by another value in the same range if that would improve the compression of the image. Same for alpha=2, alpha=3, and so on... So we could consider the RGB values to be defined only to the extent that they make a difference after composition, which means that the undefined color range for a pixel is the full range when alpha=0 and gets smaller as alpha increases. P.P.S.: In a comment added to bug #127930, Guillermo S. Romero mentions that some games such as Tribes2 use RGBA PNGs and store some information in the A channel that is not alpha (reflection effect), so it would be useful to be able to edit alpha directly. However, I disagree because this kind of abuse of the file format should be supp
