3 ms·
PNG should be just as good at gradients as it is at constant color: https://en.wikipedia.org/wiki/Portable_Network_Graphics#Filtering https://en.wikipedia.org/w
by MauranKilom 4y ago
PNG should be just as good at gradients as it is at constant color: https://en.wikipedia.org/wiki/Portable_Network_Graphics#Filtering 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).
- chrisseaton 4y agoDoesn'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.)
- deleted 4y ago[deleted]
- MauranKilom 4y agoI 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).
- tobr 4y agoWouldn’t that only work well with perfectly linear gradients? Translucency and dropshadows are usually based on Gaussian blur, so not linear at all.