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 its 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 HTML-page on the New iPad, with Retina display, the image was very sharp but unfortunately its 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

124 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 ↓
- Bart op 14 november 2012 om 20:02 schreef:
  
  Yeah, it’s such a 1990s thing to do. JPG for high-color photos, GIF or 8-bit PNG for logos/low-color flat graphics.
  
  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 ↓
  - Adrian op 2 november 2012 om 19:45 schreef:
    
    No; unless I am misunderstanding how the author described his process, Florian is correct: You can’t judge the *appearance* of the two images, because the larger image is only a scaled-up version of the smaller image.
    
    For a useful test, the larger image needs to be the original (at full resolution). The smaller image needs to be obtained by scaling the larger image down.
    
    Reageer ↓
    - Barney op 13 december 2012 om 09:51 schreef:
      
      Just looking at any one of the examples provided will immediately reveal higher detail on the retina images. And, as Florian says, you can’t magically add detail to upscaled images. So even without reading the article, the only natural thing to conclude is that the same high-resolution source was used for both images. This is standard practice for anybody who deals with images on a regular basis.
      
      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 ↓
  - Mahroof Ali op 2 november 2012 om 02:47 schreef:
    
    Apparently, apple has never invented something new. There has been tablets before the ipad, there has been smartphones before the iphone and there has been portable media players before the ipod – but when apple did it, it was a breakthrough.(Don’t get me wrong, I’m not an apple fan)
    And, of course, this is an interesting finding. The high-res low quality images do look sharper!
    [something irrelevant: Please remove that cookie request and fixed-scrolling "privacy settings". Its really really annoying ]
    
    Reageer ↓
    - Sjoerd Peters op 2 november 2012 om 12:18 schreef:
      
      Unfortunately ‘the cookie request’ and ‘privacy settings’ Are there as an implementation of a local (dutch) law. http://bitly.com/Vipic4
      
      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 ↓
  - Michael DeMutis op 9 oktober 2012 om 13:03 schreef:
    
    Retina displays are better resolution than HDTV screens.
    
    Reageer ↓
  - Sebhelyesfarku op 9 oktober 2012 om 17:45 schreef:
    
    Exceeded in what? Marketing bullshit?
    
    Reageer ↓
    - Bart op 14 november 2012 om 20:10 schreef:
      
      I think it has more to do with coming up with a strategy for developers. Where the software resolution is close to an old standard size (1440×900) with 2x graphics being used where needed (and type at high-res resolution) to sharpen the true 2880×1800 resolution.
      
      That’s different from someone making an unusably-high resolution screen where people are forced to dump up font sizes, have unusable programs, and websites with broken layouts.
      
      It’s the same situation where “tablet computers” existed before the iPad, but nobody thought they needed to update the crappy OS/software (I remember using one with Windows Me??) for touch navigation instead of point+click.
      
      Reageer ↓
- Hugh op 10 oktober 2012 om 10:54 schreef:
  
  The new challenge about Retina is not that it’s higher resolution than everything else (though Apple would like you to believe that), it’s that web pages and their images are displayed at 200% zoom by default. I don’t think the laptops mentioned do that. However, other non-Apple mobile devices do, so this is an increasingly useful technique.
  
  What surprised me is that it also increases image quality per byte on standard resolution monitors (even after you turn off the interfering CSS rule).
  
  Reageer ↓
- zzz op 10 oktober 2012 om 11:57 schreef:
  
  The trick with the Retina Display is not that it has so many pixels, but that the OS shows 1 Pixels as 4. So the size of the items on the screen stay the same, but they are sharp.
  Windows lets you choose between small fonts and items or scaling up the items to 150% which results in squishy images – Apple made it easy for developers to add two different asset sets to their software.
  
  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 http://blog.netvlies.nl/wp-content/themes/twentyeleven/style.css

.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!
  
  http://blog.netvlies.nl/design-interactie/retina-revolutie-follow-up/
  
  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.

http://news.ycombinator.com/item?id=4623160

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 ↓
Pingback: Retina revolution | Itsaat
Joris Bulckens op 7 oktober 2012 om 22:29 schreef:

Dit is de oplossing..
http://www.jpegmini.com

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
https://developer.apple.com/videos/wwdc/2012/?id=602

Reageer ↓
- Daan Jobsis op 12 oktober 2012 om 14:39 schreef:
  
  No, it’s not about upscaling your images. You need to use actual bigger pictures: 2 times the pixel size in both directions.
  
  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 ↓
Oskar Elek op 9 oktober 2012 om 12:36 schreef:

Hi Daan, I don’t want to sound negativistic (the effort is appreciated), but there’s hardly anything new in what you wrote. JPEG compression was specifically designed to exploit deficiencies of the human visual system. That of course doesn’t mean it’s universal – JPEG fails for images with large constant areas or gradients, high-contrast images etc.

The bottom line, and the basic principle of publishing pictural content, is – always use the resolution, format and compression quality that is *just sufficient* to represent what you want to convey. This is of course not easy to get right and requires testing, since it varies from case to case, but it’s the deal. There are heuristics that can help you to automate this, but there’s still a lot of progress to be made.

Reageer ↓
- Daan Jobsis op 12 oktober 2012 om 14:47 schreef:
  
  I think this is a new approach. The jpg compression isn’t new off course, but the way heavy compression can be used to create sharper images who are smaller or the same size is. Especially in combination with high resolution screens. Other ‘common’ solutions are serving multiple images, or using high res images with normal compression who are huge in filesize.
  
  Reageer ↓
Logan op 9 oktober 2012 om 17:16 schreef:

Sorry for being pedantic, but are the images not four times the size? We’re doubling each dimension after all, and there are two dimensions.

Reageer ↓
- Daan Jobsis op 12 oktober 2012 om 14:52 schreef:
  
  4 times the pixelsize, 2 times the resolution!
  
  Reageer ↓
Pingback: Michael Tsai - Blog - JPEG Compression and Retina Images
Pingback: Michael Barrett @ Abouthalf.com. : JPG is a compression format
Pingback: Things You’ll Find Interesting October 9, 2012 | Chuq Von Rospach, Photographer and Author
Pingback: Revision 91: Konferenzen und HiDPI Bilder | Working Draft
Franky op 11 oktober 2012 om 09:08 schreef:

Somehow the same approach that 10bit video uses … as you have more material you can truncate more without the user noticing a difference, leading to better compression.
http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

Reageer ↓
Pingback: Designing for Retina - DesignersTalk
Gruber op 26 oktober 2012 om 19:55 schreef:

This is very VERY interesting, and i’m wondering isn’t it better then to ALWAYS use the retina compression? this way you have the best of two world and no need to get crazy to support both retina and unretina displays, simply put the image double sized, compress the jpeg and then half the pixel sizes. Any contraindications for this?

Reageer ↓
- Micha op 15 november 2012 om 11:36 schreef:
  
  i was going to post the exact same comment here.
  
  very nice discovery Daan!
  
  but why not using your “retina compression” method throughout the website, no matter what pixel-ratio the user has. i mean if it’s the same file size…
  
  Reageer ↓
Pingback: How to serve high-resolution website images for retina displays (new iPad/iPhone4+) - benfrain.com - blog of technology writer and web designer Ben Frain.
Grégoire Noyelle op 1 november 2012 om 20:49 schreef:

Hi Daan
Thanks a lot for sharing. On my retina iPad, your trick works very well. I never thought to use the compression like you did on the retina image. Great

Reageer ↓
Craig op 6 november 2012 om 11:57 schreef:

We’ve done a fair bit of work on retina optimised pages and have come up with a useful scripted solution to handle images that prevents downloading *any* extra images –
http://codex.web-engineer.co.uk/2012/11/the-end-of-points-long-live-the-pixel-and-getting-the-best-from-a-retina-display/

There is a very simple project and demo on github here – we welcome any feedback and hope that your readers find it useful.

https://github.com/web-engineer/retinize

Reageer ↓
Pingback: Чудеса Retina — файлы меньше, качество лучше
Mohamed Alaa op 6 november 2012 om 18:20 schreef:

Thanks Meer for this awesome article very helpful.

Reageer ↓
Stephen op 8 november 2012 om 19:20 schreef:

Thanks for sharing.
Compressing 80% JPEG for Retina Images would be huge bonus to save the file size. I could see the difference between normal and retina images. But Not a huge difference.

The differences come in TYPES, i think.

Reageer ↓
Jackson op 14 november 2012 om 22:23 schreef:

Interesting points… though I’m not entirely convinced yet… but it’s a good discussion starter.

Quick tip: the logo on your site is not optimized for retina (even though you used it as an example in this article).

Cheers,
Jackson

Reageer ↓
Pingback: “Compressive” Responsive Images | Swash Cap Blog
Pingback: Handling images on retina displays — functionalaesthetics
Pingback: Responsive and adaptive design resource - DesignersTalk
Stefab op 2 december 2012 om 00:23 schreef:

I think this is the best solution anyway!

I hate it at Apple’s website, when I use a non-retina device and zoom in, the pictures are so blurry and no details. You only get the good quality images, when using a retina-device, which is no fun for the others.
I guess they make it like this to push the sales of their retina-devices, but I hope the rest will offer hi-res pictures also for the rest of us!

But I would go with the SAME file size as the original image. In some pics the 75% are enough, in others not. But if you use the same size in KB for the retina-image, it never looks worse than the original.

It is fine, because I can also see the better images without a Retina-Device, when I zoom into the website. This is standard-use on every smartphone or tablet and it becomes more and more popular on normal computers too.

It is fine, that I can zoom in here with my normal MBP 13″ (or any PC, Tablet, Non-Retina iPad, etc.) and see the good images too.
I don’t need the Retina-Device to see the Retina pictures, which is the way to go!

If it is a logo, etc. best use SVG or if not possible 2x bigger PNG or GIF (it won’t get much bigger at the higher resolution), if it is a more complex image or a photo use 2x bigger JPEGs with more compression to get the same filesize.
And then scale it down on the website, so it is fine for every device! (also zoomed in on retina and non-retina displays)

Reageer ↓
Pingback: Hands on the New Glif Plus for iPhone 5 and the Cosmonaout | Robin Plus
Pingback: Hands on the New Glif Plus for iPhone 5 and the Cosmonaut | Robin Plus
Dan Wood op 4 december 2012 om 19:02 schreef:

I made a similar finding; see http://dh.karelia.com/retina/ for a little tool to test out some different images with different compression settings.

Reageer ↓
Pingback: Automatic Retina images for web sites
waqas op 11 december 2012 om 20:08 schreef:

hello,

tnx it was a great read. specially the examples. can you please tell me which soft you used to conduct this test?

Reageer ↓
- Daan op 19 februari 2013 om 13:52 schreef:
  
  Just Photoshop
  
  Reageer ↓
Pingback: a good blog post | High Performance Web Sites
Pingback: Webtrends 2013 - Das volle Interview aus der Internet Intern
Pingback: Wishing You A Responsive and Retina-Friendly Xmas! | gonzoblog
Pingback: Polar – Pure inspiration - Dean Birkett | another web guy
Pingback: Optimize Images by Saving With Low Quality & Scaling Down | Tobias Ahlin
Pingback: « Retinafy your web sites & apps » : réduisez ce pixel que je ne saurais voir - Le Blog de LunaWeb
Pingback: Bilder von Teese - coldheat.de
Pingback: Web Contemporary | Easy Programs In Retina Display Clarified
Pingback: Bitmap Image Optimisation - Broken Links
Jason op 26 januari 2013 om 08:34 schreef:

Very interesting. I have one thought about how to evaluate your examples. If I am not mistaken, the Retina display will upscale the lower resolution images for the extra hardware pixels. This will result in a slight blurring of the image when view on a Retina display. Therefore it might be more accurate to compare the lower sized image on a standard display to the lower to the higher sized image on a Retina display. I’m sure the results would be as you have found, though not quite as much of a difference as when the result are all viewed on a Retina display.

Reageer ↓
Charles op 26 januari 2013 om 16:51 schreef:

I did a test with a photo that contains text and details.

http://124mercer.com/sizetest/index.html

Reageer ↓
vossile op 31 januari 2013 om 06:33 schreef:

What I do find interesting is how irrelevant the actual memory-usage has become. An image, no matter how it is compressed to fit into a file, will always require a certain amount of memory once loaded.
A very simplistic example:
1024x768x24bits = 2,25MiB
2880x1800x24bits = 14,83MiB
Of course this is mostly not a topic anymore nowadays (and not for the dimensions mentioned in this article anyway) but it would not be wise to ignore the fact that slamming a device with dozens of ‘retina’ Images, even if it can’t display the resolution as such, will slow it down because the 64KiB File will be expanded considerably once within the device.
Nice idea, though and interesting too.

Reageer ↓
Pingback: Bruce Lawson’s personal site : Reading List
bash grep op 14 februari 2013 om 15:56 schreef:

How do you display inline images at 50% of their width? Max-width and width set at percentages are relative to their parent, the transform approach doesn’t change the rendered dom node size. Ideally, I would like to not have a css class for each image, for instance I want to avoid having to write .logo{ max-width: 200px; width: 100%; } where the .logo is on an img tag whose native size is 400px.

Reageer ↓
Pingback: Tendencias en Diseño Web en 2013
Pingback: static-article | Bppl Cloud
Pingback: Optimize Images by Saving With Low Quality & Scaling Down - timsby
Pingback: jQuery Europe 2013, Tag 2 – Namics Weblog
Pingback: Improving UX Through Front-End Performance | Feeds
Usman Ghani op 22 maart 2013 om 05:07 schreef:

Useful information. But which tools is best for compression of images. Can you tell me.
Thanks

Reageer ↓
- Daan op 4 april 2013 om 08:08 schreef:
  
  I used Photoshop CS5.5 Other people use sites like http://www.jpegmini.com/ or other desktop programs such as Fireworks. I can’t really say what program is best for you needs
  
  Reageer ↓
Pingback: Reportage fra WordCamp Copenhagen 2013
Pingback: Designing for high resolution Retina displays
Reg op 26 maart 2013 om 21:35 schreef:

This is a seminal piece of work. Well done Daan!

Ignore the wally-dingo responses regarding .png compression for the graphics. Those chaps clearly missed the significance of what you were demonstrating. It was helpful to see how .jpg influenced images of this type. I would also like to see how this plays out for gradients such as a blue sky photo.

Thanks for sharing.

Reg

Reageer ↓
Pingback: Improving UX Through Front-End Performance | Affordable Website Design - Wordpress Website Development
Pingback: Thias の blog » Blog Archive » High Resolution Graphics
Pingback: RT @matthbooth: Interesting article on JPG compres… > UX Blog
Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | PJExploration
Pingback: Retina Done Right: An Easier, Better Workflow | Deprecated.co
Pingback: Sicher ● Web & Design
Pingback: metascope | Improve Mobile Support With Server-Side-Enhanced Responsive Design
Pingback: » Responsive Design: Neem afscheid van pixel-perfect, denk proportioneel - Ferry den Dopper’s blog
Pingback: Open Source Plugin: Magnific Popup, A Truly Responsive Lightbox (For jQuery And Zepto.js) – BeeWorks Freelance Web Design and Digital Marketing Specialist based in Cagayan de Oro Philippines
Pingback: Open Source Plugin: Magnific Popup, A Truly Responsive Lightbox (For jQuery And Zepto.js) - Pittsburgh Web Design & Hosting
Pingback: Improving UX Through Front End Performance | Zip Stream
Pingback: Improving UX Through Front-End Performance | Bee Inspired
Pingback: Improving UX Through Front End Performance | DZNR
Pingback: Improving UX through front end performance | Rapid
Pingback: Improving UX Through Front End Performance | Design To Web
Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Inspire Web Designs | Web Design Kansas City
Pingback: Open Source Plugin: Magnific Popup, A Truly Responsive Lightbox (For jQuery And Zepto.js) | Kleinburd News
Leonardo op 7 mei 2013 om 22:04 schreef:

Great article. I think this is the best workflow I found so far. Thanks!

Reageer ↓
Pingback: Responsive Retina Ready Google Maps - Rob and Lauren
Pingback: Improving UX through front-end experience |
Pingback: Are Compressive Images A Good Solution For High Resolution Displays? - Vanseo Design
Pingback: Compressive Images
viagra op 15 mei 2013 om 21:34 schreef:

I am curious to find out what blog platform you’re using? I’m experiencing some minor security problems with my latest website and I would like to find something more risk-free.
Do you have any suggestions?

Reageer ↓
- Daan Jobsis op 21 mei 2013 om 07:16 schreef:
  
  It’s WordPress, pretty reliable i guess
  
  Reageer ↓
Pingback: Tutorial: Compressed Textures in AIR (ATF Format) | TreeFortress
Pingback: Improve Mobile Support With Server-Side-Enhanced Responsive Design | Tuts – Infos++
Pingback: Are Compressive Images A Good Solution For High Resolution Displays? | Eduardo Joaquim Silva
Pingback: Open Source Plugin: Magnific Popup, A Truly Responsive Lightbox (For jQuery And Zepto.js) | Reme Le Hane - Front-end Web Developer

Netvlies Internetdiensten

Marketing, Design & Techniek blog

Retina revolution

Daan Jobsis

124 reacties op “Retina revolution”

Geef een reactie Reactie annuleren