When to use PNG or JPG in iPhone development?

Question

I have an app that will display a bunch of images in a slideshow. Those images will be part of the bundle, thus distributed with the app.

All the images are photographs or photographic, etc.

I've read that it's preferred to use PNG as the image format, but seeing that the JPG version will be much smaller, I'd rather be using that.

Are there any guidelines which format to use and in which case?

Runagate

I wanted to add that the original images are all in JPG format already if that makes any difference. – Runagate

Answer 1

PNG's are pixel perfect (non-lossy), and require very little extra CPU energy to display. However, large PNGs may take longer to read from storage than more compressed image formats, and thus be slower to display.

JPG's are smaller to store, but lossy (amount depends on compression level), and to display them requires a much more complicated decoding algorithm. But the typical compression and image quality is usually quite sufficient for photos.

Use JPG's for photos and for anything large, and PNG's for anything small and/or designed to be displayed "pixel perfect" (e.g. small icons) or as a part of a composited transparent overlay, etc.

Tomtom

I've yet to see any data on JPEG vs PNG vs iPNG decode performance. Sometimes the more-compressed format is better due to reduced I/O required; I'm not sure how fast the iPhone's flash drive is. And I definitely wouldn't say PNG decompression requires "very little" energy; the Other.artwork file appears to be raw bitmap data, presumably because the CPU/memory overhead of PNG decompression is too much for commonly-used UI components. – Effectually

On my current project, we have very large png files because of a transparency requirement. The disk IO greatly outweighs the time spent decoding a jpeg. Keep in mind PNGs are compressed also, just using a different algorithm. – Madiemadigan

Figured I'd add one supplementary tip for those trying to maximise image performance. IF you have well compressed JPGs you can load the raw JPG data into NSData objects in advance (perhaps in an array or dictionary), and build the JPGs using UIImage:imageFromData when you want to display. The JPG data can be 10-100x smaller than the bitmap image data, but it allows you to get the (relatively slow) IO part out of the way early. Obviously be careful about how much data you cache/preload this way. – Motorbike

I've found some data on compersion times: cocoanetics.com/2012/09/… It seems, that using png isn't faster than jpg ;) – Wolfson

Answer 2

Apple optimizes PNG images that are included in your iPhone app bundle. In fact, the iPhone uses a special encoding in which the color bytes are optimized for the hardware. XCode handles this special encoding for you when you build your project. So, you do see additional benefits to using PNG's on an iPhone other than their size consideration. For this reason it is definitely recommended to use PNG's for any images that appear as part of the interface (in a table view, labels, etc).

As for displaying a full screen image such as a photograph you may still reap benefits with PNG's since they are non-lossy and the visual quality should be better than a JPG not to mention resource usage with decoding the image. You may need to decrease the quality of your JPG's in order to see a real benefit in file size but then you are displaying non-optimal images.

File size is certainly a factor but there are other considerations at play as well when choosing an image format.

Splayfoot

In my benchmark Xcode optimisation actually made files slower, likely because disk I/O, not CPU is the bottleneck. – Pocketful

"Apple optimizes PNG images that are included in your iPhone app bundle" - Does this mean PNG that are download dynamically are not optimised? – Darcie

No, PNGs downloaded dynamically are not optimised. The optimisation is basically just swapping the byte order from RGBA to BGRA, which is what the iPhone graphics chip uses internally. More info here: graphicsoptimization.com/blog/?p=259 – Catachresis

Answer 3

There is one important thing to think about with PNGs. If a PNG is included in your Xcode build it will be optimized for iOS. This is called PNG crush. If your PNG is downloaded at run time it will not be crushed. Crushed PNGs run about the same as 100% JPGs. Lower quality JPGs run better than higher quality JPGs. So from a performance standpoint from fastest to slowest it would go low quality JPG, high quality JPG, PNG Crushed, PNG.

If you need to download PNGs you should consider crushing the PNGs on the server before the download.

http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/

Granniah

Answer 4

The Cocoanetics blog published a nice iOS performance benchmark of JPGs at various quality levels, and PNGs, with and without crushing.

From his conclusion:

If you absolutely need an alpha channel or have to go with PNGs then it is advisable to install the pngcrush tool on your web server and have it process all your PNGs. In almost all other cases high quality JPEGs combine smaller file sizes (i.e. faster transmission) with faster compression and rendering.

It turns out that PNGs are great for small images that you would use for UI elements, but they are not reasonable to use for any full screen applications like catalogues or magazines. There you would want to choose a compression quality between 60 and 80% depending on your source material.

In terms of getting it all to display you will want to hang onto UIImage instances from which you have drawn once because those have a cached uncompressed version of the file in them. And where you don’t the visual pause for a large image to appear on screen you will have to force decompression for a couple of images in advance. But bear in mind that these will take large amounts of RAM and if you are overdoing it that might cause your app to be terminated. NSCache is a great place to place frequently used images because this automatically takes care of evicting the images when RAM becomes scarce.

It is unfortunate that we don’t have any way to know whether or not an image still needs decompressing or not. Also an image might have evicted the uncompressed version without informing us as to this effect. That might be a good Radar to raise at Apple’s bug reporting site. But fortunately accessing the image as shown above takes no time if the image is already decompressed. So you could just do that not only “just in time” but also “just in case”.

Hetaerism

Exactly, and JPEGMini and ImageOptim makes jpegs really small! – Themistocles

Answer 5

Just thought I'd share a bit of decompression performance data...

I'm doing some prototyping of a 360 degree viewer - a carousel where the user can spin through a series of photos taken from different angles, to give the impression of being able to smoothly rotate an object.

I have loaded the image data into an array of NSData's to take file i/o out of the equation, but create NSImage's on the fly. Testing at near max frame rate (~25 fps) and watching in Instruments I see the app is clearly CPU-bound and there's an approximately 10% increase in CPU load showing ~275 kb png's vs. ~75 kb jpg's.

I can't say for sure but my guess is the CPU limit is just from general program execution and moving all the data around in memory, but that image decompression is done on the GPU. Either way and the JPG vs. PNG performance argument looks to favour JPG, especially when the smaller file sizes (and therefore smaller sizes of objects in memory at least in some parts of the chain) is taken into consideration.

Of course every situation is different, there's no substitute for testing...

Motorbike

The GPU can't decompress PNGs. The deflate format it uses is not suitable for the kind of parallelization GPU enables. I guess JPG decoding can be partially GPU-accelerated, as there's colorspace conversion involved. – Pocketful

Answer 6

I have found massive differences in animation performance when using jpegs vs png. For example placing three screen-sized jpegs side by side in a UIScrollView and scrolling horizontally on an iPhone4 results in lag and a thoroughly unpleasant jerky animation. With non-transparent pngs of the same dimensions the scrolling is smooth. I never use jpegs, even if the image is large.

Hub

Answer 7

I think if you want to use transparent, you have no choice except PNG. But, if your background is opaque already, then you may use JPG. That is the only difference I can see

Skilken

This doesn't address any performance considerations of JPG vs PNG. – Chuipek

Answer 8

'Use JPEG for photos' as mentioned in Human Interface Guidelines under section Produce artwork in the appropriate format.

Mesoglea