14 ms·
The interesting part about PNG is that since it uses the DEFLATE algorithm, and only applies compression per row/line, with no awareness of relationships betwee
by wonkaWonka 11y ago
The interesting part about PNG is that since it uses the DEFLATE algorithm, and only applies compression per row/line, with no awareness of relationships between lines, is that in most cases, the effective compression is nearly the same as if you took apart each row of uncompressed pixels as an individual image, and took all those separate images and put them in a zip file.
Disregarding the cruft of headers and other file format overhead, there would be a direct relationship between the size of a PNG image, and the raw, uncompressed row-level data zipped up and handled in a similar way.
- devit 11y agoThat's wrong: PNG uses a predictor that potentially depends on the previous row https://en.wikipedia.org/wiki/Portable_Network_Graphics#Filtering https://en.wikipedia.org/wiki/Portable_Network_Graphics#Filt...
- jsnell 11y agoI don't think that's true. So first of all this whole article is essentially about the "filters" that are used to encode the data more efficiently based on the surrounding data, before it's passed to deflate. Basically compute some kind of a delta from the pixel compared to the pixel up of it, left of it, or a combination of the two, with the deltas generally compressing better than the raw data would have. That's already a big difference to compressing each row separately. Second, the deflate compression does not happen individually for each row. It happens individually for each IDAT block, but those blocks can be of fairly arbitrary size. Using a separate IDAT block for each row would seem very odd. (Can you even use filters in that case, or does the state reset with each new block?)
- deleted 11y ago[deleted]