Last modified: 2013-07-25 18:40:48 UTC
The default settings for Vips make a huge difference on performance and functionality (obviously), and we have reports of some functionality not being complete with the Vips extension (or VipsScaler itself). We should determine where exactly we want VipsScaler to be used in WMF production environments and where we want to fall back to imagemagick (the old/current way). We can start off conservative and add functionality as we go/feel comfortable.
I would suggest starting off, only scaling PNG files bigger than say 35MP. This would make it only affect files that essentially already don't work, and thus is unlikely to garner any criticism. (Technically the PNG scale limit is 50MP currently, but things start to get expensive a bit before that, and I think there are some images in the 35-50 MP range that run into memory limits, but don't quote me on that). Something like (untested): $wgVipsOptions = array( # Sharpen jpeg files which are shrunk more than 1.2 array( 'conditions' => array( 'mimeType' => 'image/png', 'minArea' => 3.5e7, ), ), ); Possibly also with the bilinear option (not sure about that)
Regarding PNGs: I'd favor this solution as for the problems discussed in bug 51400. When the scalers are fixed and optimum settings are found Vips can still be activated for smaller graphics. One question regarding JPGs: You apply sharpening depending on how much they are shrunk. Have you tried to use a continuous function for the amount of sharpening instead of discrete values at fixed steps (as also indicated in the source code comment above)? Without having done any tests I could imagine this would yield more consistent quality for all sizes.
I wonder if it should be enabled at all for jpegs. AFAIK we don't generally have problems with memory usage on jpegs (except for progressive jpegs, where VIPS doesn't seem to do any better)
(In reply to comment #1) > I would suggest starting off, only scaling PNG files bigger than say 35MP. Agreed. > Possibly also with the bilinear option (not sure about that) Jan: Can you comment on the bilinear aspect here? (In reply to comment #2) > One question regarding JPGs: > You apply sharpening depending on how much they are shrunk. Have you tried to > use a continuous function for the amount of sharpening instead of discrete > values at fixed steps (as also indicated in the source code comment above)? Let's think about this in a longer term bug for improving VipsScaler. Logged as bug 51449.
Brian or Jan: Could one of your propose the merge needed to enable VipsScaler (with the above settings) so we can get it reviewed and ready to merge before Thursday's deploy? Thanks!
Brian/Jan: Hi :-) Got something for tomorrow's deploy? Kinda need it in the next 13 hours :)
Change 74514 had a related patch set uploaded by Brian Wolff: Proposed settings for VIPS. https://gerrit.wikimedia.org/r/74514
(In reply to comment #6) > Brian/Jan: Hi :-) > > Got something for tomorrow's deploy? Kinda need it in the next 13 hours :) Hopefully not too late, but this is what I would propose. In my tests, bilinear made some pngs worst (ex File:Solar-system.png), and some pngs better. At this point it seems like it would be better off initially to enable it only for large pngs, with bilinear off. We could change it later if people want to do something different.
Given that the motivation is to allow direct display of reduced images in Wikis, as well as possible integration of a smooth scaler or navigator in the same original image (without needing to upload various derived images with reduced scale, and improve the quality of these thumbnails, VipsScaler should effectively be used for now only on large images. But I don't see why it should not apply to JPEG images (notably large panoramas, or high-quality facsimile or photos of artistic paintings or books, architecture, or biological species to inspect anatomic details, or aerial photographies and beautiful maps : PNG is not the best format, but may be we'll need support for WebP, which combines PNG and JPEG advantages including for lossless compressions; many high-qulity photographs are also in TIFF format, and we should support images formats that use more than 8-bit color planes, as they allow fine tuning to exchibit shadows or adapt them more easily for color blinds or for some rendering devices, notably for printing or display on various types of LCD panels). I also hope that VIPS correcntly handles the embedded ICCM color profiles, and that it will preserve the alpha channels (something missing to GIF and JPEG but present in PNG, and raw BMP images). May be viewers of Wikimedia sites should have an option to select the image format they prefer in their browser. The scaler should then be able to produce other formats than just PNG or JPEG (e.g. WebP saves them lots of bandwidth, notably for mobile users that don't benefit of flat rates for their data plan, and whose connection are frequently much slower than DSL and fiber accesses), according to capabilities reported by their browser or according to user preferences if they disable some formats causing problems for them (PNG, GIF and JPEG generally work, except the full alpha channels and color profiles in PNG). Another need is to allow rescaling any image to show only a fragment of it (by optional wiki parameters in the [[File:]]/[[Image:]] inclusion tag).
(In reply to comment #9) > > But I don't see why it should not apply to JPEG images Because we can already scale those without running out of memory with our current scaler.
Note that VispScaler has severe problems in its bilinear filter. Test this with this quality image: File:Rotonde Villette interieur.jpg Look at the strokes bordering the windows, and color artefacts on them. Applying the bilinear filter is MUCH worse than when it is disabled in the test wii.
Change 74514 merged by jenkins-bot: Settings for VIPS. https://gerrit.wikimedia.org/r/74514
Done. Thanks Brian.
