High Resolution (ii)
A few tests; a few observations; and further thoughts on things like compression, kilobytes and consistency …
A few tests; a few observations; and further thoughts on things like compression, kilobytes and consistency …
The observations below were based on a comparison of sample images on various screens, and further tests done for a client using in-house image resource. It's far from a comprehensive survey but did make for some interesting observations…
I included typography in the test images to assess scenarios where a palette of typography that goes beyond system fonts is a requirement.
@2x images at low percentage compression rates as low as 10% do surprisingly well across the board for desktop, retina and non-retina displays.
If there are large areas of a flat tonal bg colour or even texture (similar tones blending into one another) the gradation can get quite pixely and blocky on @2x images particularly beneath 30%
Unsurprisingly there's a lot more scope for compressing images that don't contain typography. In some cases there may be a case for using hi-res gif for certain areas that include text.
To obtain sharp readable text the image is best served at original size or @2x size. Scaling from other over-sampled sizes gives less crisp, even blurry results for text in particular.
Choice of antialiasing settings in photoshop is a factor worth considering. I find sharp or crisp tend to give best results for @2x images
On Desktop and webmail double size images and over-sampled images at varying degrees all resized well. A slight drop off in crispness of text was perceivable compared to standard sizes.
if viewed on cellular network proxy server compression can mean the already highly compressed images look like total junk. Though this isn't an issue limited to high res assets. These inconsistencies are something I'm trying to learn more about.
Overall results are pretty positive with the a few caveats mainly in regard to images that contain typography.
On the whole an @2x image will require an increase in the kb size but with heavy compression it doesn't have to be significant.
I didn't quite experience the kind of positive results suggested by Daan Jobsis's tests. I see in subsequent comments it was suggested some flawed testing approaches had been used (not saving for web; control images not at full size in test) which might explain things.
JPEG Mini and Image Optim don't cut much off the image size when they're already compressed for web.
RIOT may be another option I'm yet to explore. My only experience of it so far is the viruses the downloaded introduced to my girlfriends PC. At least, that's the story I'm sticking with :)
Even if it becomes viable at some point in the future to create two sets of assets where we only serve the larger versions to retina devices - that will require some increase in production time which may not be practical.
Perhaps these issues won't seem immediately pressing in the world of email (and depending on subscribers current devices of choice) but if we're heading to a place where a high proportion of devices eventually 'go retina' and we care about their experience then these are matters that ought to be considered.
It's also about getting in the mindset of the technology/techniques/testing informing the campaign to get better results. For example if I know I can get a lot more milage out of compressing a very busy detailed image with multiple tones than one with flat tonal imagery that might inform the resource created for a campaign and how we set that up to create maximum inbox impact.