Re: [Gimp-developer] Line spacing in Gimp 1.3 doesn't work...
Hi, I and I wrote: (2) The text tool is under heavy development and is not advertised and being fully functional. Use GIMP-1.2 if you need a working text tool. this should have read ... is not advertised as being fully functional ... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tile row hints (was: caching considerations ingegl)
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), that the normal COW routes miss. Hmmm... This is interesting. I didn't know that a side effect of the row-hints would be to discard the RGB data from fully transparent pixels. Of course, this makes sense and this is the right thing to do. But this also means that some plug-ins such as Noisify should definitely never use the invisible RGB data in any operation, because the results could be (very) different if some tiles are swapped out. See the discussion in: http://bugzilla.gnome.org/show_bug.cgi?id=72853 -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tile row hints (was: caching considerations ingegl)
On Tue, Mar 11, 2003 at 01:07:21PM +0100, Raphal Quinet wrote: 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), that the normal COW routes miss. Hmmm... This is interesting. I didn't know that a side effect of the row-hints would be to discard the RGB data from fully transparent pixels. Of course, this makes sense and this is the right thing to do. But this also means that some plug-ins such as Noisify should definitely never use the invisible RGB data in any operation, because the results could be (very) different if some tiles are swapped out. See the discussion in: http://bugzilla.gnome.org/show_bug.cgi?id=72853 Hm. Though I see the posibility to temporarily make some area transparent just to give some its parts nonzero opacity later as a useful feature, the rest of world obviously thinks otherwise ;-( Yeti ___ 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
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
[Gimp-developer] Re: caching considerations in gegl
[EMAIL PROTECTED] (2003-03-11 at 1828.24 +0100): 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... Would just antierase users be happy with layers masks? This feature is ignored a lot, and I think it does the same, you hide and unhide areas as you want, keeping the colour info. If yes, get rid of antierase. GSR ___ 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
[Gimp-developer] Gimp-python
Hi. Are there any plans to eventually include Gimp-python in the GIMP package? I would like to be able to do automation without having to learn Perl or Scheme. Thank you. -Greg Yasko ___ 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] Re: caching considerations in gegl
Would just antierase users be happy with layers masks? This feature is ignored a lot, and I think it does the same, you hide and unhide areas as you want, keeping the colour info. If yes, get rid of antierase. GSR Or, as I suggested in an earlier email, but I don't think was stated very clearly, implement anti-erase as a layer mask (whether or not the user can actually see the extra layer). -- 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: 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
[Gimp-developer] Re: Re: caching considerations in gegl
[EMAIL PROTECTED] (2003-03-11 at 1233.14 -0800): Would just antierase users be happy with layers masks? This feature is ignored a lot, and I think it does the same, you hide and unhide areas as you want, keeping the colour info. If yes, get rid of antierase. Or, as I suggested in an earlier email, but I don't think was stated very clearly, implement anti-erase as a layer mask (whether or not the user can actually see the extra layer). Could make sense, after all quick mask is a temp channel and fast ops from / to selection. GSR ___ 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] Re: caching considerations in gegl
On Tue, Mar 11, 2003 at 12:33:14PM -0800, Daniel Rogers wrote: Or, as I suggested in an earlier email, but I don't think was stated very clearly, implement anti-erase as a layer mask (whether or not the user can actually see the extra layer). If you want to implement anti-erase as a layer mask, then for antierase to be available, this layer mask (not shown to user) has to be present all the time (if not, the information needed for anti-erase would be lost). But how this situation differs from separate alpha channel -- except for storing the same data in a much more complex way than necessary? Or did I missed something? Yeti ___ 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] Re: caching considerations in gegl
David Necas (Yeti) wrote: If you want to implement anti-erase as a layer mask, then for antierase to be available, this layer mask (not shown to user) has to be present all the time (if not, the information needed for anti-erase would be lost). But how this situation differs from separate alpha channel -- except for storing the same data in a much more complex way than necessary? Because alpha is coverage. Zero coverage means there is nothing there. The pixel is not part of the image, there is no information conveyed by the pixel. It means literally that there is no coverage of this point in space. Also this pixel is not a sample of the image. What I mean when I say alpha is coverage is that alpha was modeled and incorparted into the forumlas we use as the amount that the image covers the pixels. This is a very real life, I just took a photo of something concept. The image it not equivilent to the pixels in this context. The pixels represent a digital sampling of the image. The real image has nigh-infinite resolution. To save space, we choose a sample size and fill in the color that is closest to what the image represents. Sometimes, though, especially when compositing, an average color per pixel is not good enough. You need a number that describes how well the pixel is covered. This is alpha as described by computer scientists. Now, alpha means transparency to most graphic artists, so this is how it gets used, and in most cases this is ok. But there is a big real world difference between partially obsuring a pixel with opaque objects and putting a piece of colored glass in front of a pixel, even though the result is usually the same when sampled as RGBA. Although back on the topic of anti-erase, I think that the only way to do anti-erase correctly is with another layer. Once alpha goes to zero, the pixel no larger part of the sampled image. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: caching considerations in gegl
On Tue, Mar 11, 2003 at 02:53:45PM -0800, Daniel Rogers wrote: Although back on the topic of anti-erase, I think that the only way to do anti-erase correctly is with another layer. Once alpha goes to zero, the pixel no larger part of the sampled image. OK, I could use alpha in a wrong sense, it's a matter of definition, and let's agree on yours (though I wonder how's called the object alpha==0 pixels are part of, because I can draw on them, unlike pixels outside layer boundaries, so they exist and are part of something). But then I, as a user, don't care about alpha, and what I really care about is transparency. So everything what was said can be repeated, only s/alpha/transparency/. My need for pixels retaining their properties even in invisible state didn't disappear. Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: caching considerations in gegl
* Adam D. Moss [EMAIL PROTECTED] [030311 23:38]: Guillermo S. Romero / Familia Romero wrote: Would just antierase users be happy with layers masks? This feature is ignored a lot, and I think it does the same, you hide and unhide areas as you want, keeping the colour info. If yes, get rid of antierase. One weak reservation I have (I mention it in case no-one else has considered it) would be that although layer masks are fine and beautiful and good, and XCF files are the one true GIMP intermediate-save working-format and they save fine and intact, one day you might be handed a (for example) raw .sgi file in RGBA and for some reason be expected to do the resurrect-colour trick, but to no avail. I'm keen on both: 1) No, really, don't expect me to do that. 2) The situation is unlikely anyway. its vector outline being placed in a path. I can't think of a reason for someone to be handed a foreign RGBA file known to not be pre-multiplied, and need to resurrect its RGB data (except out of curiosity). But... PNG files stored by GIMP (at least) have resurrectable data, If you've got blue compoany logo that is supposed to be used on the web as an image with transparency to make it blend into the background it would make sense to make the whole image solid blue, and only store the shape in the alpha channel. I did some testing wrt to compressed file size using png and here are my results (default options and compression level=9 with png), and the results suggest that for nitpicky size optimization of PNG images one would want to have acces to the RGB values of completly transparent pixels. (images are at http://hnb.sourceforge.net/.files/pngtest/ ) 0_alpha_is_black.png 7526 - bytes 0_alpha_is_blue.png6836 - bytes I also ran the files through pngcrush which recompresses png files by trying various strategies, (the rgb data of pixels with alpha==0 is unchanged) 0_alpha_is_blue_crush.png 5018 - bytes 0_alpha_is_black_crush.png 5162 - bytes and finally the file containing just the rgb data when the background is black: rgbdata.png2482 -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ 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] Re: caching considerations in gegl
David Necas (Yeti) wrote: OK, I could use alpha in a wrong sense, it's a matter of definition, and let's agree on yours (though I wonder how's called the object alpha==0 pixels are part of, because I can draw on them, unlike pixels outside layer boundaries, so they exist and are part of something). You can also extend the boundries of your image (resize it) and draw over way over there. The image program restricts the area you can draw as a convience but that doesn't mean you can't draw out there if you want to. But then I, as a user, don't care about alpha, and what I really care about is transparency. So everything what was said can be repeated, only s/alpha/transparency/. My need for pixels retaining their properties even in invisible state didn't disappear. I think that is an excellent point, and a big vote for using un-premultiplied images (in fact, the only vote for using unpremultiplied images) If this is a need of our users, then it is incorrect for the cache to scrub the color information of transparent pixels. This still leaves the problem about what to with convolutions. Convolutions have a well defined behaviour for specific alpha's. If alpha is zero, it doesn't contribute to the covolution. Consider this chain of events: max the alpha of a triangular area. Blur the image. un-erase the edge of the triangle You will now have a new area revealed that didn't have the blur applied. This may or may not be what you want. This is either another way to mask the operation of a blur (what you wanted), or an annoying bug where now you have to go back six steps to before your blur, un-erase, and go forward again. I think this is why people don't like the un-erase (it's ambigious). Please correct me if I am wrong here. Clearly you (and probably others) have a need to reveal previously transparent areas. Here is a potential solution. Unambigufy the tools. Define precisly when it's ok to discard the color information and when it is not. Instead of erase and un-erase have: erase: this deletes all color information (truly erases the pixel and removes all information in it). veil: this just increases alpha, preserving color information. un-veil: this just decreases alpha, preserving color information (this is the improved un-erase). When a pixel is totally veiled it is not affected by convolutions. I use the name veil to suggest a mask that isn't quite the same as the other masks. What other tools need to be unabigufied, if this were to be implemented. Is the scrubbing done by the cache the only thing that breaks unerase? -- 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, 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
