Re: [Gimp-developer] caching considerations in gegl
Hi, Jakub Steiner [EMAIL PROTECTED] writes: As it turns out 1.3 is in fact able to create a layer mask from the alpha channel and then discarding the alpha channel by using alpha treshold. So it _is_ possible to 'transfer' the channel to the mask ATM. do you think we should add a simpler way to discard the alpha channel? Perhaps in the layers right-click menu? Alpha Threhold is rather well-hidden. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On 21 Mar 2003 10:23:23 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Jakub Steiner [EMAIL PROTECTED] writes: As it turns out 1.3 is in fact able to create a layer mask from the alpha channel and then discarding the alpha channel by using alpha treshold. So it _is_ possible to 'transfer' the channel to the mask ATM. do you think we should add a simpler way to discard the alpha channel? Perhaps in the layers right-click menu? Alpha Threhold is rather well-hidden. I think that discarding the alpha channel is not the appropriate way to describe this operation. After using Threshold Alpha, you still have an alpha channel with transparent and non-transparent parts (all fully transparent parts are still transparent after thresholding). So the thresholding step is useful for partially transparent pixels, but it does not discard the alpha channel. I cannot think of a better name than Threshold Alpha for this operation. Maybe it could be integrated into the Add Layer Mask dialog? -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Hi, Raphaël Quinet [EMAIL PROTECTED] writes: I think that discarding the alpha channel is not the appropriate way to describe this operation. After using Threshold Alpha, you still have an alpha channel with transparent and non-transparent parts (all fully transparent parts are still transparent after thresholding). of course it is not the appropriate way to describe it but I just used the term that Jimmac used. So the thresholding step is useful for partially transparent pixels, but it does not discard the alpha channel. I cannot think of a better name than Threshold Alpha for this operation. It is sortof a special threshold operation since it makes the alpha channel fully opaque regardless of what was there before. It's more flattening without removing the alpha channel. I really can't think of a good name for it right now. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Fri, 2003-03-21 at 10:23, Sven Neumann wrote: Hi, Jakub Steiner [EMAIL PROTECTED] writes: As it turns out 1.3 is in fact able to create a layer mask from the alpha channel and then discarding the alpha channel by using alpha treshold. So it _is_ possible to 'transfer' the channel to the mask ATM. do you think we should add a simpler way to discard the alpha channel? Perhaps in the layers right-click menu? Alpha Threhold is rather well-hidden. I tend to agree. We do have a 'desaturate' function even though there is a 'hue and satuartion' filter, simply because it is very common to get rid of all saturation. So it may make sense to have a 'discard alpha channel' filter. I'm also wondering when does one need a copy of an alpha channel on the mask while keeping the channel intact? Maybe the 'create alpha mask from alpha channel' should discard the alpha channel afterwards automatically. Or is there a sensible situation where this wouldn't be apropriate? Also if one was to 'merge' alpha channel with an existing mask, it would simply be a matter of applying the mask first (merging the two onto the alpha channel) and then creating a mask from the alpha channel again. Related to this - playing around with alpha treshold, I find myself puzzled about its behaviour. Sometimes it would become inactive even though I made sure I'm trying to use it on a layer with alpha channel. The fact that it becomes available on a duplicate of the image makes me feel it is in fact a bug? cheers -- Jakub Steiner [EMAIL PROTECTED] Ximian, Inc. signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] caching considerations in gegl
On Fri, 2003-03-21 at 11:15, Raphal Quinet wrote: I think that discarding the alpha channel is not the appropriate way to describe this operation. After using Threshold Alpha, you still have an alpha channel with transparent and non-transparent parts (all fully transparent parts are still transparent after thresholding). reset alpha channel? flatten alpha channel? make opaque? -- Jakub Steiner [EMAIL PROTECTED] Ximian, Inc. signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] caching considerations in gegl
On Wed, 2003-03-12 at 00:03, Daniel Rogers wrote: Adam D. Moss wrote: The idea isn't that the layer mask usurps image alpha, but that traditional paint/fill tools are generally used to increase opacity and define colour simultaneously (they do), while layer masks are extremely handy ways to safely experiment with eroding opacity away again as a logically separate composition step rather than a destructive processing of the RGBA data. --Adam I like this distinction. This should be written down somewhere. Probably in the manual (if it isn't already). This clearly describes precisely what approach to use when. Related to this, I would love to have a function that would enable me to create a layer mask from alpha channel or apply it to the existing mask. That way it would be possible to increase opacity with a layer mask by first applying the alpha channel to the mask and then 'darkening' the layer mask. To me this is a missing link between alpha channel and mask. We already have similar function when working with selections/channels. cheers -- Jakub Steiner [EMAIL PROTECTED] Ximian, Inc. signature.asc Description: This is a digitally signed message part
Re: [Gimp-developer] caching considerations in gegl
Hi, Adam D. Moss [EMAIL PROTECTED] writes: If there is a bug then it is in the remaining tools and plugins that 1) Use the RGB value of an utterly transparent RGBA (or indeed GREYA) pixel (try to tell me that this is a desirable feature in the blur plugins, for example), or 2) Try to allow a user to resurrect the colour of an utterly RGBA transparent pixel (e.g. anti-erase AKA the 'should have used a layer mask in the first place, or how do you see what you're interactively unerasing until you've unerased it?' tool). are you saying that we'd best remove the Anti-Erase feature from the current development version because it is broken by design and only works by accident (often but not reliably)? That's how I interpret your words but I want to be sure... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Ernst Lippe wrote: On Tue, 11 Mar 2003 17:12:14 +0100 Raphaël Quinet [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2003 16:38:13 +0100, Ernst Lippe [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2003 09:46:49 + Adam D. Moss [EMAIL PROTECTED] wrote: I think that the user should be able to edit the alpha channel independent from the other channels. I don't think that it is unreasonable that a user initially makes some parts of the layer transparent, then makes some other edits to the layer and finally decides that the transparency boundaries should be slightly different, e.g. slightly more feathered. In most cases this will work fine but when some of the tiles have been scrubbed this will not work for these tiles. I think that it _is_ unreasonable to expect this to work. Why? Normally operations on the alpha don't influence the state of the other color components, so I don't really see why it would be reasonable to assume that changing to full transparency is a priori different. Also it is the simplest way to implement the whole thing. Can anyone tell me what users expect? If an unerase feature exsists in other products then I perhaps in may be worthwhile to observe how they do it, cause that would be how new users expect it to work. (I am not just considering Photoshop here, but Shake and Chalice, both of which are influencing Gegl's design). -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Sven Neumann wrote: are you saying that we'd best remove the Anti-Erase feature from the current development version because it is broken by design and only works by accident (often but not reliably)? That's how I interpret your words but I want to be sure... I think that's the case. From a practical point of view the way things are at the moment you'd have to try fairly hard to get into a situation where you'd see the horizonal line drop-outs from the skipped compositing of transparent rows by the attempted resurrection of undefined colour data, but it's possible. From a more aesthetic 'broken by design' point of view, XachBot's antique logs probably catch me whining about anti-erase a few times. :) --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Sven Neumann wrote: which operation (besides the evil anti-erase) wouldn't have such a color information? IIRC the only other tool I found that can be made to resurrect colour information is the Levels tool operating on the Alpha channel (I think that the current selected BG colour is a good choice for filling in the resurrected areas, if we allow the resurrection at all). There might be a few more plugins and such that accidentally cause a similar effect, but by accident (usually undesirable at that) rather than design. --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Tue, 11 Mar 2003 18:20:34 +0100, Ernst Lippe [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2003 17:12:14 +0100 Raphaël Quinet [EMAIL PROTECTED] wrote: I think that it _is_ unreasonable to expect this to work. Why? Normally operations on the alpha don't influence the state of the other color components, so I don't really see why it would be reasonable to assume that changing to full transparency is a priori different. It works that way because the GIMP uses post-multiplied alpha and you know it. If we were having this discussion about a program that uses pre-multiplied alpha (this is common in game editors, for example), then things would be very different. Also it is the simplest way to implement the whole thing. I agree. But that doesn't mean that it makes more sense for the user's point of view. Ideally, the average user should see no difference if we suddenly decided that the GIMP should work with pre-multiplied alpha (in which all color information is definitely lost when making a pixel transparent). But how do you handle the case when a user would try to make a transparent pixel non-transparent. This pixel should then get a color, but which one? It should get the color that you are currently painting with, because the only way to make a transparent pixel non-transparent is (or should be) to paint in it with some tool. You cannot create color where it doesn't exist (or shouldn't exist). So I think that we should not suggest that the alpha channel is like any other channel. Making a pixel fully transparent should be considered as a destructive operation for the corresponding RGB data (or let's say that the behavior is unspecified, which is a good description of what happens now). In general unspecified behavior is not a nice thing to have (I am almost tempted to write EVIL). In most cases where a system has unspecified behavior the user makes assumptions on how it works and is unpleasantly surprised when in a few cases the system, for unknown reasons, behaves very differently. So don't do that, then! ;-) Nobody should rely on unspecified behavior. One day, someone could decide that the GIMP would work better by compressing tiles on-the-fly in memory and clearing the RGB data of fully transparent pixels in order to improve the compression. And then all hacks that were relying on unspecified behavior would suddenly break. Who is to blame? Not the GIMP developer, IMHO. The one to blame is the one who has used a feature that was not supposed to be used. We could of course specify that all fully transparent pixels are always set to black. But this is not done currently because this would imply a small (or maybe not so small) performance penalty. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Steinar H. Gunderson wrote: On Tue, Mar 11, 2003 at 06:36:47PM +0100, Sven Neumann wrote: which operation (besides the evil anti-erase) wouldn't have such a color information? The only operation I can think of that makes a transparent pixel non-transparent is some sort of painting with one of the paint tools. Such a paint operation always has the color information we need. Blur? /* Steinar */ I don't think Blur counts here. Alpha is a measure of the amount of coverage of the pixel. (e.g. an alpha of .5 means half the pixel is covered). In particular, 0 alpha means that the pixel is not covered at all. This means that the pixel contributes NO color information. I think this should hold for blur as well. And from that point of view, no pixel with alpha zero should ever contribute color information. Another way to look at it is that alpha is as important to the color information as the actual RGB channels. No operation should be performed without considering the alpha channel (except for a color-space conversion, which isn't really an issue in gimp-current, also, please correct me if I am wrong). Thus alpha is an inherent part of the color information. Thus if alpha is zero, our math tells us the color is non-exsistant. Another way to look at it is that alpha is a solution to the aliasing problem when you try to draw lines (say the bounding lines of a polygon) at arbitary angles. Sub-pixel precision tells us that the line doesn't cover an entire pixel, so we use alpha as an approximation to express this partial coverage of edges. But alpha here is an essential part of the edge. It tells us, approximatly how far the edge extends into the pixel. Thus a blur operation that was applied to the edge is incorrect if is doesn't take into account the alpha. A better implementation of anti-erase would try to keep an old version of the tile around, so that it could just read the old color data back when necessary, but at this point, why not just use a mask layer (since you are effectively keeping one around anyway)? Incidentally, gegl premultiplies it's images, so if anyone really really wants to use unerase in gimp 2.0, please voice an opinion so we can consider not pre-multiplying. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Tue, 11 Mar 2003 18:55:33 +0100, David Necas (Yeti) [EMAIL PROTECTED] wrote: On Tue, Mar 11, 2003 at 05:13:43PM +, Adam D. Moss wrote: If there is a bug then it is in the remaining tools and plugins that 1) Use the RGB value of an utterly transparent RGBA (or indeed GREYA) pixel (try to tell me that this is a desirable feature in the blur plugins, for example), or This is essentially my example from the Noisify plug-in discussion mentioned earlier (one can figure out other ways how to achieve the desired effect, but I do not consider them natural). [...example skipped...] Your example is fine, except for the last step using Noisify on the alpha channel. As Adam pointed out in his previous messages, the correct way to acheive the same effect would be to use Noisify on a layer mask, not on the alpha channel. Noisify and other plug-ins such as Hurl/Pick/Slur should never make a transparent pixel non-transparent (except maybe by working with pre-multiplied alpha, as I suggested in the bug report). So either we completely disable the option to work on the alpha channel, or we change the code in such a way that the noise can only increase the transparency, but not decrease it (i.e., creating color in a transparent area). -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Tue, Mar 11, 2003 at 07:23:03PM +0100, Sven Neumann wrote: I don't agree. The obvious solution whenever manipulation of the alpha channel is desired is to use a layer mask. For people on this list. But most people I know would be able to find the solution I described -- purely experimentally -- while they don't know there's anything like layer mask, and mabye will never find out. Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Tue, Mar 11, 2003 at 10:15:51AM -0800, Daniel Rogers wrote: Alpha is a measure of the amount of coverage of the pixel. (e.g. an alpha of .5 means half the pixel is covered). In particular, 0 alpha means that the pixel is not covered at all. This means that the pixel contributes NO color information. I think this should hold for blur as well. And from that point of view, no pixel with alpha zero should ever contribute color information. How do you propose this being implemented, ie. what value would you plug into the IIR filter GIMP's blur is based on, for a pixel with alpha != 255? /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Hi, David Necas (Yeti) [EMAIL PROTECTED] writes: On Tue, Mar 11, 2003 at 07:23:03PM +0100, Sven Neumann wrote: I don't agree. The obvious solution whenever manipulation of the alpha channel is desired is to use a layer mask. For people on this list. But most people I know would be able to find the solution I described -- purely experimentally -- while they don't know there's anything like layer mask, and mabye will never find out. anyone who wants to seriously work with images will have to read a book about it or at least look at some online tutorials. Masks are a rather traditional technique offered by all higher-level image-editing applications. I don't think it is asked too much. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Raphaël Quinet ([EMAIL PROTECTED]) wrote: Your example is fine, except for the last step using Noisify on the alpha channel. As Adam pointed out in his previous messages, the correct way to acheive the same effect would be to use Noisify on a layer mask, not on the alpha channel. Be careful: A layer mask can *not* do everything you could do with manipulating the alpha channel directly. Especially it is impossible to increase the opacity of the layer with a layer mask. Imagine a blurred circle on a layer and you want to make the transition to the transparency non-linear, e.g. more like a cosine. Basically this is impossible with a layer mask, because it cannot increase the opacity in some areas. Also - if we talk about more complicated shapes - it might be very tedious to manipulate the layer and the layer mask synchronously. Of course this example can be done very conveniently with the curves tool on the alpha channel, but you have to make sure that accidental changes to total transparency do not throw away the color information until the tool is finished. A layer mask is not a substitute for manipulating the alpha channel directly! Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Daniel Rogers wrote: I am missing some context here. Why does a tile get dirty? In gimp parlance, a tile is 'dirtied' whenever its pixel data gets written to (okay, that's a bit ambiguous with the tile ref system -- that could mean either when a write-able reference is added to it or when that reference is removed again upon the write completion). -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Steinar H. Gunderson wrote: On Tue, Mar 11, 2003 at 10:15:51AM -0800, Daniel Rogers wrote: Alpha is a measure of the amount of coverage of the pixel. (e.g. an alpha of .5 means half the pixel is covered). In particular, 0 alpha means that the pixel is not covered at all. This means that the pixel contributes NO color information. I think this should hold for blur as well. And from that point of view, no pixel with alpha zero should ever contribute color information. How do you propose this being implemented, ie. what value would you plug into the IIR filter GIMP's blur is based on, for a pixel with alpha != 255? /* Steinar */ Weight the pixel value by the alpha value, just like you do with any other operation on pixels. This makes sense when alpha is defined to be the coverage. If a pixel is only really half covered, their should half the impulse response on the convolution kernel. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
David Necas (Yeti) wrote: I want a yellow opaque circle, with edges blurred to transparent and some fine yellow pixelish haze around. The transition I also don't like continuous, but spotty with varying opacity, so one can see the background better or worse through individual pixels. Layer mask! But thanks for bringing it to our attention that Noisify is one of the broken plugins in this respect. This isn't a new breed of brokenness that popped up when tile-row-hints went in. It's a fundamental problem with how some plugins handle alpha data and it's been evident for as long as GIMP has had alpha support. Create a new transparent image, draw a yellow blob in the middle, then blur the image by 10px. I really hope you'd expect to see a blurry yellow blob rather than blurry blob that's yellow in the middle and black (or worse) towards the edges... but the latter is what you used to get until someone (Raphael?) went around finding and fixing the various places that assumed that RGB and alpha are logically decoupled. They're not. You can't operate on them orthogonally, 'A' is not just another dimension in 'RGBA space' -- it's simply not, but when a tool/plugin makes this mistake it's just asking to fall into the singularity. In someone's mental model color values are inherently premultiplied, and alpha == 0 means R, G, B == 0. In someone's alpha channels is a fourth independent value we attached to each pixel and it doesn't directly interact with R, G, B. This schizm can't be solved because both model are correct in some sense and in some situations. However, Gimp uses separate alpha channel internally thus I see as illogical to force the other mental model. If you wish to have an alpha-adjusting playing-field then a layer masks is conceptually an operation that gets applied to RGBA pixel data as part of the compositing step, and that's super. -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Daniel Rogers ([EMAIL PROTECTED]) wrote: [maybe increasing the opacity] If you were to do something like this, where you wanted to have control of the full range of opacity in a layer mask, then the first mistake you made was to add alpha to the image when you should have added a layer mask. In this situation it is best to remove all alpha from the image (or your roi), and use just a layer mask. Sorry, this is a step back towards Gimp 0.54 where you had no embedded alpha channel in the images and compositing of two images (that had to have the same size) was done via a third grayscale image (that also had to have the same size). When being forced to use the layer mask for all images where I might decide to increase the opacity later drawing some random strokes on the layer becomes a non-trivial task, because I have to care that these strokes are drawn exactly the same in the layer itself *and* in the layer mask. Also the painting algorithm would have to use two different algorithms for strokes on top of another opaque area in the layer and for strokes in the area in the layer where the layer mask makes it transparent. While Gimp could do this for me it would also include the overhead of accessing two drawables simultaneously which is not really good. Uhm. Yes. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Daniel Rogers wrote: There may be some worth in considering including other kinds of information in a pixel besides alpha. In addition to alpha (the measure of coverage) you could also include transparency (which is something a measure of how much light passes through, i.e. the actual transparency of glass, as opposed the the coverage of a screen, this is equivilent to insisting on a layer mask to be included for every layer). It is a little tempting, as it would remove a lot of ambiguity in the overloading of the meaning of the alpha channel. We've (well, GIMP and probably most other transparency-handing packages out there) been equating transparency with alpha for so long now though that I'd hate to have to re-educate users. But it needn't be something that the front-end has to expose. We could also include luminesence, which is a measure of how much light a pixel produces (as opposed to reflectance, which is all we measure how with rgb). There are various per-pixel properties I could think of which might be very exciting (surface normal vector, specular reflection index) especially for natural media rendering. Luminescence wouldn't be the first that'd come to my mind, since I think that any such image elements would by nature be quite isolated and fit very well on their own 'addition' style layer and save a lot of complexity, but perhaps it would be nice to paint with fire after all... -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 busting makes me feel good kthx bye ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Tue, Mar 11, 2003 at 11:41:30AM -0800, Daniel Rogers wrote: Weight the pixel value by the alpha value, just like you do with any other operation on pixels. This makes sense when alpha is defined to be the coverage. If a pixel is only really half covered, their should half the impulse response on the convolution kernel. And so, if you're blurring with some transparent area, it's equivalent to blurring with black? Doesn't make sense to me -- or am I missing something? /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Steinar H. Gunderson wrote: On Tue, Mar 11, 2003 at 11:41:30AM -0800, Daniel Rogers wrote: Weight the pixel value by the alpha value, just like you do with any other operation on pixels. This makes sense when alpha is defined to be the coverage. If a pixel is only really half covered, their should half the impulse response on the convolution kernel. And so, if you're blurring with some transparent area, it's equivalent to blurring with black? Doesn't make sense to me -- or am I missing something? /* Steinar */ Not quite the same. Black is not the same as no information. A little coverage is some information, while no coverage is no information. It is the same problem you have with blurring near the edges of an image. I think the best way to treat to problem is to declare that there is no data, and determine the best way to pad your blur (presumably you would use the same padding stragety you used around the edges of the image). You might even go to the trouble of padding partial pixels (eg, blending the padding pixel with the partially covered pixel). This breaks down though when you start to treat coverage as transparency again. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Adam D. Moss wrote: In addition to alpha (the measure of coverage) you could also include transparency (which is something a measure of how much light passes through, i.e. the actual transparency of glass, as opposed the the coverage of a screen, this is equivilent to insisting on a layer mask to be included for every layer). It is a little tempting, as it would remove a lot of ambiguity in the overloading of the meaning of the alpha channel. We've (well, GIMP and probably most other transparency-handing packages out there) been equating transparency with alpha for so long now though that I'd hate to have to re-educate users. But it needn't be something that the front-end has to expose. I think the best way to go here is to re-educate users, without breaking what they expect alpha to be. I think the best way to deal with this is quoted in a email I just sent: This is why I suggested earlier the seperation between transparency and coverage. Any drawing operation would have to consider whether it is adding transparency or coverage or both at every pixel (a pixel could be partially covered by a transparent effect). This would mean that instead of an alpha channel and a layer mask, we should have a coverage channel and a transparency channel. (giving way to RGBCT colorspaces). In this sort of situation, the full measurement of the pixel includes all five numbers, and any algoritm that affect pixels would have to take into account all five numbers (just as any operation now must account for all four exsisting pixel measurement numbers). Indcidenally, alpha, in the way it as been used would be C*T. We then explain to the user the benefit of the RGBCT colorspace over the RGBA colorspace. Since A=C*T it should be easy to write drawing functions that handle both cases just as easily. I don't think that since it has always been done this way, there should be a reason to keep doing it that way. I don't know if this is really the best approach, but I think it allows for a better representation of real life. And yeah, even if we use coverage and transparently internally, it doesn't mean we have to tell the front end about it (though abstractions have a way of leaking precisely when you don't want them too). We could also include luminesence, which is a measure of how much light a pixel produces (as opposed to reflectance, which is all we measure how with rgb). There are various per-pixel properties I could think of which might be very exciting (surface normal vector, specular reflection index) especially for natural media rendering. Luminescence wouldn't be the first that'd come to my mind, since I think that any such image elements would by nature be quite isolated and fit very well on their own 'addition' style layer and save a lot of complexity, but perhaps it would be nice to paint with fire after all... Yes, I agree. There is certainly a benefit to keeping the number of numbers used to describe a point in space to a minimum (I sure we could come up with more, with a little effort). And it may be that the distinction between coverage and transparency is better suited to a 3d renderer, where real-life modeling is more important. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Simon Budig wrote: Sorry, this is a step back towards Gimp 0.54 where you had no embedded alpha channel in the images and compositing of two images (that had to have the same size) was done via a third grayscale image (that also had to have the same size). I am not suggesting that alpha is gotten rid of entirly in all cases. Just that in this specific case, where you want the full opacity to be controlled by a layer mask, you should get rid of alpha in the area where you want the layer mask to control your opacity. This is specifically because of the overloaded nature of alpha here. Alpha is being used as transparecy but (correctly) is mathematiclly treated as the coverage. When being forced to use the layer mask for all images where I might decide to increase the opacity later drawing some random strokes on the layer becomes a non-trivial task, because I have to care that these strokes are drawn exactly the same in the layer itself *and* in the layer mask. This is why I suggested earlier the seperation between transparency and coverage. Any drawing operation would have to consider whether it is adding transparency or coverage or both at every pixel (a pixel could be partially covered by a transparent effect). This would mean that instead of an alpha channel and a layer mask, we should have a coverage channel and a transparency channel. (giving way to RGBCT colorspaces). In this sort of situation, the full measurement of the pixel includes all five numbers, and any algoritm that affect pixels would have to take into account all five numbers (just as any operation now must account for all four exsisting pixel measurement numbers). Indcidenally, alpha, in the way it as been used would be C*T. Also the painting algorithm would have to use two different algorithms for strokes on top of another opaque area in the layer and for strokes in the area in the layer where the layer mask makes it transparent. While Gimp could do this for me it would also include the overhead of accessing two drawables simultaneously which is not really good. I think what I said above addresses this. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Simon Budig wrote: Sorry, this is a step back towards Gimp 0.54 where you had no embedded alpha channel in the images and compositing of two images (that had to have the same size) was done via a third grayscale image (that also had to have the same size). Incidentally, this is precisely what movie compositers have to do when they composite real images. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Daniel Rogers ([EMAIL PROTECTED]) wrote: [...]. This is specifically because of the overloaded nature of alpha here. Alpha is being used as transparecy but (correctly) is mathematiclly treated as the coverage. [...] This is why I suggested earlier the seperation between transparency and coverage. Any drawing operation would have to consider whether it is adding transparency or coverage or both at every pixel (a pixel could be partially covered by a transparent effect). Sorry, but I don't believe that this destinction would make sense. From my point of view transparency/opacity and coverage are two models to explain what happens when talking about alpha. I do know that the original Porter Duff paper based its conclusions on the coverage model, however, the transparency analogy comes closer to what happens when gimp is building its projection of the image. For proper coverage handling you'd have to store the information *what* part of the pixel has been covered. Better leave that to a vector based implementation. The coverage model also fails to model a flat area of e.g. 50% opacity (a surface with a small hole in each pixel...). This would mean that instead of an alpha channel and a layer mask, we should have a coverage channel and a transparency channel. (giving way to RGBCT colorspaces). In this sort of situation, the full measurement of the pixel includes all five numbers, and any algoritm that affect pixels would have to take into account all five numbers (just as any operation now must account for all four exsisting pixel measurement numbers). Indcidenally, alpha, in the way it as been used would be C*T. I fail to see what would be the win in this situation. All algorithms would have to be revised and I really doubt that this separation would make the algorithms simpler. E.g. Blur: It is ok, to blur the opacity channel, but blurring the coverage channel does not make sense, because it does not fit in the model of partially covered pixels. What should we do? And how would we present unexpected results to the user? And where would be the win for the added memory requirements, more complicated algorithms and users looking blankly at the screen and trying to figure out what is going on? That said I could see some use for additional channels in the image. Normal-Vectors or glossiness are an exciting idea, especially when using them for generating textures. It also would be cool to have spot-color channels in the image so e.g. distort plugins would distort the image+spot color information together and you don't have to apply the same plugin multiple times in the very same manner on multiple drawables. It would be nice if these things were possible. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Simon Budig wrote: Sorry, but I don't believe that this destinction would make sense. From my point of view transparency/opacity and coverage are two models to explain what happens when talking about alpha. I do know that the original Porter Duff paper based its conclusions on the coverage model, however, the transparency analogy comes closer to what happens when gimp is building its projection of the image. The distintion is only important when deciding what to do when color information goes to zero. Coverage says it goes away, transparency says it stays. Also, alpha is the model. Transparency and coverage are the real (as in reality) things. Though I suppose that depends on whether you feel art imitates life, or that life imitates art (and I am not poking fun here, it's an iteresting philosophical debate). For proper coverage handling you'd have to store the information *what* part of the pixel has been covered. Better leave that to a vector based implementation. The coverage model also fails to model a flat area of e.g. 50% opacity (a surface with a small hole in each pixel...). Yes indeed. Alpha as a measure of coverage is an approximation. The core blending ops derive directly as an extension of this approximation. Since alpha doesn't declare how a pixel is covered, when two pixels overlap you can describe how they overlap in one of 5 ways, listed in a chart on page 838 of Computer Graphics (2nd ed, Foley, et. al.). But as I said above, I think the difference is only vital when you have to decide what happens at zero. This would mean that instead of an alpha channel and a layer mask, we should have a coverage channel and a transparency channel. (giving way to RGBCT colorspaces). In this sort of situation, the full measurement of the pixel includes all five numbers, and any algoritm that affect pixels would have to take into account all five numbers (just as any operation now must account for all four exsisting pixel measurement numbers). Indcidenally, alpha, in the way it as been used would be C*T. I fail to see what would be the win in this situation. All algorithms would have to be revised and I really doubt that this separation would make the algorithms simpler. E.g. Blur: It is ok, to blur the opacity channel, but blurring the coverage channel does not make sense, because it does not fit in the model of partially covered pixels. What should we do? And how would we present unexpected results to the user? It is only a small change to the algorithms (if anyone wants I can work out what I think are reasonable models, do the math and stick 'em on the list, I have already done some of it anyway). And I would think that blur would apply to a partial pixel and ignore opacity (depending on just how you modeled opacity) The impluse to the blur would be smaller, as discussed earlier. Including the alpha is the correct way to blur. The win in this situation would be greater flexiblity in deciding when it is appropriate to discard color information, also a more complex model would allow for more complex results. AFAIK, this seperation between coverage and transparency has never been modeled before in a real application, so I cannot provide any research or data about how useful it would be. I can only go with what I have mangaged to work out myself, and my gut feeling. My gut feeling tells me this might be useful. And where would be the win for the added memory requirements, more complicated algorithms and users looking blankly at the screen and trying to figure out what is going on? User's will figure it out. Since no one has ever tried to work with this before, it is hard to say what uses people will come up with. (I mean really, what would anyone use a laser for?) Besides, I am suggesting that if they don't want to work in RGBCT they can always work in RGBA. The added memory requirements give way to more complex results. That said I could see some use for additional channels in the image. Normal-Vectors or glossiness are an exciting idea, especially when using them for generating textures. It also would be cool to have spot-color channels in the image so e.g. distort plugins would distort the image+spot color information together and you don't have to apply the same plugin multiple times in the very same manner on multiple drawables. It would be nice if these things were possible. Agreed. I will try to see about incorporating these extra channels into gegl (not necessarlly C and T from above, but the others certainly). -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
