W3C home > Mailing lists > Public > www-svg@w3.org > June 1999

[Fwd: Pre-multiplication of samples in Filter Effects]

From: Raph Levien <raph@acm.org>
Date: Wed, 2 Jun 1999 12:23:40 -0700
Message-Id: <199906021923.MAA10420@trust.cs.berkeley.edu>
To: www-svg@w3.org
Peter Graffagnino <pgraff@apple.com> wrote:
> These are good comments. The general rule is that for things that  
> manipulate color independent of coverage, premultiplication is not  
> convenient.  But for things that manipulate the image as a whole,  
> premultiplication is more natural.  For example, I disagree with the  
> analysis of the GaussianBlur case.  To correctly evaluate a  
[...]

Indeed, all such convolution operations in the Gimp are implemented by
going to premultiplied space, doing the operation, and going back to
separate-alpha space (which is the interchange format). In earlier
versions, this was not done, and we had lots of nice artifacts when
gaussian-blurring partially transparent white layers.

I would disagree that, in general, premultiplied alpha is a
significant loss of precision. Yes, when converting back to separate
alpha in the small-alpha case, roundoff errors get magnified. But when
you take that pixel and composite it over another pixel, you only get
an LSB or so of roundoff errors. For Web work, that should be
completely satisfactory.

Now, if we're talking about high-quality print applications, then 8
bits is simply not adequate. Going to 16 bits, premultiplied or no,
is the only way to go. My take on the draft is that it's not being
targeted for high-quality printing. Too bad; SVG has a lot of stuff in
it that would be great for that application. Maybe SVG2...

Raph

P.S. By way of introduction, I'm one of the Gimp developers and author
of the antialiased renderer for the Gnome canvas. I'm planning on
doing a full-fledged SVG implementation in the Gnome framework.
Received on Wednesday, 2 June 1999 15:16:51 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:17 GMT