Closed
Bug 776694
Opened 13 years ago
Closed 11 years ago
feGaussianBlur should blur as if pixels outside the filter region are transparent black
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
VERIFIED
FIXED
mozilla28
People
(Reporter: jwatt, Assigned: mstange)
References
Details
Attachments
(9 files, 1 obsolete file)
It seems like feGaussianBlur does not blur pixels at the edge of the filter region correctly. It should act as if there are pixels outside the filter region, and as if those pixels are transparent black.
Reporter | ||
Comment 1•13 years ago
|
||
This should have blurred edges, but instead they are sharp as if the feGaussianBlur didn't even exist.
Comment 3•12 years ago
|
||
Is there a reference for how the image should look if this bug weren't present?
Comment 4•12 years ago
|
||
This is how it looks on my machine with my changes. However, I am unable to determine if this is how it ought to look. It didn't render properly in inkscape. I then installed and checked against google-chrome and it looks slightly different (the blur seems more pronounced on chrome - the lines are not so clear).
Comment 5•12 years ago
|
||
The rectangle should be blurred at the edges. The filter region will clip half of the blurring.
See Safari/Chrome or Opera as well.
Comment 6•12 years ago
|
||
(In reply to O S K Chaitanya from comment #4)
> Created attachment 731558 [details]
> This is how it looks on my machine
>
> This is how it looks on my machine with my changes. However, I am unable to
> determine if this is how it ought to look. It didn't render properly in
> inkscape. I then installed and checked against google-chrome and it looks
> slightly different (the blur seems more pronounced on chrome - the lines are
> not so clear).
The blurring on Chrome might be a bit bogus. We had reports about dithering on blurred content. Your result seems to look correct.
Comment 7•12 years ago
|
||
If you look at http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/filters-overview-01-b.html you should see that the fillPaint and strokePaint blue boxes are not blurred at the edges. I think that's because of this issue.
Comment 8•12 years ago
|
||
(In reply to Robert Longson from comment #7)
> If you look at
> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/
> filters-overview-01-b.html you should see that the fillPaint and strokePaint
> blue boxes are not blurred at the edges. I think that's because of this
> issue.
They are blurred in the PNG. But this is a different issue IMO. Pseudo primitives can be of infinite size. And we still did not clarify if subregions clip the input or the output of a filter primitive (or maybe both).
For input clipping, the edges should be blurred, for output clipping they may shouldn't since fillPaint/strokePaint are of infinite size.
Comment 9•12 years ago
|
||
This is how the link above looks with my changes in the Nightly. If I assume that the difference in colour is to be expected, I still find that the nature of blur looks different in image on the left (svg) and on the right (png). Is that fine?
Comment 10•12 years ago
|
||
(The clipping of the top left corner of the second image and the left edge of the first one happens even on the release version of Firefox on my machine and with a vanilla nightly build too.)
Comment 11•12 years ago
|
||
I think what you'e got is right then. The clipping seems to be an unrelated bug.
You could also compare using Opera, or Batik's Squiggle as they both clip pixels this way.
Comment 12•12 years ago
|
||
Comment 13•12 years ago
|
||
Comment 14•12 years ago
|
||
Comment 15•12 years ago
|
||
I have added renders from Chromium-browser and from Opera for comparison and an attachment with a render from the nightly with my changes.
The current attachment is a render from nightly after applying my changes and then removing the 'scaledDivisor' optimisation (i.e just dividing by boxSize instead of using 'scaledDivisor').
If you look at the renders you will see that this one is quite similar to the renders from Opera and Chromium.
On the other hand, the render with the 'scaledDivisor' optimisation has strong edges visible near the innermost part of the blurred region. Also at the corners you will see that the whitish squares are more prominently visible in the version with the 'scaledDivisor' optimisation.
Given this observation, what do you folks think we should do?
(I tried to get a render from Squiggle but some bug causes it to not render when I zoom in.)
Comment 16•12 years ago
|
||
If you see the w3g test render from the nightly without 'scaledDivisor' opsimisation, you can see that the blur on the edges looks similar to the reference in this image.
In the earlier case (with the 'scaledDivisor' optimisation), it had a lot more 'white' in the edges.
Comment 17•12 years ago
|
||
You could post both patches but I imagine that going without an optimisation with visible effects is best as a first cut. We could always add in the optimisation later and then back it out if anyone complains.
Comment 18•12 years ago
|
||
I have implemented a fix for this bug and have also removed the 'scaledDivisor' optimisation since it causes easily perceptible difference in the resulting render.
Attachment #732379 -
Flags: review?(dzbarsky)
Comment 19•12 years ago
|
||
Comment on attachment 732379 [details] [diff] [review]
fix for this bug (after removing the 'scaledDivisor' optimisation)
You'll need a review from an SVG Peer: https://wiki.mozilla.org/Modules/Core#SVG
roc (Robert O'Callahan) wrote the ComputeScaledDivisor optimisation. Jonathan Watt created the bug and I've shown some interest here so we're all reasonable choices for this. Let's see if Jonathan wants this?
Do you have tests? If so could you attach them to the patch? If not we really ought to have some.
Attachment #732379 -
Flags: review?(dzbarsky) → review?(jwatt)
Comment 20•12 years ago
|
||
Ahh, sorry about that. My Bad!
I just looked at the log for this file and the last 3 revisions were by dzbarsky. So I marked him on the r? flag. From now, I'll ensure I am marking it to someone who is an SVG Peer.
Also on an unrelated note, if I wanted to bring a bug to someone's attention, what should I do? For instance, I wanted to have someone look at the comment I posted on bug#522866 but I don't know how to draw someone's attention to it.
Comment 21•12 years ago
|
||
I'll make some tests and attach those too.
Comment 22•12 years ago
|
||
Comment on attachment 732379 [details] [diff] [review]
fix for this bug (after removing the 'scaledDivisor' optimisation)
I found some issues while making test cases for this filter. Please ignore this patch. I'll commit another one after fixing the problems.
Attachment #732379 -
Attachment is obsolete: true
Attachment #732379 -
Flags: review?(jwatt)
Comment 23•12 years ago
|
||
I didn't realise when I made comment 17 that we already had the "scaledDivisor" optimisation. We shouldn't remove that in this patch, it should just do the region change. We could then consider removing the optimisation in another bug as they are different things.
Peers and module owners generally look at changes to bugs in their area whether or not they are subscribed. Just commenting brings things to our attention. If that doesn't work you could always tick the Need more information checkbox below, choose other and then add one of us.
Assignee | ||
Comment 24•11 years ago
|
||
The Moz2D blur filter has the behavior we want here, so this bug will be fixed by bug 924103.
Depends on: 924103
Comment 25•11 years ago
|
||
Fixed by bug 924103
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Assignee: osk → mstange
Target Milestone: --- → mozilla28
Comment 26•11 years ago
|
||
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0
Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0
Verified as fixed on Windows 7 64bit, Mac OS X 10.9.1 and Ubuntu 13.10 64bit using Firefox 28 beta 3 build.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in
before you can comment on or make changes to this bug.
Description
•