Hi,

Daniel Rogers 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

(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

On Tue, 11 Mar 2003 09:46:49 +0000, "Adam D. Moss" 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

On Tue, Mar 11, 2003 at 01:07:21PM +0100, Raphaël Quinet wrote:

On Tue, 11 Mar 2003 09:46:49 +0000, "Adam D. Moss" 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

On Tue, 11 Mar 2003 09:46:49 +0000 "Adam D. Moss" 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

On Tue, 11 Mar 2003 16:38:13 +0100, Ernst Lippe wrote:

On Tue, 11 Mar 2003 09:46:49 +0000 "Adam D. Moss" 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

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.

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

On Tue, 11 Mar 2003 17:12:14 +0100 Raphaël Quinet wrote:

On Tue, 11 Mar 2003 16:38:13 +0100, Ernst Lippe wrote:

On Tue, 11 Mar 2003 09:46:49 +0000 "Adam D. Moss" 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

Hi,

"Adam D. Moss" 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

Hi,

Ernst Lippe 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

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 */

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

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

On Tue, Mar 11, 2003 at 05:13:43PM +0000, 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

On Tue, 11 Mar 2003 18:20:34 +0100, Ernst Lippe wrote:

On Tue, 11 Mar 2003 17:12:14 +0100 Raphaël Quinet 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

On Tue, 11 Mar 2003 18:55:33 +0100, "David Necas (Yeti)" wrote:

On Tue, Mar 11, 2003 at 05:13:43PM +0000, 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

On Tue, 11 Mar 2003 17:53:58 +0000, "Adam D. Moss" 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

Hi,

"David Necas (Yeti)" 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

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.

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

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

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

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 */

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)" 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

Hi,

"David Necas (Yeti)" 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

Raphaël Quinet (quinet@gamers.org) 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

sven@gimp.org (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

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

On Tue, 11 Mar 2003 20:05:39 +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?

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

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

Daniel Rogers (daniel@phasevelocity.org) 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

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

daniel@phasevelocity.org (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

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.

IIRC masked commercial clip-art intended for use in printed page layout is usually distributed in something like PSD or TIFF format with each distinct component of a photograph ready cut-out for you by its mask being placed in an auxilliary channel or 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...

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 */

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

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

On Tue, Mar 11, 2003 at 07:05:03PM +0100, Rapha

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

* Adam D. Moss [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.png 6836 - 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.png 2482

Daniel Rogers (daniel@phasevelocity.org) 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

On Tue, 11 Mar 2003 19:05:03 +0100 Raphaël Quinet wrote:

On Tue, 11 Mar 2003 18:20:34 +0100, Ernst Lippe 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

On Tue, 11 Mar 2003 17:08:43 -0800 Daniel Rogers wrote:

David Necas (Yeti) wrote:

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)

As Nick Lamb already noted, there is another good argument against pre-multiplied alpha: loss of precision. When you're using a single byte per color that could be a serious problem.

greetings,

Ernst Lippe

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

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 ]

Hi,

Jakub Steiner 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

On 21 Mar 2003 10:23:23 +0100, Sven Neumann wrote:

Jakub Steiner 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

Hi,

Raphaël Quinet 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

On Fri, 2003-03-21 at 10:23, Sven Neumann wrote:

Hi,

Jakub Steiner 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

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?

jimmac@ximian.com (2003-03-21 at 0124.53 +0100):

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.

Is not that what I did in script-fu long time ago using 1.2? The only problem I had is that script-fu was unable to add the entry to the L&C menu, but otherwise, it worked fine. The reason was that somebody wanted to edit the "alpha" cos a game used it as extra texture channel (reflections, iirc), and the best was to move the alpha to mask, work there, and then make it "alpha" again when saving as PNG.

GSR