[Gimp-developer] Open Source myths
Hi, For those (like me) who rarely read slashdot and missed this: http://www.onlamp.com/pub/a/onlamp/2003/12/11/myths.html This is an article which sums up a number of myths about open source software, as well as talking about ways that some of them can be addressed. A number of these are relevant to the GIMP, I think. Of notable interest: * If the only way to learn the basics of a project is bug fixing, most developers won't bother * If the software is hard to install, most users will not install it * Being open source isn't enough to get new developers. * End users don't follow CVS Anyway - I thought it was interesting. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ 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 Fri, 12 Dec 2003 14:41:08 -0600, Stephen J Baker [EMAIL PROTECTED] 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: [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 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 */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
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, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using gimpwire
Shrinivas Kulkarni wrote: Can anybody point me to examples about how to use gimpwire lib? Hi Shrinivas, I don't know if there are any such examples outside GIMP cvs. Inside CVS, use of gimpwire is limited to libgimpbase/gimpprotocol.c, and that might be a good place to start. The functions in there are called from (among other places) app/plug-in/plug-in-message.c and libgimp/gimptile.c (which encapsulates most of the image data passing in the protocol). Hope this helps, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
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 -- 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
