Last modified: 2014-03-26 18:19:51 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
> > 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
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
Thanks a ton, Eduard. Just to be explicit, can you tell me what settings generated the 3 image variations?
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
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.
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
(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
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).
Thanks Eduard; on JPEG I commented at bug 51449.
(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)