If you need to reduce the size of a screenshot it's often better to keep it as a PNG and reduce the number of colors. 256 colors nearly always carries all the information needed without blurring the edges or the text. Often 128 or 64 is fine. Don't use dithering - it harms the compression ratio, so you may as well use a few more colors instead.

Often just applying lossless PNG optimisations using a tool like https://imageoptim.com/mac will sometimes save a large percentage, although it can take a minute or so for the tool to finish.

Just disable Zopfli which is the most time consuming compression method and typically they compress at an instant.

> (having a limited color palette)

With translucency and soft gradients everywhere I’m not sure how true that is anymore.

PNG should be just as good at gradients as it is at constant color: https://en.wikipedia.org/wiki/Portable_Network_Graphics#Filt...

It can encode the difference to the previous pixel either up or above (or some combination). In purely horizontal or vertical gradients that's just as efficient as encoding constant color (and in fact, the Wikipedia page shows an example). For gradients in other directions, it depends on how homogeneous the slope is (because it will zip the diff to the previous pixel, i.e. the slope).

Doesn't that example show that a 256-step gradient takes 256 bytes? A 256-step run of the same colour takes just a couple of bytes due to RLE, doesn't it? (Not an expert.)

I debated about adding "after the first row", but didn't (because it doesn't make sense for gradients in the other direction). Either way, both my and Wikipedia's point is that a simple gradient filling a 2D surface costs only a "1D amount" of bytes, which is going to beat JPEG (at "can still read text" levels of quality).

Wouldn’t that only work well with perfectly linear gradients? Translucency and dropshadows are usually based on Gaussian blur, so not linear at all.

The post mentions doing this through the UI (no need for the terminal command).

my bad