Add conversion to 256 palette for PNG

[sergeevabc]

• source.png 144 512 bytes
• processed.png with &af&l=9 switches (maximum PNG squeeze via Weserv to date) 142 678 bytes
• let’s convert source to 256 palette via pingo.exe -palette=100 -sb -> out.png 46 214 bytes (and colors are still there!)

I would definitely use this mode for 99% of web graphics.

[kleisauke]

PNG quantization functions require libvips to be compiled with libimagequant, which is (unfortunately) licensed under GPLv3.

There's a possibility to use a version prior to v1.5.0, for e.g. by using this fork, since that version had a BSD-2 license. However, since image quantization is generally a time-consuming operation, it will require some research on our part to check if it can be added to the public API.

[sergeevabc]

Another approach to get PNG palette is vips.exe pngsave in.png out.png --palette --strip
The output is not that optimized as Pingo’s one, but it costs much less in terms of resources.

[kleisauke]

The palette flag requires libvips to be compiled against libimagequant, which is done in https://github.com/libvips/build-win64-mxe by using the fork mentioned above since v8.10.6.

As for this particular image, you could try to turn off filtering.

$ vips.exe copy note_ss_main1.png x.png[palette,compression=9,strip,filter=0,dither=0]
$ Get-Childitem -file x.png | select length

Length
------
 47072

See https://stackoverflow.com/a/66194787 for some background info.

[sergeevabc]

I see how to do it locally, but the issue is about processing it online via Weserv. :)

[sudofox]

This would be amazing. Quantization (when done correctly) can save an incredible amount of bandwidth.

[sudofox]

Bumpity bump bump I'm making another website and wanted to check on this... using the proxy to handle profile image URLs from a service that for some reason doesn't send cache-control headers or do quantization.