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
