retinaBlog

How to optimize images for Retina and high density screens

A long time ago in a previous life, I sold and fixed computers. The specs were simpler,  resolutions reached 1024X768 on a 4X3 screen and the biggest hurdle was “ghosting” that you would get with a Passive Matrix Screen. Life was simple…

But those days are long gone and now that Apple has launched the Retina Display on their newly announced Macbook Pro with a Pixel density of 220 pixels per inch.  This is the first laptop to introduce a high PPI (Pixel Per Inch) count. The human eye from a normal viewing distance can’t even make out the pixels.  Same thing with the new iPad (264 ppi) and the iPhone (326ppi)…  In essence, Computers will quickly become resolution independent.

And phones have already been walking down that road. Firstly, right now most of the higher pixel density screens are on mobile devices. So what that means is that your iPhones,  your Galaxies and other competing products already blow the socks off your typical desktop computer when it comes to displaying images.

So how do we display images to different devices?

There’s a bunch of proposed methods.

Some methods require multiple versions of the graphics to be output. Using JavaScript and some DOM scripting,  the script detects the pixel density and serves up an alternate (most likely higher quality and larger) version of the image. Meh… Not on my data plan thank-you.

Or there’s the Apple website.

The super smart Apple team downloads the standard version of an image,  and then the super high resolution version if an iPad (not just a high PPI screen,  but the actual device) is detected. So rather than detecting pixel density,  they detect the device. Now, they are currently only detecting for iPads but there will shortly be a whole slew of higher PPI screens on the market. I don’t think  they will want to detect each one as it becomes available using the USER_AGENT?

But let’s look a wee bit closer. Upon further investigations, the “high resolution” iPad image on the Apple website 335KB and is sized 2240X960 pixels. So your iPad is going to pull down this big image AFTER the first low quality one while your beefier, more powerful desktop computer pulls down the version that’s 3X smaller… Huh? Wait a minute…

I think they’re going about this the wrong way. I like the idea of a high resolution image, but I also like the idea of lower file sizes… I wish we could have it both ways…

<Cue the old timers to march in> Let’s see if we can get that big huge image down to the same size of the lower resolution one… Let’s see what we can do with 120KB of data?

<Hammer swings, Drilling sounds, old men recalling how the web used to be> … 10 seconds later.

A quick test reveals that I was able to get the super high resolution version of the iPad down to 130KB (only 10KB off) and with very little visual degradation Go ahead and see for yourself (130KB). And furthermore, I could have gotten it even lower if I was dealing with a clean image. I was able to optimize pretty quickly for ALL DEVICES and nobody got hurt.

Is it perfect?  No…   Is it pretty good?  You betcha!  Especially since when scaled at all,  the artifacts are interpolated and not quite as noticeable. Would this work for all scenarios?

Back when I first started building websites, it was generally agreed and the overall goal agreed that the entire page (HTML, images, JavaScript, etc) would all fit under 30KB.  Yes, that’s right,  30KB!  We painstakingly compressed images,  teetering between a JPG at 67% and 68% compression to save those valuable bits of data. All to make sure that a website would be quick on a dial-up connection.

Occam’s Razor?

I believe the solution is actually easier than we’re making it out to seem. We need to “optimize” our images. Let’s take a logo for example. There’s no need to have a x2 version and a regular version.  If you think about it we’re going to be serving up the high resolution version to mobile devices because that’s where the high pixel density screens are these days. And now that Apple has introduced the retina display on their Macbook line, other manufacturers will be playing “catch-up” to push out their own high pixel density screens.

I don’t believe we need a transition period.  I believe that all of our images should be optimized based on their importance and context.  Using proper optimization techniques,  images can be very reasonable in size and much like responsive design,  one image, all devices.

 

one image, all devices

 

Take a look at the image above. It’s under 70KB which is more than reasonable, and yet will scale to 2X what you see here. Take a look at this blog post on a new retina iPad or iPhone. Now some hardcore purists may kick and scream about nearest-neighbour aliasing and other interpolation techniques… But guess what?  Those days are almost behind us.  Resolution will no longer matter.  Interpolation will occur beyond what the eye can see!

Forget the JavaScript image replacement. I can hear some people screaming now! Seriously though…  These days broadband is all around us and desktop computers with or without high resolutions screens will be relying on these technologies.  If we weren’t, we’d be back to the days of 30KB or less.

Many of the images on this website are not optimized for high pixel densities.  But there are other images that are.  For example, the logo. There’s no web font for the Focality Font. And yet,  regardless of the device,  the all-important branding is clean and crisp on all devices, and at a paltry 7.6KB with an alpha channel. It’s optimized.

We’re not there yet, but we will be soon.  Within the next few years resolutions will be less and less of a concern. In the meantime,  I say we do away with complicated versions of images for different pixel density detections scripts or .htaccess file rules.  This really is a tricky subject.  Some of us veterans in the industry have seen all of this before. Different assets for Flash and HTML,  Netscape vs. IE…  We’re starting to see it again.  Responsive Media Queries for this or that and now different images for different screens within different devices within different pixel densities…  ENOUGH!

Conclusion

I say we optimize our images better and ensure that the ones that are important can scale down nicely and stay sharp whereas others, the browser will scale and interpolate the pixels where file size is a factor.

On yeah,  and I’m not going to discuss CSS imagery and utilizing Media-Queries quite yet.  I’ll leave that for another day. This article was mainly about images that reside in the HTML code.

 

2 replies
  1. Fahrudin Spiodic
    Fahrudin Spiodic says:

    Awesome post, thanks. I’m very impressed that you were able to lower the file size down to 130K. Would you be willing to share the steps you took to get to this file size. Also, do you make everything twice as big and then specify the width and height in HTML (e.g. Logo size 100×100 pixels, CSS: width:50px; height:50px;) to ensure optimal quality on retina display devices?

    Thanks

    Reply
  2. admin
    admin says:

    There’s lots of different techniques to get images smaller in size. Typically, I use tools like Photoshop and “Save for Web” and then tweak settings. One thing I will stress though is that lots of people use PNG-24′s and they look great, but they’re huge. There’s no need unless you’re going to use the alpha channel. Otherwise, use a JPG and crush the file down to a really reasonable size.

    And yes, typically I ‘ll work with double sized images for things that need to be crisp. Logos, text, etc. But for things like Photos, it’s a judgement call.

    As a small warning. scaling images in the browser will sometimes blur images slightly on not hiDPI screens, but honestly, they’re already blurry anyways by comparison!

    Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *


9 + = eleven

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>