Let’s Define Image Resolution
Unfortunately, there are many definitions. There’s no organisation, or consortium defining what Image Resolution actually means.
The generally accepted correct definition is the following:
The detail an image holds.
Many people believe that image resolution is about image size – for good reason. We’ll come to that.
If you were driving your car and you saw a billboard several kilometres away. You’d be very unlikely to resolve what was printed on that board. The closer you get to the board, the more you will be able to resolve the information the billboard holds.
The following statement has more relevance now in the age of high pixel density screens:
Resolution is dependent on the distance you view an image from.
For example, a billboard is not meant to be viewed from one metre away. A screen on an iPhone X is not meant to be viewed at two metres away.
Hardware Pixel and Reference, or CSS Pixel
There is now something called the Reference, or CSS Pixel. In the days before high pixel density screens, and it wasn’t that long ago, we only cared about the Hardware Pixel or Device Pixel.
The Reference Pixel or CSS Pixel is important for Web Designers, as they need to create different image sizes depending on the Pixels Per Inch, (PPI) of a screen viewing those images.
The Reference Pixel is based on the distance from the eye you view the image from and is dependent upon the Pixels Per Inch, (PPI) of the device’s display/screen.
The Hardware Pixel is just the smallest addressable element on a display or screen.
In the days before high pixel density displays, only the Hardware Pixel mattered, because resolution varied very little across devices. Most web browsing was done on desktop computers, whose resolution varied relatively little.
The W3C was working on the Reference, or CSS pixel long before high pixel screens came about. This is from the W3C site:
Without delving into the math behind this statement, we can work out the Device Pixel Ratio like so:
Calculating the Device Pixel Ratio
Suppose a smartphone has a screen with a physical pixel size of 180 pixels per inch (PPI). Calculating the device pixel ratio takes three steps:
- Compare the actual distance at which the device is normally held away from the eye to the distance for the reference pixel. The Reference Pixel specification states that at 28 inches away from the eye the ideal PPI is 96 PPI (pixels per inch). However, since it’s a smartphone, you hold the device closer to your face than you view a Laptop for instance. Let’s assume that distance to be 18 inches.
- Multiply the distance ratio against the standard density (96 PPI) to get the ideal pixel density for the given distance. ideal pixel density = (28/18) * 96 = 150 pixels per inch (approximately)
- Take the ratio of the physical pixel density to the ideal pixel density to get the device pixel ratio. Device Pixel Ratio = 180/150 = 1.2.
The creation of an image x1.2 scaled image would not be practical. But, if you wanted to ensure every possible device is supported, yes create an x1.2 version. Most Web Designers would follow this scale range: x1, x1.5, x2, x3, x4. As of December 2017, that scale range would be practical and cover most, but not all devices. A lot of designers will only supply two scales: x1, and x2.
There are websites who list what devices are the most popular at the moment. Would you bother creating an image with a scale of x1.2 for a device that has a market share of 0.10 pct?
Simple Analogy of the Device Pixel Ratio
If a CSS pixel isn’t based on hardware and it’s relative, then what is it relative to? It’s relative to you. Specifically, the size of a CSS pixel is relative to both the viewer’s eye and the viewing distance to the screen.
The CSS or Reference Pixel is actually an angular measurement. If that doesn’t make sense, here’s an analogy. If you see a full moon and you hold up a coin you can block the entire moon, even though the moon is millions of times larger than a coin.
Of course, that’s because the coin is closer to your eye.
As you move the coin closer to your eye, it takes up a larger angle of view in your field of vision until the coin equals the angle of view that the moon takes up.
The CSS or Reference Pixel uses the angle of view in a similar way. It assumes a device with a pixel density of 96 PPI, held at arm’s length which is 28 inches.
The visual angle of a pixel at that distance turns out to be about 0.22 degrees, and that angle is the basis for working out the size of the CSS Reference Pixel on any size screen.
For screens held closer to the eye, the visual angle is smaller so the CSS Reference Pixel is also smaller. For screens viewed farther away from your eye, like a television or projection screen, the visual angle is much larger.
Apple was first with Retina Screens
Mobile devices have made a quantum leap in terms of pixel density. Driven initially by Apple with the advent of the Retina screen, with every device manufacturer following suit.
The idea behind Retina is to make the screen crisp, and resolvable at roughly 12 inches from the eye. This required Apple to up the pixel density of their screens, hence Retina was born.
By the way, Retina is a proprietary name, and not a standard as such.
The idea behind CSS pixel ratio is due to devices increasing their screen PPI each year. If every device still had a CSS pixel ratio of one then web pages would render too small for comfortable viewing.
A typical full-screen desktop screen is a roughly 24 inch at 1920 x 1080 resolution. Imagine if that screen was shrunk down to about five inches, but had the same resolution. Viewing things on the screen would be impossible because they would be so small. But manufacturers are coming out with 1920×1080 resolution phone screens consistently now.
Retina and High DPI screens cause problems for Web Designers
Take an old Desktop with a screen resolution of 1024 x 768 pixels. Serve it an image of 1024 x 768 pixels – it fills the screen. Take the same 1024 x 768-pixel image, and serve it to an iPhone X, with a resolution of 2436 x 1125 pixels on a screen size of 5.8 inches, with a PPI of 458 – it would be small
But, because the iPhone X browser has a Device Pixel Ratio of 4, it will, if necessary, make the image four times larger in the browser – possibly degrading the quality.
In the early days of the Retina screen on Apple iPhones, the Safari browser doubled the size of the image (x2 Device Pixel Ratio), if it had to.
Basically, Apple was running the show and deciding how they would overcome the problem caused by the introduction of the Retina screen, by just doubling the size of images. What they did basically was squeeze everything down on to a 980-pixel grid. A website would be readable with maybe a bit of pinch zooming. Images were just doubled in size by the Safari browser if necessary. This was basically a short-term fix by Apple.
Important: resizing only takes place if it has to. If you serve a sufficiently large image in the first place, the degradation caused by web browser upsizing would not occur.
It is best to serve different size images for different devices. For web designers, this ‘size issue’ is a big deal. To make an image resolvable on varying pixel density screens, it might require three different pixel dimensions, for just one image.
What happens in reality
A device’s web browser (User-Agent) reports a Device Pixel Ratio or CSS Pixel Ratio. For the Safari web browser on an iPhone 4, that would be x2. That means for 4 hardware pixels there are 2 CSS pixels.
The iPhone 4 which has a physical screen size of 960×640 hardware pixels, the web browser’s viewport is actually 480 x 320 Reference/CSS, or logical pixels – which makes the iPhone 4 an x2 Device Pixel Ratio. Your lovely photo now could be doubled in size and would look blurry at the very least. Only, and this is very important if the image wasn’t large enough in the first place.
As we no longer need to give an image size via the HTML img tag, for Responsive websites, the picture is sized how we decide using relative measurements.
Browser Re-sizing it’s not all bad
We could just use one very large image, 4000 pixels on the longest edge let’s say and let the web browser do the resizing. At this size, there are very few screens that would need to upscale this image. But, it is very likely to be downsized. Downsizing, even via the web browser, is less detrimental to an image than upsizing. The problem now is – if the web browser does the downsizing, you are still downloading a large file unnecessarily, which is not good practice.
The different sizes for each individual raster image have to be created using a graphics program like Adobe Photoshop. So you would have an x1 image, for normal screens where 1 CSS Pixel = 1 Hardware Pixel. Then even an x1.5 image, and so forth up to x4 – as of late 2017. Who knows there could be x5 soon. Experts say there comes a point where high pixel density screens will be pointless after a certain PPI density.
The World Wide Web Consortium has not recommended (ratified) any method yet using CSS. And don’t forget, web browsers are owned by companies, and they often go their own way until W3C fully recommends a method.
In the meantime, it’s a bit of a hash, where things called polyfills are used to cope with cross web browser issues and old web browsers.
Responsive Web Design
Put simply it means everything on a page is sized and delivered relative to the Viewport (the actual screen size of the web browser).
Responsive web design is about using relative measurements that change the way the page behaves on different screen sizes.
The web browser (User-Agent), on the device, tells the webserver it’s Viewport size. The Web Server delivers content based on that Viewport size using Media Queries.
Media Queries are based on fixed pixel breakpoints to present the content in a different way based on the viewport width. There might, for instance, be four breakpoints, based on average Viewport sizes. In other words, the layout will change as the viewport gets wider, or narrower. What this means, in reality, a three-column web page on a desktop computer will end up as a one-column web page on a mobile phone.
The common breakpoints are:
- 320 pixels
- 480 pixels
- 768 pixels
- 1024 pixels
So, if you were to resize your web browser now, there will be set pixel width breakpoints where the page might change from a two-column page to a one-column page. It’s very unlikely that a responsive webpage would look good on all mobile devices due to the limitations of fixed breakpoints.
All this relativity is fine for fonts, and vector graphics like the SVG (Scaleable Vector Graphic) format. But, for raster/bitmap images, we have to serve different sizes depending on the width of the Viewport, if we want our images to remain crisp.
What happens as of 2017 is this:
- Everything is reset to override any web browser settings, like stylesheets.
- Any web browser scaling is reset to x1 Device Pixel Ratio to stop the webpage from being resized.
- Media queries are used with fixed breakpoints, to serve content based on the Viewport’s width, height, or orientation.
- Fonts are sized using relative measurements and dictated by a Media Query. In this respect, they behave like vector graphics.
- Ideally, different size raster images are served according to the viewport size, and Device Pixel Ratio. The higher the pixel density of the screen, the higher the scaling. It’s currently up to x4 as of 2017,
- To cope with web browsers having different methods for delivering High PPI images many will stick to one method and use Polyfills to support the older Browser (User Agent).
As I mentioned earlier, there are issues with some web browsers (User Agents). Especially older versions of Internet Explorer. There will come a point when the web designer will not support these old browsers. So if you’re still running Windows XP, with Internet Explorer 6, you might have problems viewing modern responsive sites.
So saying that image resolution is the amount of detail an image can hold is irrelevant as far as the Web is concerned. Size matters.
The web does not judge the quality of your image, that’s irrelevant.
Let’s say there are two cameras, one in a mobile phone, the other in an old bridge camera. They both produce images of 1024 x 768 pixels. But, the mobile phone has a much smaller sensor, and cannot capture much of a scene’s dynamic range as the bridge camera. The larger sensor of the Bridge camera can capture more of the dynamic range of the scene. But, both the bridge camera and the mobile phone produce images of exactly the same size.
As far as the web browser is concerned, or any Graphics program – they both have the same pixel resolution.
Let’s take a JPEG as an example, we can bring the quality right down, and even introduce artefacts, but the pixel dimensions will remain the same.
Quality decisions are for us as designers, or photographers
Pixel Dimensions, on the other hand, is what a screen cares about.
Size is the only factor considered by a web browser, AND when going to print.
Image PPI does not matter to a screen – Size Does
I’ve put that in bloody red for a reason – it is misunderstood by many.
This is the rule followed by many people
- 72 PPI for screen
- 300 PPI for print
Let’s take number 1., the ’72 PPI for screen’. Here are some current screen PPI’s as of 2017.
|Device||Screen Pixel Density (PPI)|
|Apple Watch 42mm||326|
|iMac with Retina 5K Display 27 inch||218|
|Samsung Galaxy Note 8||521|
|Samsung Galaxy S7 Edge||534|
Is 72 PPI is right for all these different devices? The answer is: it doesn’t matter in the slightest to a screen what you set the PPI at.
An image with pixel dimensions of 1024 x 768, is just that. The fact that this image has metadata embedded saying it’s a 72 PPI file, does not mean jack to a screen, or display.
The PPI of an image in Photoshop, or Lightroom, is NOT relevant when outputting to a screen.
The 72 PPI is a hangover from the early days of Apple monitors, and from the use of Drum Scanners – it’s a long story, and not relevant. Keep your images destined for screens at 72 PPI if you want, you’re doing no harm.
As for number two. PPI does matter to a printer. But the relationship is still dependent on the image’s pixel dimensions. 300 PPI is seen as a benchmark for quality prints. What you are basically saying is, represent 300 pixels with dots of ink, or lines of ink on one inch of paper. How the printer does that is beyond the scope of this article, and it also varies between printers.
Some print bureaus only print at 300 PPI, so we are kind of stuck with it as photographers. But I’m absolutely certain that most billboards are not printed at 300 PPI, that would be prohibitively expensive. Again the distance you view the image from is important. Does a photograph need to be printed at 300 PPI, if it’s being viewed from 15 feet? I would love to hear from someone in the printing industry as to why we are stuck with this 300 PPI benchmark.
Put simply, an image of 300 x 300 pixels, output at 300 PPI, would print at 1-inch x 1-inch – it’s as simple as that. If I wanted to print that same image at 2-inch x 2 inches, I would have to resize it using Photoshop, or Lightroom. That would mean that Interpolation would take place with Photoshop, or Lightroom in filling the gaps made by making the image larger. This interpolation, or resizing would result in some loss of detail, however small. But, guess what, I now have a 600 x 600-pixel image – so size matters.
Sorry for the digression into printing and PPI, but it’s got wrong by many people.
Quality is down to you
If you are doing all the right things with your camera, you should be producing great-looking images on a screen in Photoshop, or Lightroom. Now you have to put them on the web and in different sizes. We now have to do lots of web browser testing on different devices and tweak our images, and content constantly to see if the site renders properly on different mobile devices.
Unfortunately, Lightroom is not really equipped to cope with outputting different size images for the web, whereas Photoshop is. But you can do it in Lightroom, it just takes longer.
Save for Web is now a legacy option in Photoshop as of 2017. It’s now become Export As. You now have the option of creating x1, x1.5 x2, x3, x4 images. It suffixes the file name like so: @x2, @x3, and so on. Only the x1 version does not have its file name suffix.
Many people currently stop at x2 and don’t bother with x1.5. In other words just two sizes for one image.
W3C is trying to move away from web too reliant on raster images, and make readable content the key component of a website. And Google is trying to make content creators go the same way. Google doesn’t say it outright but it hints that sites that take a long time to download could get penalised in the search listings. Using large images could get you spanked down the search rankings. So if you’re a photographer, or designer you going to have to do a lot of soul-searching. Some JPEG images can be taken down to 40, or even 30 quality settings. Some JPEG’s would lose data integrity around 60. So, every image will need to treated differently in terms of quality on output.
My front page is a slider with large files. I want to show off my photographs, so I’m willing to take that risk.
My JPEG quality setting lowest limit is usually 40 in Photoshop. In hindsight maybe 30 probably would have been fine for a lot of these images on this website.
These are your choices
- Just use one large file, and let the web browser do the downsizing. And hope the pixel dimensions are large enough to stop upsizing. But you would be serving an unescarry large file to devices that don’t require it.
- Just use two sizes. The normal x1 size, and an x2 size. Not bother with x3 or x4.
- Use x1, x1.5, x2, x3, x4, to make yourself future proof now.
- Use one image crushed right down in the quality settings (for maximum download speed), and the right size for an x1 screen, and don’t worry about lack of quality when the image is up-sized in the web browser.
This is not an easy subject. And, if I come back to this subject in three months time, I would have trouble explaining it.
The method you use when creating your site for images destined for high-density screens is far from being Recommended (ratified) by the W3C as of late 2017. Current methods for image scaling could be obsolete in two years time.