Do more compressed PNG images take longer to load?

Question

When I create PNG files with very small disk size, I tend to wonder if the file size becomes less important than the time viewers would need to decompress the image. Technically that would be trivial too, but I've wondered about it for a long time. We all know that more-compressed PNG images take longer to compress, but do they take longer to decompress?

I don't know if this information affects the question, but I am wondering about this in relation to both icon-type files (which are small because they contain few pixels) and huge line-art files (which are small because they compress their pixels very effectively).

EDIT: In response to the answers I've been getting, I want to note that this is not strictly a network issue. Windows users might not notice this, but most icons used by the desktop environment are stored with PNG compression, and dozens of them need to be rendered when the system starts. The huge line-art that I referred to was mostly desktop wallpapers like the ones at http://simpledesktops.com/, but various posters, videogame resources, and other things could also fit that description.

Answer 1

Better-compressed images (i.e. with a smaller file size) should generally take less time to load than the same image with a larger size.

If you want to minimise the filesize when saving a PNG file, the sacrifice comes in the time it takes to compress the file.

The PNG compresses image data with DEFLATE (the same algorithm used in zlib and PKZIP). One way DEFLATE saves space is to encode recurring byte sequences by just providing a runlength, and an distance back to where it previously appeared in the stream. (e.g. A B C D E F A B C A B C D could be encoded as A B C D E F [3,-6] [4,-9]. (It could also encode it as A B C D E F [3,-6] [3,-3] D.)

The compressor has to use an algorithm to look for matching sequences before it can encode them. Algorithms vary, but many of them can be made to work harder or go faster using certain parameters. When an algorithm works harder, it might find more or longer matches, which usually result in better compression, but it will take longer to do it.

By contrast, the decompression algorithm is very simple and doesn't have to do much work - it just decodes the stream in a fairly linear fashion, and it doesn't have to search for matches because they are provided by the compressor - it just looks up the length/distance codes provided to it.

Generally, the fewer bits it reads in, the faster the PNG decompression is likely to be.

Answer 2

I ran a little experiment for you - Its not perfect, but it should give some insites into the scope of the problem.

I found a large PNG file online, opened it in GIMP and saved 2 versions of it - 1 with compression level 9 (very small) and 1 with compression level 0 (large).

The highly compressed file was 1.8 megs, the lightly compressed png was 4.7 megs. The image was something I grabbed off Google and was a picture of a star cluster.

I then wrote a script to convert the image from png to tif (on the assumption that TIF is a relatively uncompressed file format so quite fast) 200 times and timed the output. In each case I ran the script quickly and aborted it after a few seconds so any system caching could come into effect before running the full test, thus reducing the impact of disk io (and my computer happens to use SSD which also minimizes that impact. The results were as follows:

Converting the small file 200 times - 1 minute, 16.07 seconds
Converting the large file 200 times - 1 minute, 22.39 seconds

So a highly compressed file appears to be about 10 slower to decompress then a lightly compressed file.

But, this does not take into account the time taken to download the file. This will, of-course, depend on the speed of your connection, the distance to the server and the size of the file. If it takes more then about 0.5 seconds more to transmit the large file then the small file, then (on my system - which is an older ultrabook, so quite slow thus giving a conservative scenatio), it is better to send the more highly compressed file. In this case - this means sending 5.8 megabytes a second, which equates to - very roughly, 60 megabits per second - excluding latency issues.

Conclusion for large files - if you are on a lightly used LAN it is probably quicker to use the less compressed image, but once you hit the wider Internet using the more highly compressed file is better.

BTW, I'm rerunning the tests with 1000 iterations, I'll update my post once I have these numbers - I expect them to be pretty similar.

Answer 3

No, in fact all you need to do is pull up a 64 pixel png and a 64 pixel jpg to see how the time it takes to decompress is so infinitesimally minuscule so as to be inconsequential ... right before you realize that you've been spending way too much time thinking about this. :) Because we're talking about such small sized images involved in the pixels that make up an icon. As you ramp up the size the jpg as a lossy format is not going to preserve the image as well. That's where png as a lossless format really shines.

Technically speaking you're right about the fraction of the milliseconds performance improvement you'd get to bask in for not having to decompress a lossless format like png, it's just that fraction isn't likely to do you a whole lot of good because you're not going to be able to do anything with the time you saved. Jpg is only useful because it can still retain 90% of its quality at 64 pixels even though it sheds itself down to a small fraction of its original detail it's just too small to notice. PNG is nearly as expedient while its quality as a lossless format doesn't suffer at all, making it the far superior choice IMO.

Any pragmatic reason behind why you'd been pondering this for so long?

So it'd help to have a better idea of what you consider 'huge lineart files'if you had some legit question about where you were going with that.