Issuu on Google+

Netvlies Internetdiensten Marketing, Design & Techniek blog Zoeken


Hoofdmenu Spring naar de primaire inhoud Spring naar de secundaire inhoud • Home • Bezoek

Berichtnavigatie ← Vorige Volgende →

Retina revolution Geplaatst op 27 juli 2012 door Daan Jobsis The devil is in the details Detail is probably one of the most important values for a designer, an eye for detail should be in our DNA. As a perfectionist I like my designs to be pixel perfect. I am allergic for “jaggies” and ugly compressed artifacts in icons and images on websites. Apple’s Retina revolution is an interesting evolution that is turning the design world upside down. The Retina display has a high enough pixel density to prevent pixelation to be noticable to the human eye. Therefore a Retina display is a lot sharper and more pleasant to look at. Apple has doubled the amount of horizontal and vertical pixels on the iPhone, The New iPad, and now also on the new MacBookPro. The Retina revolution is irreversible, and other companies have already started or will also start implementing this new Retina technology. Nowadays pixel perfection can be obtained with techniques like @font-face and CSS3. Making fonts, borders, shadows, and gradients sparkle on your screen. These elements are based on vectors or mathematical expressions which allows them to be scaled to enormous sizes without creating distortion. This does not count for rasterized images which consist of pixels. An image that looks good on a normal display will appear blurry on a Retina display. The Retina display blows up the image, it doubles the amount of pixels. There is not enough data for the image to be displayed properly.

So there really is only one solution to get these images to be displayed properly and that is to double the images in size. More pixels = better display! Plenty of articles have been written about this technique, like this article by Conor Turnbull. Turnbull’s article shows how various companies like Apple are preparing their websites for the Retina revolution. In short: first the normal page will be loaded, then they detect if the page is viewed on a Retina display. If a Retina display is detected, images with a double pixel-size will be downloaded and will replace the normal images. This means that roughly 4 to 5 times more data will be downloaded compared to a normal website. Ridiculous right? Now that we finally have access to incredible Internet speeds we get thrown back in time. There doesn’t seem to be a proper solution, and if so could this already be the end of the Retina revolution? Thankfully not… More detail with less kilobytes One thing is certain, if you want to solve this problem you will need bigger images. Images that are double in size. This has been the starting point in a few tests I have done. I saved a 300 x 200 pixel image as an jpg image with an 80% compression, it’s file-size was 21kb. This file, optimized for a normal screen resolution, formed the base for my test. I saved the same image, this time optimized for a Retina display, and doubled it’s size. So it had 4x the amount of pixels. With the exact same compression (80%) this image was 68kb. This makes sense of course, the image is 4 times as big. I then put the two images in a test HTML-page and scaled the Retina image 50% so that both images had the same format (300×200). When I opened the test HTMLpage on the New iPad, with Retina display, the image was very sharp but unfortunately it’s filesize was just too big to actually start using this method. I continued the test by saving the base image with 1,5 times the amount of kilobytes of the, doubled the pixel size, but with more compression than the first test. This image also appeared very sharp, but it’s filesize was still far from ideal. So I continued to increase the compression of the image, and still the image appeared very sharp on a Retina display. A smaller filesize AND a better quality on both screen types! This is impossible. “So why not continue compressing the Retina image” I thought to myself. I continued by reducing the Retina image to a whopping 75% of the base image. Holy moly, even this worked, even this image was razor sharp. The difference is even noticable on the iPad 1, 2 and normal computer screens. How bizar, the filesize is smaller than the original. So a smaller filesize AND a better quality on both screen types! This is impossible, I thought. I started to wonder if there was something wrong with the base-file that I used. But there was nothing wrong, I did various test with different images and they all had the same result. Eureka! The bottomline is that heavy compression doesn’t affect the final image as much as you would expect. This is because of the greater amount of pixels in the Retina image, compression artifacts are scaled down and therefore almost unnoticeable. Of course there are certain factors that you have to consider before you start using this method in future websites. For example, how will these images behave in a responsive website? Also, is this something that clients can handle? How can the compression be determined, can a CMS automatically compress the images? Examples In the left column you can see the base-images, in the right column the Retina images with various compressions. Make sure you check it on a Retina display of course!

More examples can be viewed in the follow up article (via Google Translate) Base resolution (300 x 200 px)

Retina resolution (600 x 400 px)

Jpg compression 80 / 21 kb

Jpg compression 31 / 16 kb (75% of base)

Jpg compression 80 / 21 kb

Jpg compression 42 / 21 kb (same size as base)

Jpg compression 80 / 21 kb

Jpg compression 53 / 32 kb (1,5x base size)

Jpg compression 80 / 21 kb

Jpg compression 80 / 68 kb (full retina)

Base resolution (300 x 200 px)

Retina resolution (600 x 400 px)

Jpg compression 80 / 17 kb

Jpg compression 35 / 13 kb (75% of base)

Jpg compression 80 / 17 kb

Jpg compression 46 / 17 kb (same size as base)

Jpg compression 80 / 17 kb

Jpg compression 59 / 26 kb (1,5x base size)

Jpg compression 80 / 17 kb

Jpg compression 80 / 47 kb (full retina)

Base resolution (300 x 200 px)

Retina resolution (600 x 400 px)

Jpg compression 80 / 18 kb

Jpg compression 25 / 13 kb (75% of base)

Jpg compression 80 / 18 kb

Jpg compression 41 / 18 kb (same size as base)

Jpg compression 80 / 18 kb

Jpg compression 52 / 27 kb (1,5x base size)

Jpg compression 80 / 18 kb

Jpg compression 80 / 55 kb (full retina)

Base resolution (300 x 200 px)

Retina resolution (600 x 400 px)

Jpg compression 80 / 13 kb

Jpg compression 25 / 10 kb (75% of base)

Jpg compression 80 / 13 kb

Jpg compression 40 / 13 kb (same size as base)

Jpg compression 80 / 13 kb

Jpg compression 52 / 20 kb (1,5x base size)

Jpg compression 80 / 13 kb

Jpg compression 80 / 39 kb (full retina)

Base resolution (300 x 200 px)

Retina resolution (600 x 400 px)

Jpg compression 80 / 14 kb

Jpg compression 6 / 11 kb (75% of base)

Jpg compression 80 / 14 kb

Jpg compression 19 / 14 kb (same size as base)

Jpg compression 80 / 14 kb

Jpg compression 50 / 21 kb (1,5x base size)

Jpg compression 80 / 14 kb

Jpg compression 80 / 35 kb (full retina)

Translation by: Thomas Rademakers

Daan Jobsis Meer berichten Dit bericht werd geplaatst in Design en Interactie en getagged Design,retina,Toekomst door Daan Jobsis . Bookmark de permalink .

32 reacties op “Retina revolution”


Matthew Silvan op 13 augustus 2012 om 14:30 schreef: Great advice shared here. So your point is to scale the images down. You are using JPG even for logos, although I would have avoided it due to the lack of quality. Since everything below 80% looks bad on the logo above, one might just use PNG in the first place (as long as the file size remains reasonable). Reageer ↓ •

Daan op 13 augustus 2012 om 14:37 schreef: I agree, using jpg images for classic gif or png images is not a very good idea. Mainly because jpg images are bigger than gif / png. I used the logo image only for testing purposes Soon i”ll post a follow up article with lots of new testing images! And more conclusions.

Reageer ↓


Gwen op 27 augustus 2012 om 18:12 schreef: Probably the ‘best’ solution I’ve seen so far. Thanks for sharing! Reageer ↓


unki2aut op 7 oktober 2012 om 13:31 schreef: I was wondering, how you made the images appear the same size, so i had a look at your code: the original images only had a width of 294px even though you set them to 300px as attribute. this was because of the max-width attribute in style.css:808 which has a value of 97.5%. i deactivated the attribute and had a very interesting visual result! Reageer ↓ Daan Jobsis op 8 oktober 2012 om 07:53 schreef:

This WordPress blog page does strange things with the width of the images as you said. I just scaled the 600px images to 300px. Reageer ↓


Florian Bösch op 7 oktober 2012 om 13:34 schreef: Note that if you upscale an image and then recompress it, you’re not actually adding more detail. You might be using a nicer upsampling filter than no interpolation (jpg) like bilinear, bicubic, etc. But in effect, you just added a bit of blur. The more correct methodology would be to downsize a larger image to 50% its original width/height. And then compare that, and I assure you, you won’t get “the same or better result with less file size”. Reageer ↓ •

Jackfabulous op 8 oktober 2012 om 20:46 schreef: You misunderstood the article – he is talking about scaling the images in the browser, that is, serving an image that is twice the size that it will display. This has the effect of reducing the jpeg compression from 8×8 squares, to 4×4* squares on standard monitors – even at high compression, this “false resolution” hides the increased numbers of jpeg artifacts. * jpeg compresses images in 8×8 sections (by finding a wave that most accurately describes the pixels – the less accurate the wave, that more compression is possible), which is why they get that “squarey” compression

Reageer ↓


Alfred op 7 oktober 2012 om 13:40 schreef: When your website tops 90 HTTP requests, you shan’t shave a few bytes with a stupid trick, you oughta learn to code. Reageer ↓ Daan Jobsis op 8 oktober 2012 om 07:55 schreef:

I’m a designer, not a coder. Reageer ↓


Wim op 7 oktober 2012 om 13:50 schreef: Ugh “Retina revolution”, “this new Retina technology”… High end models of other brands pushed full HD displays in to 13″ and even 11″ laptops years back. (the 2009 Vaio Z for instance was 13.1″ and had a full HD display, and the Vaio P has pushed 221 dpi for even longer. The Vaio UX, while being significantly smaller, had 264dpi) I fail to see how Apple is leading the charge and their “Retina” branding is being seen as if it were some technological breakthrough. This is the n-th time I see a designer pointing this out as a revolution, and it’s annoyed me every time. I like the fact that higher resolution displays are becoming more widely available, but lets give credit where credit is due, and no label this as another Apple invention. Granted, they are a major benefactor for the high-dpi adoption rate, but that’s about it. Reageer ↓ •

Daan Jobsis op 8 oktober 2012 om 07:57 schreef: I think Apple is bringing the high resolution screens to the masses for the firts time. I’m sure they aren’t the inventors of it. Reageer ↓

Tiffany op 8 oktober 2012 om 15:33 schreef: It’s not about who gets to the plate first, but who does it best. And Apple has far exceeded it’s competitors. Reageer ↓


Zardoz op 7 oktober 2012 om 14:28 schreef: Interesting but in my not retina display I can appreciate more subtle differences in your images for Retina that are compressed to a 71% of original size. I can appreciate some subtle colour jumps in the background gradient. Perhaps my monitor have more contrast…. Reageer ↓


Chris op 7 oktober 2012 om 17:09 schreef: FYI, you have a css rule that is causing your control images (on the left) to appear slightly smashed and therefore more blurry: line 808 of .entry-content img, .comment-content img, .widget img { max-width: 97.5%; } Reageer ↓


John SMythe op 7 oktober 2012 om 18:14 schreef: I’m definitely going to try this later today. Great tip. Two comments: 1. – Your images have large ‘empty’ areas and fairly limited color/tonal range, which means images compress well to begin with, and output quality varies relatively little if you save an image at 80 or 50). Are your suggestions still valid with images that contain lots of detail and a large variety of colors? 2. – Check out optimized compression with JPEGMini. I use this for all sites/clients. very happy with the results. Could reduce your full size retina version of the lady with the glasses (41kB) to 21kB without any noticeable difference (smaller version from 16kb => 12kb). In a way it makes sense, as the JPEG standard was created to benefit from the limitations of the human eye (color perception/detail) and because of the “pyramid” encoding (every additional quality level adds more “signal” ie detail). I suspect that in-browser sharpening applied to browser-rescaled images also plays a role here. Thanks again en groeten aan je moeder. Reageer ↓ •

Daan Jobsis op 8 oktober 2012 om 08:06 schreef:

Thanks fot the feedback 1 – In a follow-up article I tried other pictures besides the ones with the limited tonal range etc you mentioned. It’s in Dutch, but maybe Google Translate will make you onderstand. Or perhaps you can read (and) write Dutch! 2 – Will check it out! Jij ook de groeten aan je moeder, zag haar laatst nog bij de AH! Reageer ↓


SI Hayakawa op 7 oktober 2012 om 18:39 schreef:

typo: “doubled it’s size” — should be “its” (possessive, no apostrophe) Reageer ↓ Daan Jobsis op 8 oktober 2012 om 08:06 schreef:

Thanks! Reageer ↓


SI Hayakawa op 7 oktober 2012 om 18:40 schreef:

another typo: “unfortunately it’s filesize” — should be “its file size” Reageer ↓ Daan Jobsis op 8 oktober 2012 om 08:07 schreef:

I’m Dutsch! Reageer ↓


ಠ_ಠ op 7 oktober 2012 om 19:25 schreef:

You should look at this post’s HN comment thread to read all the corrections to your little assumptions. Reageer ↓

Daan Jobsis op 8 oktober 2012 om 08:08 schreef:

I will do that, thank you for your feedback! Reageer ↓


Aaron Trostle op 7 oktober 2012 om 19:45 schreef:

This is awesome. I just purchased a Retina Macbook Pro and have been scouring the web for new techniques to tackle this issue. When I bought my new MbpR I had no idea what a difference the retina display would have on my web design work. Thanks so much for sharing, I agree with Gwen, one of the best solutions out there so far. Reageer ↓ 14.Pingback: Retina revolution | Itsaat


Joris Bulckens op 7 oktober 2012 om 22:29 schreef:

Dit is de oplossing.. Reageer ↓


evandrix op 8 oktober 2012 om 00:18 schreef:

are there noticeable differences in image loading times (compressed vs. uncompressed)? Reageer ↓ •

Daan Jobsis op 8 oktober 2012 om 08:09 schreef: I think so. Off course depending on the site your visiting. Reageer ↓


BriBriBriBri op 8 oktober 2012 om 03:41 schreef:

Cool discovery. It makes sense that when the higher resolution is scaled down it hides the jpeg compression artifacts, but I had never thought to try this. Even if people aren’t likely using a retina display this would seem to be a valuable technique where load times are critical.

On another note, this page doesn’t display very well on my iphone 4S — the image examples get squished horizontally and it’s harder to see the difference. Just wanted to let you know since seeing this on a retina display really drives home how effective it is. The examples did display properly on my retina ipad. Reageer ↓ Daan Jobsis op 8 oktober 2012 om 08:10 schreef:

Thank you for the feedback, it’s a bug in the WordPress code I think. I’m trying to have this fixed. Reageer ↓


jive op 8 oktober 2012 om 14:49 schreef:

So all you do is make the image twice the size and then set the IMG tag to show it as half the size? I’m thinking in the future, people may have to adjust the DPI of images. Reageer ↓


Gray Ghost Visuals op 8 oktober 2012 om 15:05 schreef:

In your article it sounds like you’re suggesting to upscale the original image for use in a high resolution situation. Anytime you upscale your original image the result will be fuzzy and blurry. You have to have the large image first or else when the high resolution device scales the image it will guesstimate the pixels. This is where the fuzzy and blurry effect come from. If you’re part of the apple developers program there’s a great video on this topic under the WWDC session videos 2012 Reageer ↓


Steven op 8 oktober 2012 om 17:32 schreef:

Great article. Just a heads up though, images on your site are not being scaled vertically for mobile. They appear stretched on the iPhone. This could be resolved by setting “height: auto” in your .entry-content img{} Cheers Reageer ↓

Geef een reactie Reactie annuleren Je e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met * Naam * E-mail * Site

Reactie De volgende HTML tags en attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> Reactie plaatsen

Categorieën • Design en Interactie • Marketing en Strategie • Techniek en Code

Meest recente berichten • • • • •

Retina revolutie follow up Creatieve brainstorm sessie, mijn ervaringen en aanpak Heb jij je contentstrategie op orde? PHPCR repository admin using jackrabbitexplorer Waarom Netvlies Symfony2 gebruikt

Ondertussen op Pinterest • •

â&#x20AC;˘ Met trots ondersteund door WordPress

Retina revolution