W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: [css3-background] Where we are with Blur value discussion

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 16 Jul 2010 13:17:16 -0700
Message-ID: <AANLkTinbgBUnzQzzJDxaXhArlg8d0D3Mc_SDEtWBnI4c@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, Simon Fraser <smfr@me.com>, Brendan Kenny <bckenny@gmail.com>, www-style list <www-style@w3.org>
On Thu, Jul 15, 2010 at 6:36 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> As a contribution to the discussion, here's a hand-rolled
> implementation of gaussian blur you can play with to get a sense for
> how exactly it works.
> http://www.xanthir.com/etc/blurplay/
> It appears that just halving the length gives a good sigma for lengths
> 40px or less, but that approximation gradually becomes worse as the
> blur gets larger (you gradually want something larger than half the
> length).
> ~TJ
> (By the way, I can see why gaussians are so sucky to work with.  I was
> getting detectable floating-point errors nearly the entire time, which
> were visible to the naked eye once the stdev topped 30 or so.  I had
> to contort my computations to keep decent accuracy.)

So, it turns out the errors weren't due to floating-point precision.
I hadn't realized that CanvasPixelArray takes an Octet instead of a
Number, and so I was losing a lot of precision due to the automatic
flooring that was happening.  Tweaking my algorithm slightly produces
ideal results with no contortions necessary.

Now, the relationship between stdev and blur length is clear.
Amazingly enough, if we define the length as "the distance from the
edge where it reaches 98% transparency", then the stdev we need to
produce that is just half the length.

Yup, just divide the length by 2 and you have the appropriate stdev to
feed the guassian.  This relationship holds basically perfectly all
the way from 0 to 100stdevs (that is, 0 to 200px blur length).  This
approximation eventually fails, but I don't know if that's an actual
divergence or just actual floating point errors finally catching up to
me.  I'd want to run this with some infinite-precision arithmetic to

So, we have a relatively easy specification - just say that the blur
must approximate a gaussian with a stdev of half the blur length.
Then we can put up a little bit of language defining ranges that the
approximation must fall within, which we were already planning on.

I'm gonna call this problem solved, then.

Received on Friday, 16 July 2010 20:18:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:37 UTC