Why do PNG images have so much "extra" data?

[Jasoco]

Supposedly PNG files are very unoptimized and can be "crushed" very small when need be. So I decided to do some tests myself using a PNGCrush app called ImageOptim on OS X (A Windows/Linux/Mac app called Trimage is also available) and got some interesting results and some curious questions...

I took all the images (All PNG files) in my current platformer project and ran them all (Game assets, UI assets and everything) through the program and took a folder that was 1.7MB down to 118KB.



Now the question is why, how, and is this a bad thing? According to the documentation it's compressing the data stream in the file. Now when I think images and compression I think JPEG. But I don't want to think it's actually losing any image quality. I open the different versions in Preview or PhotoShop and they all look the same. No differences. Pixels all match. So why is PhotoShop creating such a bloated image? (One image is 29,111 bytes vs a crushed 986 bytes)

Then you have Löve which can also create PNG files from imagedata. I'm currently fiddling around creating an image editor for my game. (Partly out of boredom. Partly out of the dream to be able to create as many assets for the game from within the game itself.) So I save a file and it gets a different size as well. The same image as above comes out to 2,355 bytes instead. Nowhere near as big as the PhotoShop version, but not as small as a crushed one. Basically the code for saving a canvas to an image is as follows:

Code: Select all

local w, h = canvas:getWidth(), canvas:getHeight()
imageData = love.image.newImageData(w, h)
imageData:paste(canvas:getImageData(), 0, 0, 0, 0, w, h)
imageData:encode(filename)

Where filename is a file name with a .png extension. (Since 0.8.0+ encodes automatically based on the extension.)

Now if I run the Löve version through PNGCrush, I get yet another file size. 479 bytes. Which is smaller than the crushed PhotoShop version. Then if I crush it once more, it goes down to 472 bytes.

How is this possible without losing visual data? And how small can it go? And is it even worth doing? And if it's not really a big deal, is it a bad thing for Löve? Or does Löve not really care? And if a PNG can be made smaller, why doesn't Löve's ImageData:encode() function use a better compression algorithm?

[zorg]

PNGs uses (according to wikipedia, a two-stage compression method, first is filtering by prediction, then the second,) the DEFLATE compression algorithm, which is lossless, and is also used in zlib; it can have a setting from 0 to 9, where 0 is no compression and 9 is maximum compression (this i know from gimp).

Now, maybe love uses one preset for png exporting, which gives you one size, and you tested with others which give you other sizes.

The bigger the compression ratio, the slower the decompression, that's the only tradeoff, since it's a lossless algorithm.

[Jasoco]

Well the real question is if a PNG is going to look the same no matter what the compression amount is, why even bother having options? Just use the highest at all times.

[slime]

It will look the same - the main difference is in how long it takes to encode it.

[ivan]

I have used PNG optimization but only for websites.
On the web, one image may get requested a huge number of times
whereas with games it's only downloaded once
so the benefit is probably less significant.
It may be interesting to benchmark the loading times with
optimized vs non-optimized images in Love2D.

[airstruck]

You might also be interested in pngquant and pngnq. These convert pngs to 256 color indexed (like GIF), and can get some images even smaller, especially when used with something like pngcrush. Of course, images with more than 256 colors will suffer a loss in quality, but images with <= 256 colors will look the same. Caveat: the alpha channel is considered part of the color for indexing purposes, so for example an opaque white and a partly transparent white count as two different colors.

[SiENcE]

This is an interesting blogpost about formats and compressions. It might help to find the best solution.

http://joostdevblog.blogspot.nl/2015/12 ... 4.html?m=1

[pgimeno]

There is a way to check if there's loss of quality. With GIMP:

- open the two images in two different layers
- set the top layer to Difference mode (that layer mode is the absolute value of the difference, so if they are not equal it will be nonzero)
- merge down the layers or flatten image (the former will create a merged layer with alpha, the latter will remove alpha)
- apply the Threshold tool on the result, with lower bound 1, higher bound 255

After the Threshold, any pixels that were different will be white, and the rest will be black. I assume there will be some other way with Photoshop.

But as others have said, it's highly dubious that the data will vary; apparently PNGCrush doesn't perform lossy conversions. The PNG format supports a variety of filters that can be applied to each scan line to enhance its compressibility. But analyzing which filters provide the best compression takes time, resulting in a greatly increased compression time. For decompression, that's negligible: the filters are very simple (e.g. subtract the previous scan line from the current scan line before compressing, or average the previous neighbouring pixels and encode the difference between the pixel to encode and the result). libpng doesn't use a lot of sophistication for encoding, resulting in sub-optimal files.

Then the zlib library itself supports several compression rates (from 1 = least compression, fastest encoding to 9 = maximum compression, slowest encoding). I'd suspect that Photoshop uses a low rate. Photoshop doesn't seem to be very PNG-friendly, from what I've heard. Closed software companies tend to hate open software formats.

To sum up, it's not that it has extra data; it's that it has not-so-compressed data. The original image data is much larger than what you get with Photoshop.

[Jasoco]

This is all very interesting. I'm glad to know. I don't really think decode and encode time is really a big deal though with Löve. Unless I had a million images, which I don't, it doesn't seem my projects will ever take more than a millisecond or two to load every image. So I have no qualms with running all my images through PNGCrush when the time comes. Or using Löve's built-in encoder to save images.

[Beelz]

I may be wrong, but compressing a PNG mainly just strips the metadata and color adjustment profiles, essentially making it the equivalent of a GIF.