Last modified: 2014-07-19 20:13:21 UTC
The weight of JPEG thumbnails, while varying less than PNG thumbnails', is often a relevant factor in the loading times observed on random Wikipedia pages, even with a fast connection. It may be even more important for MediaWikis using larger thumbnails. https://github.com/mozilla/mozjpeg 2 was just released, see https://blog.mozilla.org/research/2014/03/05/introducing-the-mozjpeg-project/ and http://thenextweb.com/insider/2014/07/15/mozilla-releases-mozjpeg-2-0-facebook-tests-backs-jpeg-encoder-60000-donation/ for introduction, and should be relatively trivial to implement as "second pass" over JPEG thumbnails produced, right? I know that VipsScaler is currently only used by Wikimedia wikis for PNGs (and that it's named after Vips), but would such an optimisation be in scope for this extension? If not, should we instead upstream a request to include a jpgcrush-like functionality in Vips; or use some other way?
A second pass over existing jpgs would be quite destructive and introduce compression artifacts. This is only worth considering as a swap-in replacement for imagemagick when we want to generate jpgs. One point that the github page and the announcements make no mention od, however, is which input formats are possible. The sample images on github are bmp, jpg, ppm and txt. In that area I have a feeling that imagemagick won't be replaceable. Anyway, I think it should rather go in core, where the conversion to jpgs happens with the various encoders? Definitely worth exploring!
(In reply to Gilles Dubuc from comment #1) > A second pass over existing jpgs would be quite destructive and introduce > compression artifacts. Are you just giving this for granted, or is the consideration specifically based on tests and/or the algorithm they follow? (I didn't inspect either.)
> Are you just giving this for granted, or is the consideration specifically > based on tests and/or the algorithm they follow? (I didn't inspect either.) Any jpeg recompression is lossy, theirs included. Depending on the quality settings, you can get away with a few extra passes without necessarily causing a visual difference that people will notice, but if there's a straightforward way to avoid an extra pass, we should do it. I don't see the point of having an initial imagemagick conversion to jpg if it's going to be immediately followed by a mozjpeg pass, they both achieve the same goal. Ideally someone will hook up mozjpeg into imagemagick directly and it'll be one imagemagick option away.
(In reply to Gilles Dubuc from comment #3) > if there's a > straightforward way to avoid an extra pass I didn't hear of any. > I don't see the > point of having an initial imagemagick conversion to jpg Sure, that could be skipped, using Vips instead; that's why I filed this in VipsScaler.\ > if it's going to be > immediately followed by a mozjpeg pass, they both achieve the same goal. The goal of our "convert" commands is rescaling. > Ideally someone will hook up mozjpeg into imagemagick directly and it'll be > one imagemagick option away. Sure, that may take years. Which again is why I filed this in VipsScaler, created to work around some limitations of imagemagick in specific areas. :-)
Imagemagick's convert can do the rescaling/sharpening/color profile handling, while targeting an uncompressed format, and then mozjpeg would take care of the JPEG compression.
Just to clarify, Vips is an image scaling program, just like image magick. The main differences between vips and image magick is that image magick has more options/is more flexible, and vips has better performance characteristics (particularly memory usage on large files in some formats).
