In this mobile design tutorial, Jen Gordon addresses the issue of whether to export image files destined for mobile applications in the PNG or JPEG image format.
I recently received a great question from Mobiletuts+ reader Ronald, who is building an application that requires loading photographs of grapes (yes, grapes). Hey, I don't ask questions, I just answer them. Specifically, his question was:
Do I save my grape photographs as .png or .jpg format?
Great question! After all, it is well documented that .png is the recommended image file format for the iOS platform, however for web-based projects it’s common knowledge that .jpg format is preferred for photographic images.
JPG, GIF, and PNG - What’s the Difference?
First, let’s touch on the nuances of each file format. For the really nerdy details, go here.
JPEG - the standard for photographic images and does not support transparency.
GIF - limited to 256 colors and therefore is good for large blocks of solid color and simple graphics. It supports transparency but produces jagged edges.
PNG - a lovely combination of .jpg and .gif, allowing .jpg quality images and transparency without the .gif jaggies.
Which to Choose and Why
The simple answer for native iOS applications is to always use PNG unless you have a very, very good reason not to.
When an iOS application is built, Xcode optimizes the .png files in a way that it does not optimize other file formats. It gets pretty deep, and you can read about the details here. This quote from Jeff Larmarche’s blog explains it best:
When you use any other file type (or if you load a non-optimized PNG files), your iPhone has to do the byte-swapping and alpha premultiplication at load-time (and possibly re-do the alpha multiplication at display time). Your application basically has to do the same processing that Xcode does, but it's doing it at run-time instead of at build-time. This is going to cost you both in terms of processor cycles and memory overhead.
What About Images Loaded From the Web?
Not all images you see in iOS applications are actually part of the application binary. This means that they are downloaded from the web and served into the application “from outside” the actual app. In this case, it makes sense to optimize images to the smallest file size possible, and that may often mean using a format other than PNG.
Below is an example of what I’m talking about. You can see I have the grape image set up for an iPhone screen, 320x480px, 72dpi:
When the “Save for Web” dialog appears (file menu > save for web) you can see side by side the difference between saving your image as a .png vs .jpg.
File Size - This is the most dramatic difference. The .png weighs in at 258k, while the .jpg is at a tiny 18k. That’s a HUGE difference. And if your app is loading in these images from the web, your users will not appreciate the additional wait time of the .png.
Color and Contrast - The colors in the .jpg are richer, more saturated. The .png looks washed out.
So, a few practical tips on when to use .jpg vs. .png for web downloads:
- If you DO NOT need to preserve the transparent background for an image
- If you’re working with photographs that need to preserve the image quality, color, and saturation.
- When your image requires transparency
- When working with purely graphical images. Photographs do not render as well in .png format
What about GIF and TIF?
Well, we can’t leave them out of the conversation, can we?
.tif (or .tiff) files are not rendered in a “Save for Web” environment. Typically, .tif files are high quality images where you can preserve both transparency and layers. You see them used a lot in print design.
.gif files are used all the time in web design, and can preserve transparency just like a .png. The problem with using .gif’s is twofold:
1. If you’re exporting a photograph (as seen below) .gif really can’t compete with .jpg from a filesize or image quality standpoint:
2. If you’re exporting graphics and thinking of .gif, think again. The way .gif preserves transparency is different than .png. Look at the below example, where I wanted to preserve the glow around the button. I sliced out the button, hid the checkered background, and went to File > Save for Web to open the Save for Web dialog:
In the save for web dialog you can see how the button renders when I select “gif”. The button is encircled in the color I’ve chosen in the “matte” dropdown. The .gif format will require that any transparent gradient have a background (or matte) color that the gradient can transition into. Imagine what this button would look like layered over my checkered background. Yuck.
This is why .png is such a wonderful thing. See how the transparency is actually transparent? Layered over a checked background it will look exactly like it does in the mockup!
To summarize, for native iOS applications where you are providing the images with the application binary and building with Xcode, use the .png format. The only exception is when you’re dealing with images loaded into the app from the web. Then optimize to the max!