[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 #17 from lars.sonchocky-helldorf at hamburg.de  2013-03-08 09:35:22 PST ---
(In reply to comment #16)
> 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.

Just an idea to get some precision in such a case (if just must use integer in that case). Multiply by some amount, do your calculations and divide back through the same amount. Example: 

your calculation:

204 / 5 = 40,8 --cut off decimal--> 40

your calculation with more precision:

204 / 5 --multiply by 10--> 2040 / 50 = 408 --round by adding 5->  413 --divide back by 10 --> 41,3  --cut off decimal--> 41

For your computations you would off course not take decimal values to increase the precision but hex values:

0xCC / 0x05 * 0x10 = 0x0CC0 / 0x05 = 028C --round by adding 0x08--> 0x294 --cut of half a byte--> 0x29 = 41 decimal

I hope you're not doing your calculations using 8 bit integers

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