Practical Colour Management for Designers and Developers Using Sketch
In this article, we will explore the topic of colour management through the lens of two particular issues app designers and developers routinely deal with if they use Sketch in their workflow:
- Overly saturated colours in Sketch on newer Mac displays or wide-gamut external displays,
- Colours seen in app not matching those in Sketch designs.
It turns out both of these issues have a common cause in the realm of colour management and a very simple solution. When one reads Sketch documentation on the topic, it probably leaves them wondering whether their project does call for colour management or not. This article demonstrates practical implications of ignoring colour management and offers two simple rules that ensure correct colour rendition in both Sketch and app builds.
Prerequisites
In order to understand the rest of the article, it’s important to understand the concept of colour space. Wikipedia defines a colour space as a specific organisation of colours that in combination with physical device profiling allows for reproducible representations of colour. One such system of colour organisation — sRGB — is of particular interest for our purposes as it’s been a colour specification industry standard for digital media for the past two decades. Whenever we encounter a hex colour value such as #AE0000, it's implicitly assumed that the value must be interpreted in sRGB colour space (unless specified otherwise). Web browsers and image viewers usually assume sRGB for images that do not include any colour profile.
CCI-P3 is a colour space that includes all of sRGB and introduces more saturated reds and greens compared to sRGB. It has been widely adopted in consumer displays (in smart phones, tablets and desktop computers) as well as in ultra-high definition television standards.
Over-saturation on wide-gamut displays
With rapid adoption of P3 wide-gamut displays, Sketch users started noticing odd things happening with colours in their documents: reds and greens would look much more saturated on those P3 displays than on older Macs and regular sRGB displays. The reason for that is, Sketch was not colour managed until version 48, and documents remain unmanaged by default even in newer versions. Colour values used in the documents are interpreted in the colour space of the display which used to be considered “okay” as most displays’ colour profiles resembled sRGB standard anyway (although of course this has never been correct with regard to colour reproduction). The problem with interpreting a given value in a different colour space is that it means a different visible colour there. In case of displaying what was implicitly considered an sRGB value in P3 colour space, Fueled red #AE0000 interpreted in P3 means a much more saturated colour #BF0000 in sRGB. In general, different displays would represent the same colour in Sketch differently because the display’s colour profile would not be taken into account.
Here’s roughly what the colour difference would be if we put a regular sRGB LCD monitor and a wide colour P3 monitor side-by-side with a colour-unmanaged Sketch document on them.
Some people have solved that issue by assigning their monitors sRGB profiles or switching the displays to sRGB mode where such option was available. The problem with this approach is that this is how the expensive professional-grade hardware no longer delivers the wide colour range it’s built for. Not only that but the sRGB profile is not any device’s actual profile, so the colours will be guaranteed to be off, even though it solves the over-saturation problem.
Fortunately, the correct solution is simple. Starting from version 48 Sketch is colour-managed. Every document can now be assigned a colour profile and the colours in the document are correctly translated from the colour space of the profile to the colour space of the display according to the display’s colour profile to ensure faithful colour reproduction (assuming the display’s colour profile is correct).
The following table illustrates how #AE0000 colour is affected by standard colour transformations and what is actually seen on screen (assuming the colour profiles are true to the monitor in question; which normally needs to be ensured by colour calibration process).
In both cases of unmanaged colour, colour values are sent to the display as they are in the document which means — assuming the displays’ accurate profiles are Color LCD and Display P3 — that the observed sRGB value can be derived from the input colour value by applying a transformation from the monitor’s colour space to sRGB (which is defined by the display’s colour profile).
When colour management is enabled, the colour specified in the document is interpreted in the colour space assigned to the document and display’s profile transformation is applied to that colour before it’s displayed which results in a correct colour on screen. Again, if we apply the reverse display colour profile transformation, we will get exactly the colour specified in the Sketch file (in practice, if we use system eye-dropper or Digital Color Meter app to check the colour, there may be minute difference in hex values due to floating point calculation errors).
Should vibrant P3 colours be desired by the designer, the document should be assigned a P3 colour profile in Sketch. In this case, if predefined sRGB colours need to be used (e. g. brand colours from existing brand guidelines), their hex values must be converted to P3 to preserve perceived colour unless particular brand guidelines prescribe otherwise (the same hexadecimal value might be favoured over a correct colour conversion or a new colour altogether may be prescribed for wide colour displays). Here’s how #AE0000 / srgb(174 0 0) could be converted to its P3 #9F2015 / p3(159 32 21) using Color Sync Utility's Calculator that ships with macOS X.
Google can be used to perform hexadecimal ↔ decimal colour format conversions: typing rgb(174, 0, 0) in the search field will yield #AE0000 and vice versa. Note how the digital representation is colour-space agnostic, so you can use the converter for both sRGB and P3 values.
Design preview
Once colour management is taken care of (including monitor calibration and viewing environment of course), we can hope for faithful representation of colour we work with in Sketch but there will still be discrepancy between what is seen on the Mac and what is seen on device. Part of it may be due to lack of calibration, part due to display settings like brightness (I am more likely to have my phone on max brightness than my laptop). These are the reasons it’s always a good idea to review designs with Sketch Mirror. Our testing has revealed that Sketch mirror behaves correctly with regard to colour management in all currently available configurations: 1. Unmanaged Sketch documents will be displayed in sRGB (which is usually implicitly assumed) on both legacy iOS devices and newer wide-colour ones (iPhone 7 and newer iPhones, iPad Pro 10" and newer iPads). 2. Colour-managed Sketch documents will be displayed according to their assigned colour profile and devices screen capabilities.
Verifying design execution
It’s not uncommon for an app developer, designer, or a QA specialist to take a screenshot of an app design in Sketch, put it next to a screenshot of an actual build of that app and wonder why the colours are different. Why indeed?
The problem may be manifold, and we will try to list what can go wrong, so it would be straightforward to check and rectify.
Picking and specifying a wrong colour value at development stage.
Developers often use screen colour pickers (also known as eye-droppers) to pick a colour from the design. Bad news is, even if the user knows what they are doing, eye-droppers will return incorrect colours in some circumstances if not always.
TL; DR. Do not ever use colour picker apps to collect colours from designs (be it Sketch or Photoshop).
How can colour pickers be wrong?
- Colour value may be collected directly from screen which is a representation of the colour in a specific device’s colour space. We can see in Figure 1 how this leads to a wrong value if we interpret it in sRGB (which we usually do): we miss a inverse transformation from the device colour space to sRGB.
- Even if the collected colour is transformed correctly back to sRGB, there may be additional floating point errors introduced by the reverse transformation process. This behaviour has been observed on a P3 MacBook Pro with a standard P3 colour profile using Apple’s Digital Colour meter set to display values converted to sRGB. A 2014 MacBook Pro with a standard Color LCD profile did not exhibit this behaviour and the Color Meter app displayed correct sRGB values in my tests. The introduced errors may be insignificant and practically imperceptible but are still not desired when working for example with brand colours where preserving the exact hexadecimal value is considered important.
How to pick a correct colour?
We cannot talk about accurate colour reproduction in the builds if the colours in the design change based on the display the design is viewed on. Therefore the colour space of the Sketch design document must be fixed by assigning the document a colour profile. These days, it would typically be sRGB. Once this is done, the developer’s job is easy:
1. Recognise design document’s colour space using ⌘+Shift+K shortcut in Sketch
2. Take a hexadecimal value directly from the element’s colour selector.
Specifying correct colour space in Xcode
Now as we know the colour space and the colour’s RGB value, there are only 3 possibilities to specify a colour in Xcode.
1. Explicitly in storyboard.
Apart from specifying the colour hex value, we need to ensure the colour space is also specified correctly by clicking on the little gear icon in the system colour picker and selecting sRGB colour profile as shown in the second screenshot. Note that the colour space needs to be selected before we specify the colour value, otherwise the RGB values will be converted to sRGB from the previously selected colour space. So the process should look like this:
- Select/confirm colour space
2. Select/paste RGB value.
It appears sRGB is the default profile these days but legacy projects used to use Device RGB placeholder which will result in completely different colours seen on iPhone 6 and iPhone 7.
Here’s what to look for in existing projects’ storyboards:
When the colour is specified in sRGB, this storyboard source code will look like this:
In case of P3 colour profile in Sketch, the same process applies with Display P3 colour profile specified in Xcode.
2. In asset catalogue (iOS 11+)
Xcode 9 introduced named colours — a feature that allows to specify colours as named assets and specialise them depending on various device features including naturally screen colour space.
Those named colours can then be used from both storyboards and from code.
3. In code
If Sketch colour profile is sRGB, nothing needs to change whatsoever when creating UIColor objects as those use so called extended sRGB colour space which approximately coincides with sRGB in 0–1 colour component ranges, so the same values will result in the same colours on both iPhone 6 and iPhone 7 and on.
If the colour space of the Sketch document is P3 and named colours cannot be used (say, if iOS 10 support is required), then developers need to resort to a new UIColor initialiser init(displayP3Red: CGFloat, green: CGFloat, blue: CGFloat, alpha: CGFloat). Note that the old custom init(hex: Int) convenience initialisers will not work correctly without modification for P3 colour values.
What can we meaningfully compare?
Now that we finally specified colours in the app. How do we visually verify the results against the designs? How do we avoid the confusion of seeing different colours? Naturally, the most practical way of quickly verifying colour accuracy is by looking at a screenshot of the app side by with the design. This only works reliably under 2 conditions:
- The screenshot is taken from an iOS device unmodified (simulator works in case of sRGB colours but should generally not be considered reliable due to considerations below)
- Sketch document is colour-managed.
Once these conditions are met, both visual comparison and exact screen colour comparison using an eye-dropper will be correct.
More precise verification methods include combining a Sketch export with an actual app screenshot in Photoshop as layers with Difference blending mode.
iOS Simulator screenshot considerations
Disclaimer: the following paragraph is a hypothesis verified only with a few experiments. The information in this section is not based on official documentation, can become outdated at any time without notice and cannot be relied upon.
It appears that iOS Simulator is not properly colour managed: simulators appear to respect sRGB colour values but colours in other colour spaces seem to be converted to something like Generic RGB and assigned sRGB profile anyway in screenshots regardless of the simulated device type and the Mac screen used. This means that sRGB colours should look correctly but P3 colours will be distorted and will look desaturated.
iOS device screenshot considerations
When we take a screenshot from an iOS device, the resulting image is assigned sRGB or P3 colour profile depending on the device screen type. Note that this information can be lost if the screenshot is exported and sent over email or AirDrop (in which case the image will have sRGB colour profile unconditionally). In order to get the screenshot unmodified, we can use Image Capture app or export the screenshot’s original from iCloud photo library on the Mac.
Summary
In order to make colour to appear correct on developer/designer work stations and on iOS devices, we need to follow 2 simple rules:
- Sketch design document should be colour managed.
- Developers should specify colours in Xcode along with the colour profile assigned to the Sketch design document.
