Bug 53658
| Summary: | FEGaussianBlur kernel size is slightly wrong | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> |
| Component: | SVG | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | Normal | CC: | krit, simon.fraser, zimmermann |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
Simon Fraser (smfr)
The spec <http://www.w3.org/TR/SVG/filters.html#feGaussianBlurElement> says:
if d is odd, use three box-blurs of size 'd', centered on the output pixel.
... if d is even, two box-blurs of size 'd' (the first one centered on the pixel boundary between the output pixel and the one to the left, the second one centered on the pixel boundary between the output pixel and the one to the right) and one box blur of size 'd+1' centered on the output pixel.
The kernelPosition() gets this wrong, since it it fails to subtract the center pixel for at least the (std % 2) case.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Simon Fraser (smfr)
For example with std==47, all three blurs should use dLeft = dRight = 23. Right now they use 23,24.
Dirk Schulze
(In reply to comment #1)
> For example with std==47, all three blurs should use dLeft = dRight = 23. Right now they use 23,24.
This means the even and the odd cases are wrong, since we dLeft + dRight should be std - 1. right? But IIRC, this gets balanced during the blurring, since we do not differ between the center point and the points next to this point. So, in a row, we just take 'std'-number of pixels into account. And that is what the spec means: dleft + center pixel + dRight - pixels. Can you check this please?
Dirk Schulze
I think this was fixed a long time ago.