One of the challenges with responsive design is how to handle images. The issue gets more complicated when we consider images optimized for retina and other high resolution displays. Ideally we’ll use vector graphics or icon fonts where possible and even better replace images with code where we can. However, sometimes we need to serve bitmapped images.
One of the interesting techniques that’s been proposed for delivering bitmapped images to retina devices comes from Daan Jobsis. The technique is being called compressive images and I recently had a chance to run an unscientific test with a client and thought I’d share the unscientific results.
Compressive Images
First in case you’re not familiar with compressive images the general idea is that the quality of compression of a .jpeg image contributes more to its file size than the physical dimensions of the image.
Consider two identical images that differ only in their physical dimensions and quality of compression.
- 800x600px and 0% compression
- 400x300px and 100% compression
The theory behind compressive images suggests the first, while being physically larger, would ultimately have the smaller file size. If you take that image and reduce its dimensions in the browser you have an image that downloads quicker and has the additional px needed for retina and other high resolution displays.
It’s an appealing solution because it’s relatively easy to implement. However, it’s hardly a perfect solution as the comments to Scott Jehl’s post about compressive images point out.
I was curious what, if any, difference in file size and quality there would be between images of different dimensions and compression and set up a test for a client. I also set up two tests you can check out, which I’ll get to momentarily.
The Client Test
This particular client is a photographer and her site will naturally feature a lot of bitmapped images. At their largest the images will need to be 800px on the longest side. Thinking about the compressive images technique, I’ve had her send me every image at 1600px on its longest side.
Ideally we’d us media queries to serve high resolution images to particular devices, but time and budget make that unfeasible. Since I want to optimize the images for both quality and performance I wanted to test the compressive images technique to settle on the best way to save the one version we’ll use.
I took one of her images and saved it 2 ways.
- Full 1600px size with 0% quality compression
- Reduced 800px size with 100% quality compression
The file weight of the latter image was about 5 times as large as the former. That’s quite a lot of extra file weight.
I placed both images on a web page and set each to the smaller dimensions letting the browser resize the larger of the two. Then I sent her a link to the page and asked her to have a look and to ask her friends to have a look as well.
This was highly unscientific, but the results were split about 50/50 between those who couldn’t notice a difference and those who could. All who did think one of the images looked better chose the smaller image with the higher quality compression. Unfortunately most of the people responding aren’t the tech-savvy type and I wasn’t able to get them to include the resolution of their monitors.
Those who couldn’t tell the difference reported first and initially I thought I’d use the technique. Later when those who could tell the difference all reported the smaller image as being of higher quality I wasn’t so sure.
When it came time to actually add some images to the site I tested again with more realistic compression settings included.
- 1600px image was saved at 10% and 20%
- 800px image was saved at 60% and 100%
When compression on the smaller image was 60% (as high as I usually save images by the way) the difference in file size wasn’t worth using the larger image. In fact it had a smaller weight than the larger 0% compressed image.
In the end I’m using the smaller images on her site, since they aren’t noticeably heavier in terms of file size, but I wanted to conduct more tests to make sure the results I saw weren’t due to the specific images I chose to test.
What Do You Think?
Instead of testing my client’s images this time around, I thought I’d try one of my own. It’s an image I took last summer while eating lunch at Montauk and it’s the one you see at the top of this post. I’ve set up two pages comparing the same image over different sizes and compression settings.
- 1600 x 1200px vs 800 x 600px (9 images)
- 800 x 600px vs 400 x 300px (8 images)
If you peek at the file names of each image you’ll be able to tell it’s dimensions and compression settings. The files have been names with the same format of length-height-compression.jpg
Each image was compressed (and resized) using Pixelmator and then run through Image Optim to further compress them. This has become my typical workflow and I wanted to keep the test as close to what I normally do as possible.
If you don’t mind taking a moment, have a look at both tests and look over the images to see if you think one or a few look better than the others. Also, of you don’t mind, let me know the resolution of your monitor. Thanks.
My Observations
I’ve made a few observations while setting up these two test pages. First, I can see a difference in quality. It’s generally located in one specific part of the image, but it’s there. However, had I not been specifically looking for differences in quality I wouldn’t have thought the lowest quality images looked bad.
I don’t currently have a retina display Mac and it’s possible on a monitor with higher resolution I would be more put off by the lower quality images.
In comparing the file sizes of the saved images I noticed
- The larger image saved with a compression quality of 10 has a near identical file size to the smaller image saved with a compression quality of 80.
- With a compression quality of 60, the smaller image weighs about 2/3 the size of the larger image compressions at 10.
Rarely do I save images with a compression larger than 60, which suggests the compressive images technique isn’t going to work well for me.
For the most part the smaller dimension image ended up with a smaller file size. That had me wondering why, since the articles I’ve read suggest the opposite should happen.
Then it occurred to me what the difference might be. I’m using Pixelmator to compress the images and I suspect those who’ve written before me used Photoshop for compression.
One of the things I’ve learned since I started using Pixelmator is that Photoshop’s compression algorithm needs improvement. It doesn’t compress images as well as it could. I suspect the technique isn’t quite as effective as first thought where file weight is concerned, though it may still make sense for delivering images with more px density to high resolution displays.
Granted everything that’s led me to this conclusion is far from scientific. Once again if you don’t mind check the two test pages and let me know which of the images, if any, look better. I’d also encourage you to run some tests for yourself.
I’ll leave you with a table showing the difference in file size between Pixelmator and Photoshop at various compression settings over 3 different images sizes. The numbers below are after compressing each image in the specific editor and then running each through Image Optim. Above 10% and below 100% the files weigh more when compressed with Photoshop than when compressed with Pixelmator.
| Compression | File Size Pixelmator | File Size Photoshop |
|---|---|---|
| 1600 x 1200 | ||
| 0% | 57kb | 54kb |
| 10% | 76kb | 78kb |
| 20% | 93kb | 110kb |
| 30% | 108kb | 134kb |
| 800 x 600 | ||
| 0% | 17kb | 16kb |
| 10% | 23kb | 23kb |
| 20% | 28kb | 33kb |
| 30% | 32kb | 39kb |
| 40% | 36kb | 49kb |
| 60% | 47kb | 82kb |
| 80% | 73kb | 144kb |
| 100% | 299kb | 298 |
| 400 x 300 | ||
| 60% | 14kb | 25kb |
| 80% | 22kb | 42kb |
| 90% | 31kb | 60kb |
| 100% | 90kb | 86kb |
Download a free sample from my book, Design Fundamentals.
The only point of the double res highly compressed image is for presentation on a double res (retina) display, where the half resolution images look significantly worse particularly if they have text in them. Under those conditions in my highly unscientific test people picked which image was which pretty much instantly.
Thanks Brett.
My understanding of the technique is that it works to only serve one image instead of having to serve two, in part because the larger dimension image ends up being the same or less file size than the smaller dimension image. If that file size saving wasn’t there, you might as well serve different images to different resolution devices.
I’ve checked the images on my laptop which doesn’t have retina display and on my iPad which does. I can notice a small difference in quality, though not a lot and nothing that would cause me to think the lower quality images were poor.
What most surprised me though was none of my client’s friends chose the larger dimension image as the better quality image. I expected those on non-retina displays to not notice a difference and those on retina displays to choose the larger dimension image as the better one. I don’t really know what kind of monitors they have unfortunately, but all who thought one image was better all chose the smaller dimension image, which seemed strange to me.
That’s when I started creating more variations in the compression settings and noticed there wasn’t the file size savings I expected to see, which made me wonder if the savings had more to do with how Photoshop compresses images than anything else.
Yes. Interesting on the different compression outcomes, though in my tests I also used Pixelmator and had outcomes that were in line with previous findings, so I suspect compression sizes would have to be averaged to find out if one method is better than the other.
Your sample images show the compromises of each approach quite well. I picked 20% quality double res because artifacts more visible below that level (in your image the clouds are the most problematic) and the size saving wasn’t as great on the size images I was using. In the lower res images the boat’s name and other detail such as the foreground post are fuzzy in the 800×600.
In other words text and detail benefit from the double res approach but subtle shifts in colour are probably going to be better at lower resolution at low compression, and there is no guarantee on file size..
Interesting that you saw savings using Pixelmator. I suppose it could be the specific images we each used. I agree an average would be better before coming to any conclusion. I’ll have to keep testing on different images and see what I find.
Yeah it’s definitely the clouds in the image I posted. I notice more noise in that area in the lower quality images. I hadn’t noticed the boat name. I can see it now on the larger image test. On the smaller one it’s so small anyway. I’m not really seeing any issues with the post out front, though it could be my monitor or my eye.
I haven’t given up on this technique at all. I just found it odd that my initial tests with it didn’t seem to match up to what I expected to see. Something that definitely needs more testing.
Have you placed any of the images you tested online? I’d be interested in taking a look.
Very interesting test here, I’m creating a small little design project that uses a background image and I was wondering what to do with high resolution devices.
I’ve taken a look at images you’ve posted, but unfortunately, I couldn’t tell the difference on my non-hi resolution screen. I don’t have a hi res device with me so I cant help you with the tests.
I believe I might go with the larger image at a smaller compression, but thats more of a gut feel and I have no scientific answers.
Looking forward to see your results 🙂
I don’t think there’s a huge difference when you look at the images on a non-retina display. I do notice some differences. It’s mostly extra noise in a certain part of the image, but not so much to make the lower quality images look bad.
When I looked on my iPad with a retina display I notice the same thing. I can’t say I’m seeing the larger dimension images with so much better quality.
The larger dimensions at lower compression is what the technique suggests. It seems like the right approach, but if I’m not seeing enough difference in quality and I’m not seeing any savings in file size, I’m wondering if that’s best. Maybe I’m doing something wrong or misinterpreting what’s supposed to happen.
Interesting post. I did a similar sort of test a few weeks ago and found double resolution with a compression of around 20-25% to be the sweet spot for standard and hi-res displays.
Any compression lower than this works on standard resolution screens but poor image quality is apparent on retina screens.
I also, like you, found though that images saved at original size with 60% compression can have a smaller file size than the compression method, they will just appear blurrier on retina. This of course depends on the image.
Thanks Adam.
Somewhere in that 20-25% range is where I found the best compression for the 2x images too. Out of curiosity what image editor did you use to compress the images? Was it Photoshop?
I wasn’t expecting that 60% compression on the smaller image would be equivalent to 0% compression on the larger either.
The hard part for me in testing is I don’t currently have a retina display computer. I checked on my iPad, but I don’t know that the screen is large enough to make the quality differences as notably as they would be on a larger monitor. I can’t say I noticed any of the images having poor quality, though I could certainly tell the quality difference between them.
Makes a lot of sense too about some of what goes on depending on the specific image.
Yes Steven it was photoshop. You can then also take it a step further by using a lossless compression service like jpegmini or something similar.
Yeh creating graphics for retina displays without having them to test on is not ideal, however there are ways you can simulate it.
Is your iPad retina? If so, this should be fine to test on.
Or as you save for web in photoshop at double the dimension, look out for any obvious artefacts, and increase the compression until these go away, as these will show up on retina devices. (Which seems to be around 20%).
Remember just viewing the image at 2x is pretty much what retina is, so although not ideal, that is the best test you can do without a retina device.
Thanks Adam. From our conversation I can tell more testing is needed on my part. I’m not sure how Image Optim compresses images, but I did run both sets of images through it after compressing them with Pixelmator.
My iPad does have a retina display, but again while I could certainly notice the difference in quality, I’m not sure I would have been bothered by the lowest quality images had the others not been there to compare to.
I probably need to pay more attention to image quality though and develop a better eye for it. I haven’t had to so I haven’t done that.
My next computer will likely have a retina display. Part of me is excited and part of me is afraid to look at all the images I’ve created over the years to so how they look.
Comparing compression % settings across different programs is like comparing volume settings from speakers. What’s 5 on one speaker might be 11 on another.
What actually happens behind the % setting is that JPEG uses a 64-entry table to decide how much information to discard for each detail size. The % is just a crude way to scale every table entry at once.
So it make more sense to make two files of the same size, even though the quality setting might be completely different, and then compare their visual quality.
You might want to check out this post about Mozjpeg, which is a JPEG library with a focus on image quality and smaller file sizes for the web (at the expense of being slower). http://calendar.perfplanet.com/2014/mozjpeg-3-0/
No difference between the pictures. 1024X768