How Do You Make Web Graphics & Photos Look Great On The New iPad?
by Joseph Linaschke, first posted March 23, 2012
(thanks ApertureExpert reader John Crosby for bringing this to my attention—follow him on twitter @j_crosby)
Photographer Duncan Davidson duncandavidson.com has been digging into the impact of the new iPad’s Retina Display, as many of us have. He blogged about a potential webkit where images above a certain size are displayed quite small on an iPad screen, which I encountered as well when loading a 21MP image on a webpage that only showed up as only 1,404 wide (you can read the “real-time” evolution of a series of experiments here if you like). Anyway Duncan took that quite a bit further in his post “Webkit Limit on Retina JPG Image Display”.
He follows up with a second post on the use of progressive JPGs vs regular JPG, titled “An Example of Photography on the Retina Display” and this is where it gets even more interesting.
Some background… here’s what it all means and why you should care.
Say you format your website to be 1,000 pixels wide, because that’s generally acceptable to be viewable on most modern screens. If your computer screen is 1,024 or 2,048 or 5 bajillion pixels wide, you will still see your web page at 1,000 pixels wide, and just have blank space around it if your screen is bigger.
Enter the iPad. If your web page is 100 pixels wide or 10,000 pixels wide, the iPad is going to scale that width to the width of the iPad (and will keep it at full width regardless which way you orient the iPad in your hands). So your images may scale up, or down, depending on if they are smaller or bigger than the width of the iPad screen.
So now, if you have a webpage that’s 1,000 pixels wide, on the previous iPads that had a 1,024 width screen, that displayed just fine. That 1,000 pixel scaled to 1,024 was insignificant, and text is rendered on the fly, so it always looks great.
Enter the new iPad. At 2,048 pixels wide, your text still looks great, but suddenly your 1,000 pixel wide images are being scaled up to over 2x, and they look like crap. Well maybe not crap, but they certainly don’t look like “retina” images… you can see pixels, artifacts, and general ugliness.
So what’s a web designer to do? Redesign your entire page at 2,048 wide? Of course not… beyond the obvious amount of work that would entail, you would break viewing on any normal computer screen smaller than that. Imagine trying to read a blog that’s 2,048 wide on your 1280 pixel wide 10” MacBook Air screen. No good.
So a solution is needed… and Duncan and his twitter followers discovered it. There’s two parts to this solution.
Part 1 — Scaling images on display
If you’ve done any web design in the past you probably recall that you can post an image of any size on your site but have it scaled in the browser, so for example you can upload a 10,000 pixel wide image but using the code style="width: 100px;" you can force the browser to render it at 100 pixels wide. This has generally been considered a Bad Idea™, because the viewer has to download that massive image only to see it at a tiny size. You’ve all been to those websites where people upload photos that are in their original mega-megapixel size and display them at 640 wide, and it takes half a minute to view a single image. Lame. What you’re supposed to do is resize the image before uploading, and display it at full size. If you want people to click on the image to open it at full size, great, you put that there too, but you never force them to download the full size thing.
Well, that’s about to change.
Now if you take a 2,048 pixel image, and tell the browser to display it at 1,024 (50%), on a regular computer screen the viewer will see the 1,024 image (but wait a little longer for the page to load), BUT new iPad viewers will see all 2,048 glorious pixels. Fantastic.
Part 2 — Progressive vs Normal JPG
So where does the progressive part come into play? For those shaky on web JPG history, a progressive JPG is a type of JPG that doesn’t just draw top to bottom on screen, but loads a softer/lower resolution image on screen first, then continues to draw it over and over again “progressively” until the full quality is presented. This allows images to appear on screen quicker, albeit at lower quality, then continue to improve as they download. As Duncan said, he hasn’t used that format in years, and I haven’t either. For one, connections are so fast these days it’s relatively irrelevant, and two, Aperture doesn’t output progressive JPGs — and you all know I use Aperture.
What Duncan and I both discovered in our testing was that images don’t display at full resolution on the new iPad if they are over a certain size. He did a bunch of tests and in the process of it figured out that what the new iPad / webkit really likes is progressive JPGs (or PNG, but those are too big for most use). If you present too-large of an image as a regular JPG (to see how too-large, read his post), the iPad will display it at some factor smaller. However that same image as a progressive JPG will display just fine. Hurrah!
Part 3 — Put 1 and 2 together and what do you get…
Now let’s combine these two concepts and see what happens, and this is what you’re seeing tested below. You’ll want to view this on a new iPad to get the most out of this (photojoseph.com/retina is the page you’re looking at now).
The first image is a normal JPG at 1055 pixels wide. Looks fine on a computer screen; looks rubbish on the new iPad.
The second is a normal (non-progressive) JPG that is 2110 pixels wide, but is being displayed at 1055. Looks effectively the same on a computer to the first photo, but on a new iPad—wow what a difference (look at the basket on the bike to see the biggest difference)
The third is a progressive JPG that is 2110 pixels wide and displayed at 1055. I thought it appeared sharper on the iPad than the non-progressive, but you’ll see at the end that the difference is negligible.
Now here’s the second part. Click/tap on the second and third images. On a computer, both will open to their 2110 original. On the iPad however, the non-progressive (photo 2) will open to only 1055 wide, whereas the progressive (photo 3) will open to the full 2110 wide! You can see the size by looking at the title in the tab; you’ll see the name of the file and then the size it’s being displayed at, so for example “2110.jpg 1,044x704 pixels”.
Keep scrolling past these, there’s more to the story.
1055 wide at 100% (normal JPG)
2110 image displayed at 1055 (normal JPG) — tap to open full size image, not scaled (iPad will display scaled to 1055)
2110 image displayed at 1055 (progressive JPG) — tap to open full size image, not scaled (iPad should display at size)
Let’s look at these cropped so it’s easier to compare on one screen without scrolling…
1055 wide at 100% (normal JPG)
2110 image displayed at 1055 (normal JPG)
2110 image displayed at 1055 (progressive JPG)
How big of a difference is it?
Here are crops side-by-side of screenshots from a new iPad, with a difference algorithm applied in the third pane. As you can see the difference is remarkable, especially in areas of fine detail (look at the basket). First you’ll see the 1055 vs the 2110-as-1055 image, then the normal vs progressive JPG. Again for the second compare there is a difference but it’s barely there, and to be honest I couldn’t tell you which is better.
Sum it up…
So again, what does this all mean?
- If you want images to look awesome on the new iPad on your webpage, upload them at twice their size and scale on display. And to be honest, this 2x isn’t a hard line. If you’re building a web page that’s only 512 pixels wide and displaying a full-page-width image, and you want it to look good on a 2,048 iPad, then you’ll need to make your image 4x size at 2,048, displayed as 512.
- If you want viewers to open large images and see the full size on an iPad, you’ll need to choose progressive JPG. At the moment for Aperture users that means using Photoshop or something else. Preview.app doesn’t even do progressive JPG. It’s an old format that’s not really used, so I’m not surprised.
- If you want both, then you gotta do both. At least for now. I’m inclined to agree with Duncan that this is a bug.
If you want to comment, please do so here. This isn’t a blog page so I don’t have comments on it. And thanks again to Duncan Davidson for figuring most of this out. We all stand on the shoulders of giants.