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
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

Attached:

(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)

Look at this strong example (reported on Commons) https://test2.wikipedia.org/wiki/Special:VipsTest?file=File%3AGilbert_Burnet%2C_engraved_by_John_Rogers_after_John_Riley.png&width=862&sharpen=0.8
This seems a bug of the default scaler, maybe T71155 related.