Re: [Gimp-developer] Handling of transparent pixels
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 [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Hi, Joao S. O. Bueno [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
PNG zeroing transparent pixels. Was.. Re: [Gimp-developer] Handling of transparent pixels
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 [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Mon, Dec 15, 2003 at 10:45:56PM +, Adam D. Moss [EMAIL PROTECTED] 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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
[EMAIL PROTECTED] ( 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 -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Consume Less, Live More ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
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 -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
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: [EMAIL PROTECTED] ( 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 - ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
[EMAIL PROTECTED] ( 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: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Stephen J Baker wrote: [EMAIL PROTECTED] ( 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: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Tue, Dec 16, 2003 at 07:51:13PM +, Adam D. Moss [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] ( 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 :). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet wrote: On Tue, 16 Dec 2003 10:31:29 -0200, Joao S. O. Bueno [EMAIL PROTECTED] 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? -- Codito ergo sum Roel Schroeven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On Tue, Dec 16, 2003 at 05:55:06PM -0200, Joao S. O. Bueno [EMAIL PROTECTED] 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. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
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 -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 Consume Less, Live More ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Raphaël Quinet [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
On 17-Dec-2003, [EMAIL PROTECTED] 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) -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 signature.asc Description: Digital signature
Re: [Gimp-developer] Updating Script-Fu scripts for GIMP 1.3+
On Wed, Dec 17, 2003 at 04:09:45AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: Script-Fu scripts? In the days of GIMP 1.1.x there used to be a script which aided in the updating of Script-Fu scripts from the 1.0 API to the 1.1/1.2 API but I don't see one in the 1.3 CVS copy of GIMP. This script still needs to be written. The header file gimpcompat.h is probably the best source of information about the changes to the PDB. If you talk about scm2scm, it's part of the gimp-perl distro and relatively straightfoward (no dependencies, it builds a tree of the script, runs some filtering operations and prints out the script again). If anybody wants to give it a try, I think modifying it for the 2.0 api might take about as long as modifying the scripts manually :) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
