Page MenuHomePhabricator

Filter effect Gaussian blur filter not rendered correctly for small to medium thumbnail sizes
Closed, ResolvedPublic

Description

The filter effect <feGaussianBlur> available in SVG specification (http://www.w3.org/TR/SVG/filters.html#feGaussianBlurElement) is often (or rather most of the time) not rendered correctly on all Wikimedia projects.

This is a known problem of librsvg (see https://bugzilla.gnome.org/show_bug.cgi?id=605875) but probably won't get fixed in the near future.

For some quite impressive examples refer to:

This bug severely restricts the possibilities of graphic artist on Wikimedia projects since it basically renders the Gaussian blur filter completely useless since the final rendering of the MediaWiki software is rather arbitrary and comes near to gambling in the end. However Gaussian blurring is heavily used in modern SVG images since it allows to create outstanding effects like 3D effects and superior shading.
Besides art created exclusively for Wikimedia projects, many free SVG images from other sources can't be used either since they are just not compatible, would need a lot of work to render correctly at all and wouldn't look nice in the end anyway.

Therefore it would be badly needed to either change the SVG renderer (maybe only for problematic SVG files?) or to finally fix the bug in librsvg (maybe consider http://strategy.wikimedia.org/wiki/Proposal:librsvg_development_funding ?)


Version: wmf-deployment
Severity: major
See Also:
https://bugzilla.gnome.org/show_bug.cgi?id=605875

Details

Reference
bz42090

Related Objects

StatusSubtypeAssignedTask
ResolvedMoritzMuehlenhoff
ResolvedMoritzMuehlenhoff
ResolvedKrenair
Resolved AlexMonk-WMF
Resolvedfgiunchedi
Resolved AlexMonk-WMF
ResolvedKrenair
Resolvedfgiunchedi
ResolvedKrenair
DeclinedNone
Resolvedmobrovac
ResolvedKrinkle
ResolvedKartikMistry
ResolvedKartikMistry
Resolvedbd808
InvalidNone
DeclinedNone
Resolveddduvall
Resolveddduvall

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 1:04 AM
bzimport set Reference to bz42090.
bzimport added a subscriber: Unknown Object (MLST).

Since librsvg seems rather unmaintained and there seems to be no interest on side of the Wikimedia projects to consider using an alternative library on problematic SVGs I went on and fixed the underlying bug in librsvg myself.

See https://bugzilla.gnome.org/show_bug.cgi?id=605875#c9 for the patch. Sadly over at Gnome bugzilla nobody seems to be maintainig bug reports for librsvg or implementing patches given there. Therefore it's stuck right now.

If there are any Gnome developers around maybe you could have a look at it?

Sorry guys, but this bug hits nearly every image that uses the Gaussian blur filter effect. This is a serious limitation for SVG creation!

Can we please include the patch I posted upstream [1] in our local copy of rsvg until bug 51555 is solved in one way or another?

[1] https://bug605875.bugzilla-attachments.gnome.org/attachment.cgi?id=229516

  • Bug 8566 has been marked as a duplicate of this bug. ***

This is finally fixed upstream!

librsvg 2.40.9 (just released) includes the fix. [1]

When / how can we get this for Wikimedia Wikis? Given the severity of this bug, it would be great to not have to wait until it's in the official Linux distro used on WMF servers...

http://apt.wikimedia.org/wikimedia/pool/main/libr/librsvg/

librsvg_2.40.2-1+wm1.debian.tar.gz 09-Jan-2015 09:46

https://packages.qa.debian.org/libr/librsvg.html

[2015-03-02] Accepted 2.40.8-1 in experimental (medium) (Iain Lane)

adding _joe_ since he built librsvg (2.40.2-1+wm1) per debian/changelog

This is fixed upstream ??? Awesome, this really was one of the biggest problems with librsvg so far.
I'm sure the SVG users of the site will be super glad with this.

Krenair added a subscriber: Krenair.

I think I made a mistake. Have been trying to deal with the ridiculous backlog on the Upstream workboard, because no one bothers to use it properly.

The upstream fix is in librsvg version 2.40.9 (which first needs to get packaged and shipped by the distribution running on WM servers).

@Krenair: Whoever created that board, "Patch merged" etc is so vague (in upstream? in WM downstream?) that I have no idea when to move cards anyway so I personally ignore it.

@Krenair: Whoever created that board, "Patch merged" etc is so vague (in upstream? in WM downstream?) that I have no idea when to move cards anyway so I personally ignore it.

I think it's probably supposed to be merged upstream. Would make sense. I didn't make it though. I think it should also include other upstream resolutions (e.g. Resolved, declined). Can we rename those columns?

I made it, and yes indeed Patch Merged was meant to indicate patch merged upstream. I figured we would add columns as we see need for them.

librsvg 2.40.9-2 is now in Debian testing. Is this enough to use it on Wikimedia servers?

Dvorapa raised the priority of this task from Lowest to High.Nov 22 2015, 6:46 PM
Dvorapa lowered the priority of this task from High to Medium.

BTW not happy this issue is marked as a low priority :/

Don't get too excited. Priorities are meaningless

BTW not happy this issue is marked as a low priority :/

Don't get too excited. Priorities are meaningless

I don't know, e. g. in GitHub issues the priority is sometimes really important.

As noted above, this issue has been fixed in the rsvg library we use to convert SVG images to PNG. To resolve this issue on Commons, our copy of the library has to be updated, which is tracked as T112421: Update rsvg on the image scalers to 2.40.16 (to solve several SVG rendering issues). There's nothing else to do here other than wait for that to be done, and verify that it was fixed afterwards. That task actually has seen some movement recently, please watch it for updates :)

That bug is fixed on the new jessie image scaler using 2.4.16 (tested locally, it's not yet pooled into the set of active scalers in production). I have scaled https://cs.wikipedia.org/wiki/Wikipedista:Dvorapa/P%C3%ADskovi%C5%A1t%C4%9B/Broken_SVG_file#/media/File:Silverwiki_Hires.svg on the new and the present image scalers and put the results at https://people.wikimedia.org/~jmm/svg/ :

new-1.png / new-3.png are the results with approx. 100 and 300 pixels on the new scaler
old-1.png / old-3.png are the results with the existing scalers

(The pixel sizes differ slightly to prevent hitting the cached results in favour of a fresh scaler run)

The trusty-based image scalers have now been disabled, so I'm marking this task as resolved.

@MoritzMuehlenhoff When could we await the fix to be in a release on Wikipedias (Czech)? In yesterday's MW release it wasn't (nothing changed). In the next one?

@Dvorapa This change is not a change in Mediawiki, but in the librsvg software component installed on the Wikimedia servers. As such, the change is already available on Wikimedia servers like Commons.

@MoritzMuehlenhoff I see, then it is only matter of time when it will arrive to other Wikis?

If any other Mediawiki installation wants to use the fixed version, it needs to install updated librsvg packages as well. For Debian jessie you can fetch the packages we use from https://people.wikimedia.org/~jmm/rsvg-backport-jessie/ and Ubuntu 16.04 provides recent enough packages as well. But maybe I'm misunderstanding you, are you referring to a specific file on Czech Wikipedia?

@MoritzMuehlenhoff I just want to fix this on Czech Wikipedia. The file is uploaded on Commons, but on the Czech Wikipedia the preview is still broken. This is the reason why we can't remake all our barnstars and badges on the Czech Wikipedia from PNG to SVG (it looks broken even if perfectly valid SVG 1.1 file)

@Dvorapa I see the files ok, please check your browser cache.

@jcrespo I see, thank you, it must be from today, because yesterday purging server and browser cache didn't help

@Dvorapa The confusion we are seeing here is probably a bit logical. The issues is fixed, BUT any image that is affected will have to be manually purged. You can easily do this, by going to the file description page on commons and added "?action=purge" at the end of the URL.