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

VERIFIED FIXED in mozilla28

Status

()

Core
SVG
VERIFIED FIXED
5 years ago
3 years ago

People

(Reporter: jwatt, Assigned: mstange)

Tracking

Trunk
mozilla28
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(9 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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

5 years ago
Created attachment 645056 [details]
testcase

This should have blurred edges, but instead they are sharp as if the feGaussianBlur didn't even exist.

Comment 2

4 years ago
I'll start looking into this one.
Assignee: nobody → osk

Comment 3

4 years ago
Is there a reference for how the image should look if this bug weren't present?

Comment 4

4 years ago
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).

Comment 5

4 years ago
Created attachment 731559 [details]
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.

Comment 6

4 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

4 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

4 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

4 years ago
Created attachment 731567 [details]
render of w3g's filters-overview-01-b.svg test with my changes

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

4 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

4 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

4 years ago
Created attachment 731674 [details]
filt3.svg rendered in Chromium

Comment 13

4 years ago
Created attachment 731675 [details]
filt3.svg rendered in Opera

Comment 14

4 years ago
Created attachment 731676 [details]
filt3.svg rendered by nightly

Comment 15

4 years ago
Created attachment 731677 [details]
filt3.svg rendered by removing the scaledDivisor optimisation from nightly

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

4 years ago
Created attachment 731681 [details]
the w3g test rendered with nightly without 'scaledDivisor' optimisation

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

4 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

4 years ago
Created attachment 732379 [details] [diff] [review]
fix for this bug (after removing the 'scaledDivisor' optimisation)

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

4 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

4 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

4 years ago
I'll make some tests and attach those too.

Comment 22

4 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

4 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

4 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

3 years ago
Fixed by bug 924103
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED

Updated

3 years ago
Assignee: osk → mstange
Target Milestone: --- → mozilla28

Updated

3 years ago
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.