Re: [Gimp-developer] caching considerations in gegl
On Fri, 2003-03-21 at 11:15, Raphaël 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 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
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 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, 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 Fri, 2003-03-21 at 01:24, Jakub Steiner wrote: > To me this is a missing link between alpha channel and mask. We already > have similar function when working with selections/channels. 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. Jakub Steiner :: gfx [ http://jimmac.musichall.cz ] 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
On Tue, 11 Mar 2003 19:05:03 +0100 Raphaël Quinet <[EMAIL PROTECTED]> wrote: > On Tue, 11 Mar 2003 18:20:34 +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote: > So don't do that, then! ;-) Nobody should rely on unspecified > behavior. But how should an end-user know that this is unspecied behavior? I could not find anything in the documentation that came with my version of the GIMP :) > 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. Who else do you think an end-user is going to blame? Remember that end-users are in general horrible beings: they believe that they know what they want to do and they even believe that the GIMP is simply a tool that they could use. When that tool does not do what they want it is always the tool that is wrong. Another problem with end-users is that they don't really want to learn new things. The first time they will notice that the GIMP removes color information is when they start using it for a serious job with large images. For unknown reasons end-users tend to have an extremely low frustration tolerance when they are working on jobs that they consider serious (this might have something to do with these things that they call deadlines). Instead of being grateful that they have learned that they were sinning, they will usually start complaining: "But it works fine on this part of the image" or "But it worked 5 minutes ago". > The one to blame is the one who has used a feature that was not supposed > to be used. But why does it have an unerase then? > 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. But how great is that penalty? At least this gives consistent behavior. greetings, Ernst Lippe ___ 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
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, 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
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
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. -- 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
On Tue, Mar 11, 2003 at 07:05:03PM +0100, Raphaël Quinet wrote: > 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. The apps with pre-multiplied alpha are lossy, and they know it. They do it because it's faster, or just because it's become traditional. We should not model ourselves on them IMHO. Nick. ___ 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
On Tue, Mar 11, 2003 at 10:14:50PM +0100, 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? No; when you combine pixels premultiplied alpha works OK. On separated alpha it can be written (with weigths 1/2, for brevity) Alpha= (Alpha1 + Alpha2)/2 ColorChannel = (Alpha1*ColorChannel1 + Alpha2*ColorChannel2)/2/Alpha This is equivalent to Alpha = (Alpha1 + Alpha2)/2 PremulChannel = (PremulChannel1 + PremulChannel2)/2 on premultiplied alpha. Blurring with black only occurs when you don't combine pixels and just increase alpha of a pixel. Yeti ___ 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: 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. True! I was in mind of style of assembling/creating images where you start with something solid and then cut/peel/molest away parts of it, which excellently fits layer mask usage. The converse would be the approach whereby you start with transparency and build up the result by 'painting onto glass' -- personally I use a mix of both approaches. 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 -- 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 20:05:39 +0100, "Steinar H. Gunderson" <[EMAIL PROTECTED]> 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? You would not plug any color there, of course. Or more exactly, the color would not matter because it would be multiplied by 0 anyway. Please take a look at the formulas in these two bug reports: http://bugzilla.gnome.org/show_bug.cgi?id=70335 http://bugzilla.gnome.org/show_bug.cgi?id=72853 The IIR Blur filter was also affected by that bug but it has been fixed thanks to David Necas (Yeti): http://bugzilla.gnome.org/show_bug.cgi?id=72848 -Raphaël ___ 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: 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! 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. If you are going to disallow the editing of alpha, then you will probably want to have a way to extract alpha information into a layer mask (at the same time, removing alpha (or setting it all equal to 1.0) from the image) in case someone is handed a merged image. You should combine this operation with an edge detection scheme so that you can exclude removing alpha when alpha is actually being used to describe coverage instead of transparency. -- 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, 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
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
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
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
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
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
On Tue, Mar 11, 2003 at 08:05:39PM +0100, 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? Gimp Blur tool is not fixed yet, but IIR Blur plug-in is -- so you can look at the patch http://bugzilla.gnome.org/show_bug.cgi?id=72848 The tool will work along the same lines (there are matrices and such stuff, but the idea doesn't change). There are no doubts how pixels should be blended together (which is what blur does), the only source of controversy is handling of alpha of individual pixels (i.e., no pixel interaction involved). Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
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). 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). Not I am equating the following concepts alpha == coverage (like a metal screen over a window) layer mask == transparency (like glass, or, incidently, colored glass if you extend your layer mask to include all color channels). luminesence == the amount of light pixel produces at zero coverage (this is equivlent to additional layers) -- Dan ___ 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
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
On Tue, Mar 11, 2003 at 07:15:16PM +0100, Raphaël Quinet wrote: > On Tue, 11 Mar 2003 18:55:33 +0100, "David Necas (Yeti)" <[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. > > 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). I'm for disabling operation on alpha completely (I'll fix it this way when I find some time). IIRC this means removing the Alpha slider (and corresponding functionality) from Noisify and changing Hurl/Pick/Slur to work only on color channels. I can't imagine how it could do anything both useful and politically correct with alpha. (Feel free to suggest something, but working on premultiplied alpha satisfies only the second condition, because no one wants to average pixels with invisible black). Everyone will have to learn how to use Layer Masks then -- but, well, that's not my problem -- if usability people think this is the right approach, who I am to oppose ;-) 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
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
Raphaël Quinet wrote: > The one to blame is the one who has used a feature that was not supposed to be used. Well, to be fair I wouldn't blame the user, I'd blame the specific tool that was ill-conceived or ill-implemented. And even then we've never had an explicit policy on programmatic alpha handling, and assumed that common-sense should prevail, but I think now we should have an explicit policy instead. :) :) :) --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: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
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
Adam D. Moss wrote: It's a reasonable direction, I think, but I have two comments: * It probably makes sense to detect whether a whole tile is transparent/solid/etc just-in-time when you're about to consider swapping it out (or dropping it down to a colder cache) instead of every time it gets dirty. IIRC the tile-row-hints stuff does this sort of stuff just-in-time too, at compositing time, so effort isn't wasted on the various sorts of tiles, transient or otherwise, that never end up getting composited (but I'm an old man and my memory is getting hazy; I'd forgotten that the tile-row-hints stuff even existed and I should bloody well know). I am missing some context here. Why does a tile get dirty? (To offer a guess at understanding, what two blocks of memory are getting out of sync when a tile is dirty?). ___ 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 17:53:58 +, "Adam D. Moss" <[EMAIL PROTECTED]> wrote: > 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. That's right. I tried to track them down in this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=70335 Thanks to the help of David Necas (Yeti), several of these bugs have recently been fixed. Even if we disagree about whether some of these effects are undesirable or not. :-) -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, "David Necas (Yeti)" <[EMAIL PROTECTED]> writes: > 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). > > 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. (Hm, my English is poor, > but I hope you understand what I mean.) > > The obvious solution is following: Fill whole area with > yellow. Select a circle there. Blur the selection. Invert > slection. Clear selection. Use Noisfy only on Alpha channel. > (Now you can further shape the haze.) I don't agree. The obvious solution whenever manipulation of the alpha channel is desired is to use a layer mask. 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 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
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). 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. (Hm, my English is poor, but I hope you understand what I mean.) The obvious solution is following: Fill whole area with yellow. Select a circle there. Blur the selection. Invert slection. Clear selection. Use Noisfy only on Alpha channel. (Now you can further shape the haze.) If transparent pixels forgot their state, I would have to create the circle (base opacity nonzero) and the pixelish haze (base opacity zero) separately (or use other trick like using pixel with opacity 1/255 as pseudotransparent and fix them with curves or histogram tool after I finished it -- this dirty trick itself illustrates the nature of the problem quite well). Only becasue transparent pixels were discriminated. 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. Yeti ___ 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
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
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 */ -- 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, Ernst Lippe <[EMAIL PROTECTED]> writes: > 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? White and black are possible choices, and in most cases the user > will want neither of them. Perhaps every operation that potentially > could change a transparent pixel should have an additional argument > that specifies the color for those pixels? 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. 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
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
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. > If the user > wants to change the transparency boundaries, then the correct way to > do it would be to undo the steps that have shrunk the visible area > (and then it does not matter if the transparent tiles used in the > following steps have been scrubbed or not). The point was that fiddling with the boundaries as a final step after you have made other modifications to the layer looks like a pretty normal scenario to me. In your proposal it is safe to make the area smaller, but there is no way to make it bigger or use a slightly different feathering. The only way to undo a wrong initial decission is to undo all subsequent edit steps. I am very certain that I would not be too happy about having to start all over again. > You seem to imply that > the user would use the "anti-erase" option as a normal feature. Why not? It is very easy to give good semantics for this feature. > I always considered the "anti-erase" feature to be evil. > 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? White and black are possible choices, and in most cases the user will want neither of them. Perhaps every operation that potentially could change a transparent pixel should have an additional argument that specifies the color for those pixels? > 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. I think that we both have reasons to be unsatisfied with the current implementation. The main point for me is that the current implementation leads to irreproducible behaviour. When it is desirable to remove all color information from transparent pixels the right place to implement this is in the operation that modifies the alpha and not somewhere hidden in the tile caching. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
Nick Lamb wrote: On Tue, Mar 11, 2003 at 04:38:13PM +0100, Ernst Lippe wrote: I think that the user should be able to edit the alpha channel independent from the other channels. Agreed. Then don't be shy of layer masks, they're a lot more flexible than operating directly on the pixels' alpha data. The meaning of a pixel's colour is tied very closely to its alpha (ie. the relationship, precision aside, is such that you can use any pair of the RGB, the alpha, and the weighted result to derive the third), and a colour becomes undefined when it loses all weight. This is the *RGBA PIXEL*'s alpha, a property of the pixel, not an arbitrary value that we carry around in the same word as the RGB data simply for purposes of rendering convenience. If a pixel is RGBA it's as fair to say that its RGB values become undefined when its A hits 0 as it is to say that an HSV pixel's H becomes undefined when its V hits 0. 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). If you want to tweak a layer's alpha values forever without the risk of sending the RGB part of RGBA pixel data to la-la land, use a holy layer mask and/or the undo tool! If you want an auxilliary per-pixel channel that doesn't have fixed semantics tied to a pixel's RGB values at all, use an auxilliary channel. --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, Mar 11, 2003 at 04:38:13PM +0100, Ernst Lippe wrote: > I think that the user should be able to edit the alpha channel independent > from the other channels. Agreed. I did some work on making this really true, but I'm not sure how much of it landed in CVS. Nick. ___ 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 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. If the user wants to change the transparency boundaries, then the correct way to do it would be to undo the steps that have shrunk the visible area (and then it does not matter if the transparent tiles used in the following steps have been scrubbed or not). You seem to imply that the user would use the "anti-erase" option as a normal feature. I always considered the "anti-erase" feature to be evil. 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). 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). -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, 11 Mar 2003 09:46:49 + "Adam D. Moss" <[EMAIL PROTECTED]> wrote: > The idea > of rehash-on-dirty would be to catch identical tiles, even > accidentally-identical tiles (like great masses of transparent > tiles, presuming that you scrub the RGB data of a transparent > pixel; the row-hints stuff has been doing this and potentially > breaking the ill-advised anti-erase feature for 100 years now > and no-one has complained) Perhaps because no-one knew, you should not have told us this. 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. In my mental model the alpha information is simply one of the "color" channels, that are all completely independent from one another. What I find particularly nasty is that scrubbing could happen at unexpected moments and this makes it very difficult to reproduce any bugs that are related to this "feature". If it is really desirable to remove color information from transparent pixels, this must have a predictable behavior. The logical place seems to be the operations that modify the alpha channel, e.g. erase. These operations should set the color channels to 0 for transparent pixels. In this way you get at least reproducable behavior. Finally, when everybody believes that scrubbing by the tile manager is a great idea, I have another one: delete all tiles from the image that are completely obscured by higher layers. After all, like the color information in transparent pixels, these tiles do not contribute anything to the final image, so it seems very reasonable delete them. Also I suggest that a good random number generator is used to decide when these tiles are deleted :) greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
(soz if you get this multiple times, it hasn't turned up after ~24h) Sven Neumann wrote: looks very sane overall and I couldn't find any obvious design mistakes. There is one thing that is already halfway implemented in *cough* - completely implemented IIRC in respect to what it was originally intended for. :) the current system and that I'd like to see considered. I'm speaking of a way to have hints about the pixel data stored in tiles. Such a hint could for example state that the tile is completely transparent, that it is fully opaque or even solid-colored. We have this as tile-row hints since GIMP-1.2 but I think it would make sense to have such hints on the tile level as well. The cache system should probably know about these hints since it wouldn't make much sense to swap a solid-colored tile to disk since it can be regenerated faster than it could be swapped in. It's a reasonable direction, I think, but I have two comments: * It probably makes sense to detect whether a whole tile is transparent/solid/etc just-in-time when you're about to consider swapping it out (or dropping it down to a colder cache) instead of every time it gets dirty. IIRC the tile-row-hints stuff does this sort of stuff just-in-time too, at compositing time, so effort isn't wasted on the various sorts of tiles, transient or otherwise, that never end up getting composited (but I'm an old man and my memory is getting hazy; I'd forgotten that the tile-row-hints stuff even existed and I should bloody well know). * For about a billion years I've been quite keen on the idea of lazily strong-hashing dirty tiles into a gimp-global hash table and collapsing multiple tiles with the same hash. There are so many hoops to jump through to make sure that the existing copy-on-write framework can actually be used in certain situations, mostly boiling down to having to use a central drawable-copy function that knows when it's possible to COW. Of course, plenty of GIMP's operations don't/can't use this function but still yield data that would in theory be COW-able. The idea of rehash-on-dirty would be to catch identical tiles, even accidentally-identical tiles (like great masses of transparent tiles, presuming that you scrub the RGB data of a transparent pixel; the row-hints stuff has been doing this and potentially breaking the ill-advised anti-erase feature for 100 years now and no-one has complained), that the normal COW routes miss. Since I suck, I don't have time to implement... stuff. But these are probably fun beginners' core-hacking projects. --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
Hi, Daniel Rogers <[EMAIL PROTECTED]> writes: > What I am going for here is a request for comments. I spout some > ideas about how I think how tilemanagement would be done, and those > people that actually have to deal with tile management tell me how I > might improve things. looks very sane overall and I couldn't find any obvious design mistakes. There is one thing that is already halfway implemented in the current system and that I'd like to see considered. I'm speaking of a way to have hints about the pixel data stored in tiles. Such a hint could for example state that the tile is completely transparent, that it is fully opaque or even solid-colored. We have this as tile-row hints since GIMP-1.2 but I think it would make sense to have such hints on the tile level as well. The cache system should probably know about these hints since it wouldn't make much sense to swap a solid-colored tile to disk since it can be regenerated faster than it could be swapped in. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] caching considerations in gegl
I am trying to help design an api for tile management in gegl. What I am concerned about is designing the api to be flexible enough to allow future changes to the swapping, caching and tiling code without placing limitations on how to best go about achieving this. What I am going for here is a request for comments. I spout some ideas about how I think how tilemanagement would be done, and those people that actually have to deal with tile management tell me how I might improve things. At the moment, I know very little about how gimp uses tiles (though a pretty good understanding of how it caches and swaps). Here are the ideas I am starting with. Please tell me where I should be concerned that I am limiting a potentially useful feature of tiling, something you think should or should not be exposed about the tiling system, or any ideas about how the tiling system should work. I am hoping here to rely on the vast collective experience of the gimp developers, rather than trying to forsee everything myself. Also, as of yet, there is not code to back up these ideas. I am just trying to make sure I am not being too short sighted before actually trying to make this work. Here be my ideas: There should and an Interface (the gobject kind) that defines the api of an object that is swapable (call it GeglSwapable) and a similar interface for things that are cacheable (GeglCacheable). I don't see why non-cacheable things should be swapable, so GeglCacheable should be a pre-requisite of a GeglSwapable. An object that conforms to GeglCachable would know how to inform an inquisitive Cache implementation of potential future requested elements. How to attach itself to a particular cache manager, and how to check that it's data is avaiable in the cache before trying to get it from some real source. An object that conforms to GeglSwapable should know how to flatten and free it's swapable data when asked to, and how to unflatten and restore whatever state it handed off. A GeglTile would be a continuous allocation of memory that represented some portion of a two-dimensional area of data. A GeglTile would be an abstraction below a Channel. Channels should behave (behind a hopfully well designed api) as a continuous block of 2 dimensional scalar values. This demands that Channels have iterators that allow one to advance by scanlines in either direction (x or y) and to pull element by element, values from anywhere in the Channel, as though the entire channel exsisted in memory. GeglTiles (or some parent object) would also be the thing that implements GeglSwapable and GeglCacheable. A CacheManager would need to know how to fetch things from the cache, put new things in the cache, expire old things from the cache, and request that the swap manager swap out stuff. A SwapManager would need to know how to fetch from disk, keep track of unused chunks of disk space, and restore things from the disk. Here is a summary of the demands of the api that I of expounded on above: GeglCacheable attach_to_cache_manager() get_prioritized_list_of_predictions() fetch_from_cache() expire_from_cache() add_to_cache() add_to_cache_maybe() GeglSwapable flatten() unflatten() swap_out() swap_in() swap_maybe() GeglTile gpointer data GeglTile* left GeglTile* right GeglTile* up GeglTile* down GeglTile* top_left GeglTile* top_right GeglTile* bottom_left GeglTile* bottom_right GeglChannel GeglTile *top_left get_x_scanline_iterator get_y_scanline_iterator get_pixel(x,y) set_pixel(x,y) GeglChannelIterator next_x() next_y() current_x_position current_y_position Now that I have stated such a mouthful, I am getting other ideas that might be appropriate. It may be more meaningful to Let GeglCacheManger really manage a stack of caches, which would cause an expiration from a higher cache to push the data to a lower cache. Then let GeglSwap and GeglMemCache take over and place GeglMemCache on top of GeglSwap (both of which would inherit a common interface). This would even allow special purpose cache architectures to be place above more general (and thus sometimes (always?) slower) architechtues. How well do these ideas fit the needs of the gimp programmers? -- Daniel S. Rogers ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
