Last modified: 2014-03-26 18:19:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T53400, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 51400 - Improve quality of scaled PNGs with Vips for all sizes
Improve quality of scaled PNGs with Vips for all sizes
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
VipsScaler (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-15 21:45 UTC by Eduard Braun
Modified: 2014-03-26 18:19 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
HTML document containing various real world test-cases side-by-side (10.01 KB, text/html)
2013-07-15 21:45 UTC, Eduard Braun
Details
tarball of above comparision, for in case special:VipsScalar goes away (1.02 MB, application/x-tar)
2013-09-29 01:14 UTC, Bawolff (Brian Wolff)
Details

Description Eduard Braun 2013-07-15 21:45:09 UTC
Created attachment 12852 [details]
HTML document containing various real world test-cases side-by-side

While experimenting with the test page [1] I realized that for some PNG images quality of the new scaler was superior, for others much worse. Also checking the "bilinear" check-box yielded completely different results depending on content.

I therefore tried to find some sort of systematics by comparing the results for various real world examples (e.g. images used on Wikipedia, scaled to the size the are currently used in the respective articles). I created an HTML page including those test-cases side-by-side to be able to directly compare them (see attachment).

My results so far:

1) First of all: Is checking "bilinear" (or the URL parameter bilinear=1) on the test page actually activating bilinear scaling? Since in all my test-cases the "bilinear" version yields a very sharp result, with sharp edges and noticeable steps - something which should actually be avoided by bilinear scaling and isn't visible in any other image editing software I'm using when setting a bilinear scaler (e.g. GIMP). So, if the switch is not inverted for a reason, VIPS incorporates the worst linear scaler I've ever seen.

2) All test-cases have in common, that the old-scaler is always a bit smoother than VIPS (regardeless of bilinear setting) - maybe a bit too smooth.

3) While the old scaler does not always provide the best quality, it provides always an acceptable quality without any visual flaws. Nothing one could say off any of the VIPS scaler settings.

4) Choosing one of VIPS scaler settings is basically impossible. Sometimes "bilinear" looks better, sometimes worse. Sometimes there are serious visual flaws with "bilinear" enabled, sometimes there are serious visual flaws with it disabled.

I also gave some basic notes in the attached HTML document on the issues I see with every graphic. But porbably it's best if you have a look yourself.

In conclusion - judging from those test-cases - I'd still prefer imagemagick currently. I don't know how hard this is, but I'd say the scalers used by VIPS need to be improved before we can deploy them on the WMF Wikis. Otherwise we'd have to accept much worse quality in some cases which should only be considered if we really have serious performance issues currently (which I don't think we have?).


[1]  https://test2.wikipedia.org/wiki/Special:VipsTest
Comment 1 Bawolff (Brian Wolff) 2013-07-15 21:55:21 UTC
> 
> In conclusion - judging from those test-cases - I'd still prefer imagemagick
> currently. I don't know how hard this is, but I'd say the scalers used by
> VIPS
> need to be improved before we can deploy them on the WMF Wikis. Otherwise
> we'd
> have to accept much worse quality in some cases which should only be
> considered
> if we really have serious performance issues currently (which I don't think
> we
> have?).
> 
> 

Thanks for taking the time to put together those test cases. Vips is not an all or nothing thing. The files which are most of concern (performance wise) are PNGs > 35 megapixels, and especially those > 50MP. I think we should maybe enable it only on those files, at least initially. See bug 51370
Comment 2 Eduard Braun 2013-07-15 22:04:19 UTC
Yes, this surely would be a workable short-term solution. But in the long term it would be nicer to use VIPS exclusively if [1] comes anywhere close to reality. But not in it's current state I'm afraid...

[1] http://www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use
Comment 3 Greg Grossmeier 2013-07-15 23:12:52 UTC
Thanks a ton, Eduard.

Just to be explicit, can you tell me what settings generated the 3 image variations?
Comment 4 Eduard Braun 2013-07-15 23:53:52 UTC
You can just look at the HTML source (the images are directly downloaded from the WMF servers with the respective URL parameters).

The comparison contains:
1. Image as scaled by current default scaler (therefore imagemagick I assume)
2. Image scaled by VipsScaler - "bilinear" unset, sharpening set to zero
3. Image scaled by VipsScaler - "bilinear" set, sharpening set to zero
Comment 5 Greg Grossmeier 2013-07-16 17:48:01 UTC
Thanks (again) Eduard.

Re-titling the bug to reflect (I believe) the current state of things. Reduced the importance of the bug a bit to reflect the fact that we can move forward with using VipsScaler for large images but not all.
Comment 6 Bawolff (Brian Wolff) 2013-09-29 01:14:17 UTC
Created attachment 13400 [details]
tarball of above comparision, for in case special:VipsScalar goes away

Added a tarball, so that the tests above won't go away if our image scalar changes
Comment 7 Nemo 2014-03-26 17:38:48 UTC
(In reply to Eduard Braun from comment #0)
> I therefore tried to find some sort of systematics by comparing the results
> for various real world examples

Did you also note differences in sizes (bytes) of resulting thumbnails? That seems to be a concern now, at least for mobile (an increasing portion of our traffic):
https://www.mediawiki.org/wiki/Requests_for_comment/Reducing_image_quality_for_mobile
Comment 8 Eduard Braun 2014-03-26 17:59:07 UTC
My comparison and this bug is about PNG images. Since PNGs are lossless their quality and therefore their size can't be influenced (there are possibilities to optimize a PNG anyway but those normally don't make a huge difference).

Based on the different rendering the size of the resulting PNG thumnails differs also a little bit but nothing nothing notable I'd say and also nothing systematic (e.g. sometimes Imagemagick wins, sometimes VIPS).

I think there's not much to gain at this end (in contrast to JPGs).
Comment 9 Nemo 2014-03-26 18:14:08 UTC
Thanks Eduard; on JPEG I commented at bug 51449.
Comment 10 Bawolff (Brian Wolff) 2014-03-26 18:19:51 UTC
(In reply to Eduard Braun from comment #8)
> My comparison and this bug is about PNG images. Since PNGs are lossless
> their quality and therefore their size can't be influenced (there are
> possibilities to optimize a PNG anyway but those normally don't make a huge
> difference).
> 
> Based on the different rendering the size of the resulting PNG thumnails
> differs also a little bit but nothing nothing notable I'd say and also
> nothing systematic (e.g. sometimes Imagemagick wins, sometimes VIPS).
> 
> I think there's not much to gain at this end (in contrast to JPGs).

I think vips turns indexed pngs -> 8bits per channel pngs which can have a massive affect on file size (but only affects a small number of files)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links