Raphaël Quinet wrote:
On Fri, 12 Dec 2003 14:41:08 -0600, "Stephen J Baker" <sjbaker@xxxxxxxx> 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@xxxxxxxx http://www.link.com
Home: sjbaker1@xxxxxxxxxxx http://www.sjbaker.org
