Last modified: 2013-07-15 18:48:05 UTC
Copied from [[COM:VP]] Unfortunately, there's a big problem with the thumbnailing of File:Shield of Trinity Aveling 1891.png. The current 595px thumbnail is a rather optimized 16bit grayscale+alpha image 82kb in size, while the 595px thumbnail under the new algorithm is a 32-bit RGB+alpha image 155 kb in size (or almost twice the filesize). It took about 6 years to get grayscale PNGs to generate grayscale thumbnails (one reason why some people still preferred GIFs for such images until relatively recently: File:Harleian Ms2169 St Mihell arms tricked original.gif etc.), and I would be quite disappointed to see such belated and hard-won progress suddenly be reversed at this point... AnonMoos (talk) 18:20, 13 July 2013 (UTC) ----------------- Note, we do store if a png file is RGBA or greyscale in img_metadata, so if we can't fix vips on this point, we could perhaps have it fallback to the old scaler for greyscale images.
Despite differentiating between grayscale and RGB, it might be well worth to consider to always reduce color depths to the minimum possible. As PNG supports arbitrary bit depths one can most efficiently store the information by creating a minimal color map. I have no idea how VIPS is working, if it supports something like that or if it could be implemented wit hreasonable effort. But this would greatly reduce file sizes and therefore server load and loading times for users.
Eduard: Is this something that is actually a blocker or is the current situation (no changes to the test system) ok for now until we get a fix out?
Regarding this bug, I won't say it's a blocker: It only produces unnecessarily large PNGs and nullifies previous attempts of users to optimize PNGs by cautiously reducing bit depth. It doesn't influence visual appearance, though. However I have general considerations regarding scaler quality (and I'd call those blockers). I wrote a little on that in the announcement on Commons already and I'll probably file a bug report with some test-cases this evening. Having that said: Is there any need for the pressure on the release date? There was only roughly one week between announcement and the planned deployment. Why not give people a little more time to test and to sort out bugs like the one discussed here? I mean we have a working scaler in place so I assume we do not need to immediately deploy VIPS now?
Thanks Eduard. (In reply to comment #3) > Regarding this bug, I won't say it's a blocker: It only produces > unnecessarily > large PNGs and nullifies previous attempts of users to optimize PNGs by > cautiously reducing bit depth. It doesn't influence visual appearance, > though. Great, good to know. Reducing priority of this specific issue. > However I have general considerations regarding scaler quality (and I'd call > those blockers). I wrote a little on that in the announcement on Commons > already and I'll probably file a bug report with some test-cases this > evening. That would be great, as I don't know of those issues (I read some of the VillagePump on Sunday, but I thought everything was reported thus far). > Having that said: Is there any need for the pressure on the release date? > There > was only roughly one week between announcement and the planned deployment. > Why > not give people a little more time to test and to sort out bugs like the one > discussed here? I mean we have a working scaler in place so I assume we do > not > need to immediately deploy VIPS now? The beginning of this change started before my time, but according to the VipsScaler extension wiki page (https://www.mediawiki.org/wiki/VipsScaler) the VipsTest page on test2.wikipedia.org has been around since December 2011 (I don't know what communication was made at that time, though). The purpose of changing to Vips for a subset of image scaling jobs is to reduce memory consumption (thus be able to scale larger images). So it isn't just a needless change, but a change to improve functionality. To be clear: the scheduled deploy doesn't *have* to happen if there are blocking bugs. The only one I see now is determining the file size limit for progressive jpegs (bug 51275). See bug 51370 for tracking the config settings for VipsScaler. Please do report any other issues you have so I/we can make a fully informed decision. Thanks!
