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!

It appears the issue is only for greyscale+alpha images. Plain greyscale images remain greyscale when fed through vips in my testing.

Actually, it appears that greyscale+alpha stay greyscale+alpha with vips.

The issue is that vips converts palate images into sRGB.