[Webkit-unassigned] [Bug 111177] feGaussianBlur shows banding under certain circumstances

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=111177





--- Comment #16 from Florin Malita <fmalita at chromium.org>  2013-03-04 07:20:26 PST ---
(In reply to comment #11)
> (In reply to comment #10)
> > I'm pretty sure this is caused not by the gaussian blur per se, but by the lookup tables used to apply gamma conversion after filter application.
> 
> I take it back -- in this case, the LUT application accentuates the problem, but does not cause it:  the colors are still non-monotonically increasing, even with color-interpolation-filters="sRGB".

Yes, the trace above is a direct dump from the filter effect buffer.

> Interestingly, the problem still seems to occur if you use a stdDeviation of "50 0", which should eliminate the Y pass of each blur in the Skia implementation.  This suggest to me it's not the fact that it's a separable blur.

I'm not too surprised: in my testing I had changed the implementation to a single pass box blur in order to isolate the problem, and under those conditions a X-only or Y-only pass was not enough to trigger it. But if we're doing all three passes it's more likely for this to happen even with a one-dimensional stddev.

> I'm still a little confused as to how we're getting alpha values introduced at all in this case, but that's probably just my lack of SVG-fu.

Just from looking at the implementation, we're box-blurring all channels independently - including alpha.

I'm quite convinced now that this is just a precision issue. With the original test, the fill color is solid #cccccc. So we're blurring 0->0xcc edges for RGB, and 0->0xff edges for A => this yields a difference in rounding, and introduces enough variance in the (R,G,B)/A ratio to break the monotonicity of the composited values. I've plugged the numbers from that trace in a spreadsheet to better illustrate this: https://docs.google.com/spreadsheet/ccc?key=0AmPAhmQe58QjdHpMVjFkLXRXU3JFbG1kWXZ1Sjkzb0E

For example, consider a kernel of 20% coverage. Then for alpha we get 255 / 5 = 51, with 0 rounding error. For R/G/B we get 204 / 5 = 40, discarding 0.8 in flooring. Now suddenly our blur result is somewhat darker than it should be, and if the rounding stars also align when compositing, the composited result is also darker.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.