Closed Bug 776694 Opened 10 years ago Closed 8 years ago

feGaussianBlur should blur as if pixels outside the filter region are transparent black

Categories

(Core :: SVG, defect)

defect
Not set
normal

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.
Attached image testcase
This should have blurred edges, but instead they are sharp as if the feGaussianBlur didn't even exist.
I'll start looking into this one.
Assignee: nobody → osk
Is there a reference for how the image should look if this bug weren't present?
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).
Attached image Reference file
The rectangle should be blurred at the edges. The filter region will clip half of the blurring.

See Safari/Chrome or Opera as well.
(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.
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.
(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.
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?
(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.)
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.
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.)
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.
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.
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 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)
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.
I'll make some tests and attach those too.
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)
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.
The Moz2D blur filter has the behavior we want here, so this bug will be fixed by bug 924103.
Depends on: 924103
Fixed by bug 924103
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Assignee: osk → mstange
Target Milestone: --- → mozilla28
Keywords: verifyme
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.