Hi,

Raphaël Quinet writes:

One thing that has not been mentioned in this discussion so far is that there are two kinds of transparent pixels

Transparent pixels are transparent pixels. There are no two kinds of transparent pixels; that would be a strange concept to introduce.

2) For the pixels that have been obtained from an external source, then the "hiding" concept does not fit because the RGB data is undefined.

There is no such thing as undefined RGB data. GIMP doesn't use premultiplied data, so the data is always there and I don't think you can argue that it would be undefined.

- Some indexed formats (e.g., GIF) associate a default color with the transparent areas to be used by programs that are not able to handle transparency correctly. Note that nothing requires a GIMP plug-in to store this color in the image, because the GIMP supports transparency.

If such a background color is specified, transparent pixels should be filled with this color. Otherwise black seems like a good choice, but see below.

- Some other formats (e.g., RGBA PNG) store full RGBA data, so the transparent pixels may contain some RGB values. However, these values may be discarded by other image processing software or by tools such as pngcrunch. A GIMP plug-in could also discard the color of transparent pixels while loading or saving an image in order to improve the compression.

The RGB data can hardly be discarded, it can only be replaced with other data.

- In some other formats (e.g., WAD textures), the transparent pixels are simply not stored: they are defined as a number of pixels to skip in the current row or column, so there is not even a concept of "default color" for these pixels. In this case, the RGB values depend only on internal implementation details of the plug-in used to load the file.

We should probably set up a policy on how plug-ins should implement this then. The policy could say that transparent pixels should be left untouched (leaving it up to libgimp to initialize them) or alternatively be initialized to 0.

So the concept "alpha = hiding" does not work for case (2). In addition, even case (1) has some problems because sticking to that model would prevent the GIMP or GEGL from optimizing the memory usage by clearing and freeing tiles that are fully transparent (this would be useful if we want to implement layers that grow and shrink on demand, as requested in bug #93639 and bug #98776).

This is indeed an interesting point. Basically the only advantage that I could find in your concept so far but indeed a compelling one.

This is is why I was suggesting to remove the bug introduced by #127930 before it makes it into a stable release, and instead implement what I suggested in bug #128118. Beyond the next release, this is also why we should consider removing the "anti-erase" mode of the eraser tool in a future release and replace it by an undo brush. This would improve the quality of the GIMP and make sure that the users do not consider the alpha channel to be something that it cannot be (not always, at least).

I don't see why you want to limit GIMP in this way. It is an image manipulation program. Manipulation IMO includes being able to reveal the content of transparent areas. The information is there; why shouldn't the user be able to use it?

Sven

Raphaël Quinet (quinet@gamers.org) wrote:

Here is a long overdue and long-winded update to the discussion about editing the alpha channel and how transparent pixels should be handled...

Let me respond to this. I don't think, that your proposal is as urgent as you make it and I seriously believe that it has a fatal flaw.

One thing that has not been mentioned in this discussion so far is that there are two kinds of transparent pixels: those that have been made transparent during the current GIMP editing session, and those that were already transparent when the file was loaded from disk or obtained from a plug-in.

I fail to see why this is such a fundamental difference.

1) For the pixels that have been made transparent during the current editing session, one point of view could be to consider the alpha channel as a "hiding mechanism" that does not modify the RGB data. However, if the goal is to be able to un-erase some pixels that were accidentally made transparent, then an "undo brush" would be a more appropriate solution to that problem. So the concept of "hiding without destroying" is not really necessary if the same data can be retrieved from the undo history with the same convenience.

As you wrote: "However, if". While a undo brush certainly would be a nice thing to have, it certainly does not cover the same area as an anti-erase mode.

2) For the pixels that have been obtained from an external source, then the "hiding" concept does not fit because the RGB data is undefined. For the files loaded from disk, the RGB values of transparent pixels depend on the file format, on the programs that have previously processed the file, on the current implementation of the plug-in, etc. There are several cases:

[...]

So the concept "alpha = hiding" does not work for case (2).

So you basically claim that our uncertainity of what happens to the data outside the GIMP makes it impossible for us to work with that data inside the GIMP.

This is nonsense. We always had the general approach to empower the GIMP user to do non-obvious stuff. Right now we don't discard RGB-information when A=0 in the core, and stuff like Anti-Erase usually just works good for power users. The new Alpha-to-mask feature you are complaining about in #127930 works and empowers users to handle Tribes2 textures. The point that you perceive this as an abuse of the PNG format is irrelevant: PNG does not discard the RGB information by itself, and there is no point in preventing our users to use it.

In addition, even case (1) has some problems because sticking to that model would prevent the GIMP or GEGL from optimizing the memory usage by clearing and freeing tiles that are fully transparent (this would be useful if we want to implement layers that grow and shrink on demand, as requested in bug #93639 and bug #98776).

Right, we need to think about it, when we actually implement that fancy compression stuff. I'd love to know if layers really shrink automatically in Photoshop. When we implement this I certainly would let the user decide, if he wants automatic shrinking or not.

It is better to consider the transparent pixels to have undefined RGB values and to make sure that these RGB values are never exposed to the user (that would be a bug).

I strongly disagree here. Just because we cannot rely on external tools to handle the RGB information for A=0 in a consistent manner, that does not mean that we should prevent the usage of that information.

The user has to select the tools he want to use. And it is his responsibility to select his toolchain to handle that case in the way he wants to get it handled. Gimp should not artificially limit the way the user wants to interact with invisible information.

Other well-known programs have solved the problem of un-erasing pixels by introducing an undo brush. I would like the GIMP to reach or exceed the quality of these professional programs by making sure that the features are implemented in the right way instead of introducing new bugs.

Undo Brush can only work if there actually *is* an undo history. Since Gimp might get used together with external tools this is not always the case, making it necessary to have other ways to reveal potentially important information (for pixels where A was =0).

This is is why I was suggesting to remove the bug introduced by #127930 before it makes it into a stable release,

Let me emphasize this:

THIS IS NOT A BUG!

A bug is not defined as "might lead to unexpected results when used in a very specific manner".

and instead
implement what I suggested in bug #128118. Beyond the next release, this is also why we should consider removing the "anti-erase" mode of the eraser tool in a future release and replace it by an undo brush.

As mentioned above the scope of these two tools is not the same.

This would improve the quality of the GIMP and make sure that the users do not consider the alpha channel to be something that it cannot be (not always, at least).

This would severily impact the scope of the GIMP, since it would prevent its use in cases where the user knows exactly what the alpha channel is.

P.S.: I would also like to add that this discussion applies also to the pixels that are partially transparent, not only those with alpha=0. For a pixel with alpha=1, the only thing that matters for the R, G and B values is whether they are greater or lower than 128 because the result after composition would be the same.

This is when you assume "normal" composition mode. For other modes your argument breaks apart into pieces.

P.P.S.: In a comment added to bug #127930, Guillermo S. Romero mentions that some games such as Tribes2 use RGBA PNGs and store some information in the A channel that is not alpha (reflection effect), so it would be useful to be able to edit alpha directly. However, I disagree because this kind of abuse of the file format should be supported by a specific plug-in instead of adding unreasonable requirements to the GIMP core.

Since there is no such plugin and I somehow don't see you jumping up and implementing it and right now the GIMP core can handle that case just fine I don't see why we should restrict the user in that kind of operation.

To summarize:

Raphaël outlined where the treatment of A=0 pixels could lead to problems in the future (automatic layer shrinking), but I believe that these problems could be solved by exposing the policy to the user.

The Gimp core right now allows us to store RGB information in pixels where A=0 and retrieve them later. This is useful in some cases and thus must not be called a bug. In my opinion we should not limit the scope of the GIMP by imposing artificial restricitions on the User.

And please note that I'll go berzerk when I am no longer able to make A=0 pixels more opaque via the curves dialog.

Bye, Simon

Hi,

Raphaël Quinet wrote:

One thing that has not been mentioned in this discussion so far is that there are two kinds of transparent pixels: those that have been made transparent during the current GIMP editing session, and those that were already transparent when the file was loaded from disk or obtained from a plug-in.

Like nomis and Sven, I don't see there being any inherent difference here.

1) For the pixels that have been made transparent during the current editing session, one point of view could be to consider the alpha channel as a "hiding mechanism" that does not modify the RGB data. However, if the goal is to be able to un-erase some pixels that were accidentally made transparent, then an "undo brush" would be a more appropriate solution to that problem. So the concept of "hiding without destroying" is not really necessary if the same data can be retrieved from the undo history with the same convenience.

I don't follow your logic here. It is undoubtedly useful to consider an alpha channel as a way to hide data, therefore it is not necessary to modify data in the RGB channel when we modify the A channel.

In any case, masks and alpha channels are also used to hide data across sessions for several file formats (eg. png), and we have ven had a bug report against the GIMP
(http://bugzilla.gnome.org/show_bug.cgi?id=82882) because someone expected this behaviour from the tiff plug-in (apparrently this is provided by other programs).

2) For the pixels that have been obtained from an external source, then the "hiding" concept does not fit because the RGB data is undefined.

This is where we start to voilently diverge :) I disagree that this is the case. It may be considered to be the case in some specific circumstances, but in general, we should not destroy data, IMHO. Not destroying it means, inevitably, allowing it to be manipulated. Your suggestion amounts to pre-multiplying RGB by alpha regardless of the file format, and I consider that just wrong.

Beyond the next release,
this is also why we should consider removing the "anti-erase" mode of the eraser tool in a future release and replace it by an undo brush.

As a matter of interest, how would an undo brush work? I'm having trouble getting my head around the idea.

Cheers, Dave.

--
Dave Neary
bolsh@gimp.org

The value of the RGB of transparent pixels is crucial for applications involving realtime MIPmapped textures...pretty much all 3D games for example.

MIPmapping works by creating successively reduced resolution images - each (typically) half the resolution of the previous one.

When a MIPmapped image has alpha, this down-filtering produces semi-translucent pixels in areas of the image that were formerly completely transparent.

At these locations, the colour you see will be a down-filtered version of the higher resolution image.

It it therefore ESSENTIAL that the pixels in the areas outside of the opaque parts of the image can also be painted - and have user controllable RGB values.

What GIMP does now is just fine - what might be nicer would be some kind of toggle to temporarily show the entire image as opaque (without actually destroying the value of the alpha buffer).

If GIMP were to do something like (say) making all the transparent pixels be solidly black, you'd see a dark halo. This is a really common problem and GIMP is the tool that saves you.

----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

Hi Stephen,

Stephen J Baker wrote:

What GIMP does now is just fine - what might be nicer would be some kind of toggle to temporarily show the entire image as opaque (without actually destroying the value of the alpha buffer).

Raphaël will probably kill me for advertising a feature he considers a bug, but anyway... you can now do this by converting the alpha channel to a layer mask, and hiding the layer mask in the usual manner.

Cheers,
Dave.

Hi Raphael,

Raphaël Quinet wrote:

Well, I am still not sure about what was the real source of the problem mentioned in that bug report.

Quite simply, Photoshop (according to the bug submitter) does not pre-multiply RGB data by the alpha channel when saving, which allows the complete data to be retrieved afterwards. This is perhaps an option, but that was the origin of the problem. The submitter expected the GIMP to do the same thing.

According to the
second comment from the reporter, it looks like Photoshop is able to decode both types of images correctly (with and without pre- multiplication)

So do we - but at load time, we pre-multiplied the RGB values (as prescribed in the standard), so the behind-the-alpha data was destroyed.

Actually, without going into details, I think it could be considered correct to do this on save, but to read the data in the file as-is (that is, without pre-multiplication). That is, we assume that this operation was done by the application that created the image, and we read whatever's in the file. Part of the patch I attached to that bug would do this, if it were desirable.

so I suspect that the real problem comes from some exotic option that we (or libtiff) do not use and that would allow us to save the image with full RGBA information.

Nope - according to the latest tiff standard I could find, we're unequivocally doing the right thing on save.

It
may be an undocumented extension - TIFF is known to be full of these.

Ah - if you say so :)

Well, I'd rather be non-violent... ;) Of course, we should not destroy data if we have no good reason to do it. On the other hand, we should not lock ourselves in a situation that would prevent us from destroying this data if that could bring other advantages.

The fundamental rule that I thinkl we should follow is that modifying any 3rd party or user data should require an explicit action from the user (switching a toggle to optimize the image, for example, or toggling a preference to do alpha pre-multiplying, or somesuch). If the user does not request it, we should not touch his data just because we think that might be what he would expect.

Exposing internal data to the average user means that we would not be allowed to some of this internal stuff later.

Nonesense. Applications change their behaviour all the time - free software projects more than most. If we decide to provide features like layer auto-growing in the future, then we can do so. Saying that one 20 line patch will prevent us from doing something is just wrong.

Also, I do not consider the data we're talking about to be internal, or undefined. It is simply data which is not visible in the projection.

The undo brush sounds like it would be a nightmare to implement and get to act reasonably...

Cheers, Dave.

Raphaël Quinet wrote:

On Fri, 12 Dec 2003 14:41:08 -0600, "Stephen J Baker" wrote:

MIPmapping works by creating successively reduced resolution images - each (typically) half the resolution of the previous one.

When a MIPmapped image has alpha, this down-filtering produces semi-translucent pixels in areas of the image that were formerly completely transparent.

I don't follow your argument. Even the simplest downsampling techniques ("nearest neighbors", no linear or cubic interpolation) work by combining the weighted values of the pixels (all colors are weighted by their opacity). So the relative weight of a fully transparent pixel is zero, which means that if you are filtering four pixels (half resolution) and three of them are transparent, then the result will only have the contribution of the fourth pixel, with a lower opacity (1/4). The fully transparent pixels will not contribute to the downsampled result.

But that assumes that alpha is pre-multiplied into the RGB's - which is not the case for either DirectX or OpenGL's hardware texturing.

If my down-filtering (for MIPmaps) worked as you suggest then pixels with (say) 50% alpha wouldn't carry as much weight as they should.

So, no - we cannot do as you suggest.

The standard OpenGL MIPmap generator does not do as you suggest it should.

If GIMP were to do something like (say) making all the transparent pixels be solidly black, you'd see a dark halo. This is a really common problem and GIMP is the tool that saves you.

I don't see how this would happen, except if the downsampling filter would be incorrectly processing the R, G, B and A values independently (without weighting by A), which is obviously incorrect.

Well, it's not "obviously incorrect" unless you assume that RGB's are pre-multiplied by alpha.

Whilst I might be pursuaded that pre-multiplied Alpha was a good idea, I (and everyone else who works with realtime hardware) do not have a choice in the matter since that's how the API's are specified - and how the underlying hardware is implemented.

There is actually a GOOD reason to use post-multiplied alpha - and that is that pre-multiplying RGB by alpha destroys information that might come in useful later on. If you can choose to postpone the destruction of data - then that's generally a good thing to do.

If some other software has the same bugs as some of these plug-ins, I don't think that it is the GIMP's job to make sure that the software works despite its bugs.

But it's not a bug to choose to post-multiply alpha - it's a design choice.

I would argue that if GIMP were to uniformly support post-multiplied alpha, then any application that required pre-multiplied alpha could trivially fix it. However, for applications (including **ALL** realtime/interactive 3D applications) that absolutely must have post-multiplied alpha, giving us the data in the pre-multiplied form makes GIMP virtually unusable.

Please don't do this!

Of course we should not break it on purpose if we have no good reason to do it (i.e., if there is no other benefit in clearing the transparent pixels) but we should not be prevented from improving the GIMP even if that triggers some pre-existing bugs in some other software. We can implement specific workarounds if someone thinks that it is worth it, though.

I strongly implore you to retain post-multiplied alpha.

----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

On Mon, Dec 15, 2003 at 07:43:39AM -0600, Stephen J Baker wrote:

But that assumes that alpha is pre-multiplied into the RGB's - which is not the case for either DirectX or OpenGL's hardware texturing.

Both OpenGL and DirectX can handle premultiplied alpha just fine. Just use additive blending and off you go. :-)

The problem is of course that you lose a lot of precision when everything has to be stored in 8-bit-per-channel bitmaps after the multiplication.

The standard OpenGL MIPmap generator does not do as you suggest it should.

There is no "standard OpenGL mip-map generator". gluBuild2DMipMaps is a part of the GL Utility kit (GLU), not OpenGL, and it usually does its work in software anyhow (quite slowly, and with mediocre quality). You have an OpenGL extension (GL_SGIS_mipmap_generate IIRC) that does automatic filtering, but the exact filtering method is somewhat undefined.

/* Steinar */

Hi Raphaël,

I think everyone has more or less had their say on the thread - can I just sum up the salient points?

Raphaël Quinet wrote:

I agree. This is what the GIMP does and I was definitely not suggesting to change this, so I think that you misunderstood what I wrote. The GIMP will keep on using post-multiplied alpha in the future, and this is a good thing.

The whole point of this discussion was based on the fact that because we use post-multiplied alpha, there is some ambiguity about whether the average user is supposed to know and rely on the RGB values of transparent pixels. If we had been using pre-multiplied alpha, then there would be no reason for any debate, because all transparent pixels would have R, G and B = 0.

You believe that allowing the RGB data behind transparent pixels to be exposed might be confusing to some users - so far in the thread you are the only one who has asserted this.

You consider that in certain circumstances this behaviour could be considered a bug.

Others have stated that there are several applications where transparent data is stored across sessions, and that this data is indeed useful, and not at all undefined.

Personally I have stated that we should never destroy or modify data without explicit user action to that effect.

For the moment, unless I am mistaken, you are the only person to have stated that they consider the current behaviour wrt transparency flawed.

Can I propose, then, that we keep the current behaviour? Perhaps we could have a filter that pre-multiplies layers by their alpha channel? That would be trivial to write, and would address Raphalël's concerns, while staying true to the principle I outlined.

Cheers,
Dave.

David Neary wrote:

For the moment, unless I am mistaken, you are the only person to have stated that they consider the current behaviour wrt transparency flawed.

I'd just like to say that I somewhat agree with Raphaël. Using alpha for 'hiding' and unhiding is conceptually wrong, it's quite equivalent to letting the user take the saturation knob down to zero and then coming back later, turning up the saturation again and wondering where the original colours have gone. I've said it before: an RGBA pixel isn't just an RGB pixel with a handy auxilliary channel. Alpha is the glass you draw upon; it accumulates coverage of a certain colour, but the colour of the glass itself is undefined.

BUT, it's not the user's fault that GIMP hasn't really historically given this much thought, and has exposed tools and plugins which more or less pretend that the alpha channel is just another layer mask. The solution to just about all the 'I want my RGB data preserved orthogonally to the alpha in my file!' objections is to load and save the alpha as a layer mask, because that's precisely what people are wanting the alpha channel to be. That layer masks aren't quite as convenient to modify as alpha channels (that is to say, there isn't a tool that implicitly draws onto a layer mask a la eraser) is one of the reasons that people are going to keep abusing alpha. Right now probably isn't a good time to go crazy and change anything to accommodate (I'd still kinda like the deceptive anti-erase to go away, but don't mind stuff such as 'levels' working on the alpha channel on the understanding that it's a relatively power-user thing to do and that power-users understand that the resurrected RGB values of a 0-alpha pixel may not be as expected).

(For the record, there have existed in the GIMP core for years some optimizations that skip RGB processing for certain sections of completely-transparent image regions, which can cause -- albeit under conditions in which the user is least likely to care -- regions of transparency in a composited image to 'go undefined'. No-one seems to have noticed or at least cared yet.)

Regards, --Adam

Raphael, can I ask you a thing?

You could maybe just add (or ask someone to add) a "zero-out transparent pixels" on the layers menu.

This will make you possibly happy, and will NOT arbitrarily throw away data that is relevant to more than one group of users as this thread had shown.

Maybe, if you want to be really picky and selfish about this - there are far more usability issues in GIMP as it is now - them instead of a menu option one have to actively click, there could be added an entry in preferences. Something like "Automatically destroy color data from transparent pixels". Or some name equally "warnfull" about what it does.

With that, GIMP could be kept for Image Manipulation thats why we use it for.

However, I would agree that such an __option__ - to zero out data pixels - should be added to the .png save filter.

JS ->

Hi,

"Joao S. O. Bueno" writes:

You could maybe just add (or ask someone to add) a "zero-out transparent pixels" on the layers menu.

There's a perl script in gimp-perl which does just that: Image->Alpha->Clear Alpha

Sven

Ok, I managed to change my png plugin to handle cleaning out all transparent pixels.

What do you say? Is it interesting to go in right now? If it is a PNG recomendation, then it might be a nice add on, and it is small enough to go in even now, before the first pre-2.0.

a 640x480 pix image with a transparent hole of about half it's size got a 15% file size decrease.

I will polish my changes a little and submit the patch do bugzilla. If anyone wanna try it, just tell me now.

JS ->

On Tuesday 16 December 2003 10:31, Joao S. O. Bueno wrote:

Raphael, can I ask you a thing?

You could maybe just add (or ask someone to add) a "zero-out transparent pixels" on the layers menu.

This will make you possibly happy, and will NOT arbitrarily throw away data that is relevant to more than one group of users as this thread had shown.

Maybe, if you want to be really picky and selfish about this - there are far more usability issues in GIMP as it is now - them instead of a menu option one have to actively click, there could be added an entry in preferences. Something like "Automatically destroy color data from transparent pixels". Or some name equally "warnfull" about what it does.

With that, GIMP could be kept for Image Manipulation thats why we use it for.

However, I would agree that such an __option__ - to zero out data pixels - should be added to the .png save filter.

JS ->

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Patch submitted at bug 129472

I'll throw my opinion into the mix FWIW. I disagree with Raphael that RGB values for alpha=0 should be undefined. If alpha is subsequently adjusted, then the original RGB values must be preserved whenever possible so that the reduced transparency can be effected and produce the correct result. Therefore, in concept I don't completely agree with Rafael's comment that RBG values are undefined when alpha=0. Rather, the RGB values should be treated whenever possible to yield the proper result as if taking the limit as alpha approaches 0, rather than strictly stating that RGB values are undefined when alpha=0. This would provide the most useful and expected results, and greatest functionality for the user.

I am coming in late on this thread, and may have missed something, so please forgive me if my opinions are off the mark for some reason.

s/KAM

----- Original Message ---

On Mon, Dec 15, 2003 at 10:45:56PM +0000, "Adam D. Moss" wrote:

it's quite equivalent to letting the user take the saturation knob down to zero and then coming back later, turning up the saturation again and wondering where the original colours

To just throw in another personal opinion: The behaviour you describe wrt. saturation would be hilarious. It's even implemented that way in current gimp _until_ you say "OK". After which you have to (comparatively) clumsily have to re-adjust it.

Being able to change the saturation later by moving it up again would be rather desirable, even if it will not likely to be done that way for the next decade or so.

However, the "layer effects" people want is (in my eyes) exactly that: apply some saturation effect to a layer that you can later change without loss of fidelity.

mask. The solution to just about all the 'I want my RGB data preserved orthogonally to the alpha in my file!' objections is to

Orthoginality is a different argument (and can be rather valid, too). Tools in the current gimp don't work like alpha behaves. If you press OK, the old image is gone.

While I sometimes find the erase tool conceptually difficult to use (maybe because it's so unusual), the question is wether this is just a weird added feature (as most people including me _seem_ to view it), or something that hinders people.

Hi,

On Tue, 2003-12-16 at 17:59, Raphaël Quinet wrote:

Basically, the model that we should promote is: - layer mask => hiding mechanism, reversible - alpha channel => pixels that are cleared have undefined RGB data, not reversible (except for undo)

Breaking this model should be avoided, except in very special cases (i.e. obscure features for hackers).

I'm sorry, Raphaël, but I do not agree with you on this issue either. I don't see why we should limit the gimp when there is no, at least to me, obvious reason to do so.

I think you will have to accept the fact that this proposed change will not make it into gimp, at least not at this point in development. Allow me to refer to the minutes of the gimpcon meetings - http://developer.gimp.org/gimpcon/2003/minutes-1.html#decisions - where we agreed not to continue discussions just for the sake of the discussion. I think we have all had a chance to comment on the proposed changes at this point, and I suggest that we leave it be.

I actually think Joao S. O. Buenos patch to the PNG plug-in is a nice addition/work around the optimization problem - I have yet to try it out, though.

Sincerely,
./Brix

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

However, the "layer effects" people want is (in my eyes) exactly that: apply some saturation effect to a layer that you can later change without loss of fidelity.

And that'd be pretty groovy, and it'd work BECAUSE the layer effect is conceptually (and in reality) a separate processing step rather than an attribute of the data it applies to. This is precisely how I see the layer mask versus the alpha channel.

--Adam

Raphaël Quinet wrote:

I care about the message that we are giving to the user about the alpha channel: the correct way to present the alpha channel is that a pixel with alpha=0 has an undefined color. The GIMP should be free to keep the RGB data of transparent pixels intact or to destroy it if necessary. Hackers may be aware of whether the GIMP will keep the RGB data or not for such and such operation, but we should avoid adding features that explicitely require one or the other to happen.

Firstly, I'd strongly debate the idea that only 'Hackers' need that RGB data that's hidden by the alpha plane.

Anyone who paints textures to apply to 3D models is going to need those RGB values to be in good shape when the file is written out.

With the increasing prevelence of games that are user-customisable, I think an increasing proportion of GIMP users will care greatly about this feature.

Either way, having to keep a mental image of what operations will screw up my texture to the point of unusability and which ones will preserve it is not something that I could live with. I've been a user (and sometimes - author) of paint programs since the Quantel Paintbox back in the early 1980's - so I'm guessing I fit your idea of a power user.

IMHO, Alpha should be treated just exactly like R, G and B (or C, M, Y and K) are treated. I should be able to paint into the alpha plane (which is in effect what the GIMP eraser tool does).

I think the way that the alpha plane is treated as special is a large part of the problem here.

Basically, the model that we should promote is: - layer mask => hiding mechanism, reversible - alpha channel => pixels that are cleared have undefined RGB data, not reversible (except for undo)

Breaking this model should be avoided, except in very special cases (i.e. obscure features for hackers).

I don't think painting texture maps should be considered an obscure or special case undertaken only by deep guru's.

If you think of this as an operation that many of your users will be doing, your argument falls to the ground.

----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

While I sometimes find the erase tool conceptually difficult to use (maybe because it's so unusual), the question is wether this is just a weird added feature (as most people including me _seem_ to view it), or something that hinders people.

Oh yeah, I don't know if you simply made a typo, but 'erase' isn't a problem, while 'unerase' is. Not a 'your app will crash' sort of problem by any means, more a matter of exposing the user to implementation details and fluffy conceptual wrongness, actively encouraging the wrong tool (alpha) for the job (masking), and implying that 'undefined' data is sacred whereas it hasn't strictly been for a very long time now (and in some tools and usage patterns NEVER has been, but users don't even question these because the UI never encouraged these usage patterns).

--Adam

Actually, this will be quite possible with the "custom layer mode" I was cooking a couple months ago, and which I plan do revive to Gimp 2.2 ..
As an effect that applyes to the layer itself,like the "dissolve" layer mode, instead of on combinations, it is doable there.

One will just have to write the effect (if he's writiing from scracth, here will be a handfull of pre-made custom layer modes) ST=0; VT=V1; LT=L1 ,
to mean that targets HSV are set to zero, self, and self, respectively.

The RGBA values per pixel are kept unchanged by the Custom Layer Mode.

On Tuesday 16 December 2003 17:40, Adam D. Moss wrote:

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

However, the "layer effects" people want is (in my eyes) exactly that: apply some saturation effect to a layer that you can later change without loss of fidelity.

And that'd be pretty groovy, and it'd work BECAUSE the layer effect is conceptually (and in reality) a separate processing step rather than an attribute of the data it applies to. This is precisely how I see the layer mask versus the alpha channel.

--Adam

-

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

To just throw in another personal opinion: The behaviour you describe wrt. saturation would be hilarious. It's even implemented that way in current gimp _until_ you say "OK". After which you have to (comparatively) clumsily have to re-adjust it.

If the underlying data representation was HLS rather than RGB, doing this would not be ludicrous - it would be expected. OTOH, if the underlying representation WAS HLS then doing something like taking all the green out of the picture - then putting it back without affecting the hue would seem ludicrous.

While I sometimes find the erase tool conceptually difficult to use (maybe because it's so unusual), the question is wether this is just a weird added feature (as most people including me _seem_ to view it), or something that hinders people.

It's certainly unexpected - but it's useful.

I would rather hide that widget from Joe Public to avoid confusing him than to unnecessarily destroy valuable data.

Let me say this one more time: If GIMP produces truly undefined data where Alpha is zero - then GIMP will become utterly useless for painting texture maps for 3D graphic applications. That's DEVASTATING to a large number of your users.

----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

Stephen J Baker wrote:

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

To just throw in another personal opinion: The behaviour you describe wrt. saturation would be hilarious. It's even implemented that way in current gimp _until_ you say "OK". After which you have to (comparatively) clumsily have to re-adjust it.

If the underlying data representation was HLS rather than RGB, doing this would not be ludicrous - it would be expected. OTOH, if the underlying representation WAS HLS then doing something like taking all the green out of the picture - then putting it back without affecting the hue would seem ludicrous.

(Sorry - that should have been "...putting it back without affecting the RED would seem ludicrous.")

----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sjbaker@link.com http://www.link.com Home: sjbaker1@airmail.net http://www.sjbaker.org

On Tue, Dec 16, 2003 at 07:51:13PM +0000, "Adam D. Moss" wrote:

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

While I sometimes find the erase tool conceptually difficult to use (maybe because it's so unusual), the question is wether this is just a weird added feature (as most people including me _seem_ to view it), or something that hinders people.

Oh yeah, I don't know if you simply made a typo, but 'erase' isn't a problem, while 'unerase' is. Not a 'your app will

No, I was referring to the "erase tool" (actually "Eraser") since I was too lazy to check how the unerase option is called ("Anti-Erase" here). Sorry for making you guess.

I fully agree with what you say, othwerwise (I think :).

On Tue, Dec 16, 2003 at 05:55:06PM -0200, "Joao S. O. Bueno" wrote:

Actually, this will be quite possible with the "custom layer mode" I was cooking a couple months ago, and which I plan do revive to Gimp

Right, still I disagree in practise, and here is why:

While "it can be done" with the custom layer mode is true, the problem is not the implementation, but the user-interface. The model I was referring to (that is not going to be implemented too soon, if at all) would work somewhat like "whenever the user does something, the operation is added to the pipe/tree for the image. if necessary the user can revisit any stage of the tree and change parameters or insert new steps."

This poses a computing problem (it might be too slow/use too much memory for caching etc.) and also a UI problem (how can I make this accessible to the user in an easy way).

Incidentally, this is (in a pipe not tree way) how the display app of ImageMagick works, but it's often overlooked. I can resize an image as often as I want (and display will do it in LQ mode quickly for me), but only when I hit the apply menu will it actually resize the underlying image data, keeping highest possible (for imagemagick) quality.

One will just have to write the effect (if he's writiing from scracth,

The "just" is the problem. I can do it without custom layer modes, too, I just have to write the program.

Raphaël Quinet wrote:

On Tue, 16 Dec 2003 10:31:29 -0200, "Joao S. O. Bueno" wrote:

You could maybe just add (or ask someone to add) a "zero-out transparent pixels" on the layers menu.

[...]

I do not care (yet) about clearing the transparent pixels, destroying color data, using pre-multiplied alpha or all the (un)related things that were mentioned in recent messages.

I care about the message that we are giving to the user about the alpha channel: the correct way to present the alpha channel is that a pixel with alpha=0 has an undefined color. The GIMP should be free to keep the RGB data of transparent pixels intact or to destroy it if necessary.

Above you said "I do not care about [...] destroying color data", now you say that the GIMP should be free to destroy RGB data. No offense, but that does make it easier to misunderstand you. After reading many posts about this topic, I'm still not sure I understand what you are saying.

As far as I understand it, I disagree.

[...]

Basically, the model that we should promote is: - layer mask => hiding mechanism, reversible - alpha channel => pixels that are cleared have undefined RGB data, not reversible (except for undo)

Breaking this model should be avoided, except in very special cases (i.e. obscure features for hackers).

I *really* don't see why. The way I see it is that in general things should be kept orthogonal as much as possible, unless there are good reasons to do otherwise. In RGBA we have four values named R, G, B and A, and it is perfectly possible to change any single one of them without affecting the others. That's orthogonality, and it is a nice feature to have.

What is the advantage of RGB data suddenly being undefined?

Stephen J Baker wrote:

I would rather hide that widget from Joe Public to avoid confusing him than to unnecessarily destroy valuable data.

Let me say this one more time: If GIMP produces truly undefined data where Alpha is zero - then GIMP will become utterly useless for painting texture maps for 3D graphic applications. That's DEVASTATING to a large number of your users.

Let me be clear, and hopefully just one more time. As far as I'm concerned, we're never going particularly out of our way to willfully smash/destroy/eat/zero data belonging to a value that has that become undefined -- but for any number of reasons (mostly optimizations of some sort) it happens, and will increasingly happen in the future of GIMP as a pixel's VALUE becomes further abstracted from its REPRESENTATION (example: is your favourite 10,0,80 HSV pixel being passed between GEGL stages as HSV, XYZ, L*a*b* or RGB? That will depend, and you will never know).

The question is, should we expose non-power-user tools (one tool in particular, in my mind) that give the illusion that a pixel's raw byte representation is precious to the GIMP core? If your alpha channel is really a mask, use a mask. If your alpha channel is really an aux channel (i.e. specular index map), use an aux channel. If you are a power-user and willing to take your chances with alpha and particular power-user tools, know the risk and take your chances. If your favourite file-format plugin does not export and import alpha channels that are spec'd to contain non-destructive transparency data as layer masks, take it up with the author of your favourite file-format plugin.

GIMP will always be (utterly) useful for painting texture maps for 3D graphics applications, but if you want and need a TRULY orthogonal (in the colourspace sense) channel in which to put your decal mask (or other attributes) then put it in one of the various supported GIMP data channels which are better suited to this purpose, if you wish your process to be futureproof.

--Adam

Raphaël Quinet wrote:

You consider that in certain circumstances this behaviour could be considered a bug.

Yes, because presenting undefined data to the user should be avoided.

I mostly agree with you, but there are reasons for me wanting the feature implemented as the result of bug #127930. Here's my point of view of the situation.

Conceptually, I agree that alpha = 0 means that the RGB value of the pixel is undefined. Alpha = coverage; coverage = 0 means no pixel is there. Gone. Inexistent. On the other hand, mask = 0 does NOT mean that the corresponding pixel is inexistent, as we already agree (I think).

However both alpha and mask accomplish the same goal, i.e. opacity/transparency of individual pixels. Personally, the first time I saw it I found confusing and irritating to have two different elements for the same functionality.

Being the things as they currently are, the problem that I see is that you can use alpha to do things that you can't do with mask, and vice versa. I would really like them to be just one, the Alpha Channel, treated just as any other channel, but that's nearly impossible for a number of reasons. As they are currently implemented, the only way to be able to get the advantages of both is to implement some mechanism for converting one into the other and vice versa. There was already one direction, accomplished with "Apply Mask". The only missing one was the reverse, which is what bug #127930 addresses.

Now that I can convert from one to another and the other way around, I can take full advantage of both. I'm aware that this operation might expose undefined data, and I agree that there's some problem with that. Indeed I proposed an alternative implementation of #127930 in an earlier message that you haven't commented on, though now I doubt it's even useful. My current idea is rather to try to solve it by defining the guidelines for zero-alpha pixel handling as was mentioned earlier in this thread. In my previous message I suggested to specify them as undefined, but maybe it's not a good idea after all as you seem to defend.

I tried PS to see how it handles Alpha. I became quite frustrated. Once I deleted a part of the image and saved and reloaded it, I found *no* way of increasing the opacity of partially transparent pixels, not to mention totally transparent ones, except by painting. All adjustment tools had RGB but no A. Maybe it's just that I'm missing something because I'm not experienced with it but now I think that PS is not my kind of program.

But I have sometimes found myself needing to do alpha editing. Here's an example. I drew a closed figure in a layer and as an approximation I put a grayscale copy of it as a mask then I applied the mask (i.e. converted it to alpha) to continue work on it. I went on drawing; when working on the background I suddenly realized that there were small spots within the figure that were partially transparent and I wanted them fully opaque. The figure was complex; if I used the anti-erase I could neglect to opacize the whole figure. My alpha-to-mask script became very handy in that situation. With the threshold preview I could identify the spots that were not fully opaque and remove them.

As a final note, I've run into the same request from Gimp users for such a mechanism as the one implemented in Bug #127930 several times already.

Pedro Gimeno

On 17-Dec-2003, usr352@wanadoo.es wrote:

Conceptually, I agree that alpha = 0 means that the RGB value of the pixel is undefined. Alpha = coverage; coverage = 0 means no pixel is there. Gone. Inexistent. On the other hand, mask = 0 does NOT mean that the corresponding pixel is inexistent, as we already agree (I think).

Its only inexistant to the calculations. The RGB data doesnt go away, which is what I think you mean.

However both alpha and mask accomplish the same goal, i.e. opacity/transparency of individual pixels. Personally, the first time I saw it I found confusing and irritating to have two different elements for the same functionality.

Well, some image editors have alpha as a transparency mask, which is what would be better imho. Its better to visualize stuff this way.

Being the things as they currently are, the problem that I see is that you can use alpha to do things that you can't do with mask, and vice versa. I would really like them to be just one, the Alpha Channel, treated just as any other channel, but that's nearly impossible for a number of reasons. As they are currently implemented, the only way to be able to get the advantages of both is to implement some mechanism for converting one into the other and vice versa. There was already one direction, accomplished with "Apply Mask". The only missing one was the reverse, which is what bug #127930 addresses.

I think that all the alpha and transparency mask operations should be folded in to just doing transparency mask, and then alpha on load be converted to transparency masks.

Now that I can convert from one to another and the other way around, I can take full advantage of both. I'm aware that this operation might expose undefined data, and I agree that there's some problem with that. Indeed I proposed an alternative implementation of #127930 in an earlier message that you haven't commented on, though now I doubt it's even useful. My current idea is rather to try to solve it by defining the guidelines for zero-alpha pixel handling as was mentioned earlier in this thread. In my previous message I suggested to specify them as undefined, but maybe it's not a good idea after all as you seem to defend.

I tried PS to see how it handles Alpha. I became quite frustrated. Once I deleted a part of the image and saved and reloaded it, I found *no* way of increasing the opacity of partially transparent pixels, not to mention totally transparent ones, except by painting. All adjustment tools had RGB but no A. Maybe it's just that I'm missing something because I'm not experienced with it but now I think that PS is not my kind of program.

GIMP is exactly the same way. I have no way of doing alpha only operations, except when hacking up the transparency mask. My suggestion above would fix this. Colors are RGB, and Alpha is altered through the transparency mask.

But I have sometimes found myself needing to do alpha editing. Here's an example. I drew a closed figure in a layer and as an approximation I put a grayscale copy of it as a mask then I applied the mask (i.e. converted it to alpha) to continue work on it. I went on drawing; when working on the background I suddenly realized that there were small spots within the figure that were partially transparent and I wanted them fully opaque. The figure was complex; if I used the anti-erase I could neglect to opacize the whole figure. My alpha-to-mask script became very handy in that situation. With the threshold preview I could identify the spots that were not fully opaque and remove them.

As a final note, I've run into the same request from Gimp users for such a mechanism as the one implemented in Bug #127930 several times already.

Having to use anti-erase is a pita.

In addition to this, it should be possible to copy a transparency mask to a RGB layer, something GIMP doesnt support afaik. (Which, then, it would appear as a greyscale image)

On Tuesday 16 December 2003 21:44, Patrick McFarland wrote:

I tried PS to see how it handles Alpha. I became quite frustrated. Once I deleted a part of the image and saved and reloaded it, I found *no* way of increasing the opacity of partially transparent pixels, not to mention totally transparent ones, except by painting. All adjustment tools had RGB but no A. Maybe it's just that I'm missing something because I'm not experienced with it but now I think that PS is not my kind of program.

GIMP is exactly the same way. I have no way of doing alpha only operations, except when hacking up the transparency mask. My suggestion above would fix this. Colors are RGB, and Alpha is altered through the transparency mask.

Curves Tool,
It is the alpha manipulation per excellence, IMO.

Patrick McFarland wrote:

Conceptually, I agree that alpha = 0 means that the RGB value of the pixel

^^^^^^^^^^^^

is undefined. Alpha = coverage; coverage = 0 means no pixel is there. Gone. Inexistent. On the other hand, mask = 0 does NOT mean that the corresponding pixel is inexistent, as we already agree (I think).

Its only inexistant to the calculations. The RGB data doesnt go away, which is what I think you mean.

I mean "conceptually" as I emphasize in my quote above. It's never actually inexistant; there are bytes that hold values for R, G and B and the value of a byte is always defined and existant.

I think that all the alpha and transparency mask operations should be folded in to just doing transparency mask, and then alpha on load be converted to transparency masks.

That's equivalent to just use alpha and treat it as a channel just like R, G and B are, letting the user to paint in the channel, as I already suggested.

GIMP is exactly the same way. I have no way of doing alpha only operations, except when hacking up the transparency mask.

Wrong. You can manipulate the Alpha channel by using Levels, Curves, Histogram and even Threshold Alpha. The latter requires a separate plug-in, though, since the Threshold tool does not work with the Alpha channel even if it does with the R/G/B ones. And there's of course the eraser and its controversial counterpart anti-erase tools.

In addition to this, it should be possible to copy a transparency mask to a RGB layer, something GIMP doesnt support afaik. (Which, then, it would appear as a greyscale image)

Copy and Paste works in 1.3 for this task. In 1.2 you can Paste as New, then copy again in the new image and paste back in the original image.

Pedro Gimeno

Raphaël Quinet wrote:

But as you mention a "proposed change", I will just repeat that this discussion started because of a change that was introduced during the feature freeze and that is (IMHO) controversial and goes against the model that we should try to promote.

That's a point where we diverge. I've found some users telling me that sometimes they use Photoshop, sometimes Gimp, depending on what they're intending to do. That's because both do things in different ways. If we try to just clone Photoshop's features, we'll be always one step before it. I think that offering the feature in bug #127930 doesn't break anything to the user.

I was hoping that more
developers would see that the rest of the world around us (e.g., Photoshop) does things in the right way

That's not the right way in my opinion. If I want to make a certain shape look sharper in Photoshop, I can't use a tool like the central slider in the Levels tool in Gimp. Are you sure that that is the "correct" behavior?

and that we should not
introduce new features that have not be thought out carefully and that break this model

The model was already broken before the addition. Anti-erase, Curves, Levels and the plug-in-threshold-alpha with -1 arg hack can all be used to resurrect totally and partially invisible pixels.

Interestingly, the only new arguments (from Pedro, about Photoshop) are actually supporting what I wrote, even if Pedro does not like it.

That was not "the only new argument"; read my message again because it seems that you overlooked some.

My new arguments were:

- Photoshop does it (that's supporting your argument, provided that "others do it" means supporting your argument).

- There are things that can be done only by using alpha and things that can be done only by using layer masks (more on this later), and a means of conversion between them is desirable so that one can take advantage of both and not be limited by what can be done with the flavour he's using.

- I have found practical situations where I needed to edit the alpha channel, and the way that Photoshop does things wouldn't have helped me. I even gave an actual example.

- Other users have asked me for such a feature as the one implemented in bug #127930, so there's a real need for it in the users' side.

I actually think Joao S. O. Buenos patch to the PNG plug-in is a nice addition/work around the optimization problem - I have yet to try it out, though.

I haven't tried it either, but it could indeed be a nice addition to the PNG plug-in.

And what about the TGA and the TIFF and the formats? Isn't it better to
solve the issue in a more general way, so that the user doesn't get confused if such-and-such load plug-in doesn't include the option to load the alpha as a mask?

But alas this is far from solving the real problem, which is a problem of model/perception. The real problem is that some GIMP developers and users see alpha as a simple hiding mechanism, which is wrong (or not always right, depending on your point of view).

As Mask and Alpha are quite different things, are you saying that the Apply Mask option should be removed? Or the Create Mask as a Copy of Alpha option? Why should they exist in the first instance, if they're so different and so unrelated? (and why does PS have them?)

As this will be my last message in this thread, I would like to end it with a question (but I suggest that you do not respond - just think about it): Why do we need layer masks in the GIMP? Wouldn't it be easier to paint directly into the alpha channel and simply get rid of this intermediate step (mask)?

Quoting myself (as you seem to have missed it):

"I would really like them to be just one, the Alpha Channel, treated just as any other channel, but that's nearly impossible for a number of reasons."

Why were masks introduced in the first place?

mmm... because Photoshop had them? }:-)

Seriously though, I agree that they're conceptually different and for this reason they don't behave in the same way. This leads to what I already said: there are things that can be done only by using alpha and things that can be done only by using the layer mask. Which, in turn, leads to the need for some mechanism to convert one into the other and vice versa, addressed by bug #127930.

I'll just mention some of the things that come to my mind that can be done with Alpha but not with a layer mask:

- Use the Eraser as a quick way to hide pixels. With Mask, you have to select the mask, change to the Brush tool, change the current FG color (which you probably were using for other purposes), change the current brush (which you probably were using for other purposes), ensure that the brush options are suitable for the erase operation (or lose your previous settings which you probably were using for other purposes), then paint.

- Apply filters that behave consistently to their weighted R,G,B. The filters in the Distorts section come immediately to mind, but of course many filters are affected by the same reasoning. I've even found a filter (Curve Bend) that silently applies the mask before processing and keeps it applied even if cancelled. I consider that a bug, and I'm taking note of it for reporting it later, but it gives a clue on what the user (or the plug-in author in this case) would want masks to do but don't.

For the vice versa (things that can be done with a layer mask that can't be done with alpha), the best example is just to use paint tools on it.

My usual workflow is to always use alpha because it does what I need, except when I need to make some adjustments by hand. I used my alpha-to-mask script for that task before; now I don't have to.

I have yet to see a reasoned argument against this one, which is the one that led me to developing the partial patch for #127930, even knowing that it might lead to exposing undefined data just as Levels, Curves and Anti-erase can do so far.

The problem with our positions seems to be a "you should not" vs "there's no reason why you can't if you need to", applied to exposing conceptually undefined data. Note that the user does not necessarily expose it when he's focusing on what he's wanting to modify (it didn't happen to me when I did the modifications that I wanted in the example I gave). It can happen accidentally but I don't think that's an issue, given the gains obtained. Plus, undefined data can be actually defined data, given proper specifications and plug-in behaviour.

That's why one is not
encouraged to edit the alpha channel directly (there are ways around that if you know how to do it).

If PS has a way around that (I was unable to find it), why can't gimp have it too?

I hope that it is not too late to correct the mistakes made in the GIMP.

It's never too late *if* they are mistakes. Currently you and Adam seem to be the only ones in the thread who think so.

Pedro Gimeno

On Sunday 21 December 2003 18:37, usr352@wanadoo.es wrote:

Raphaël Quinet wrote:

(...)

I actually think Joao S. O. Buenos patch to the PNG plug-in is a nice addition/work around the optimization problem - I have yet to try it out, though.

I haven't tried it either, but it could indeed be a nice addition to the PNG plug-in.

And what about the TGA and the TIFF and the formats? Isn't it
better to solve the issue in a more general way, so that the user doesn't get confused if such-and-such load plug-in doesn't include the option to load the alpha as a mask?

Actually, all my patch does is to make avalilable an extra option on the PNG save dialog - a "save transparent pixel color values", which is true by default.

It is an extra do the PNG save that doesn't break any other thing, and give to the user control that would only be achievable by some maneuvers of making a selection based on the alpha channel, and zeroing the colors inside it, and which is useful, for instance, to make the file get better compression.

If it is found to be THAT useful, it could be moved to the GIMP preferences, but either way, each file format's save plugin would have to be changed to get aware of that. In any case this would be a Gimp 2.2 matter. (And I think BUG 129472 could be merged in just now, in time to the first pre-2.0 without breaking anything)

Regards, JS
->

On Tuesday 23 December 2003 20:10, usr352@wanadoo.es wrote:

In another message you wrote:

I was working, and noted that gradient fill is working poorly in CVS HEAD - the first color, or beggning of the first segment of the gradient, is taking up almost all the area to be filled.

Have you checked the Offset setting? It's supposed to do exactly that.

Like Homer would have said:
DOH!

Pedro Gimeno