Digital Colour Spaces: A Simple Analogy Aids Understanding

Updated on August 5, 2019
Fotimageon profile image

An Engineering Consultant and Professional Photographer with 40 years of experience in digital imaging.

The merits of sRGB, AdobeRGB (aRGB) and ProPhotoRGBcolour spaces are frequently the subject of debate and some confusion. Attempts by the novice to understand the principles behind these colour spaces are often hindered by the complex, 3‑dimensional mathematical transforms used to describe them.

A graphical representation of sRGB, AdobeRGB and ProPhotoRGB colour spaces
A graphical representation of sRGB, AdobeRGB and ProPhotoRGB colour spaces

This difficulty can be overcome by referring to a simple 1-dimensional linear analogy which describes 3 fictional methods of encoding vehicle speed, appropriately named (by analogy) sMPH, aMPH and ProMPH. This analogy helps illustrate how image data is encoded and converted between colour spaces and what happens when images are converted or rendered incorrectly. This article concludes with examples of real and synthesised images rendered in different colour spaces.

sMPH

Suppose engineers wanted to record the variation in forward speed of a motor vehicle at 1 second intervals over the duration of each journey. The vehicle has a sensor that provides speed readings from 0.0 to 100.0 mph with 1 decimal place at 1 second intervals. Realising they didn’t need 0.1 mph precision and they needed to minimise the memory storage requirements for long journeys, the engineers decided to store each speed reading in a single 8 bit byte (which can only store integer values from 0-255). They devised a simple encoding method which multiplied the sensor readings by 2.5 and then rounded to the nearest whole number. They called this process “Standard MPH encoding” or sMPH for short.

   sMPH encoded reading = ROUND(2.5 x Sensor reading)

A speed of 100.0 mph can therefore be encoded in a single 8 bit byte with a value of 250. To recover the original data, the process is simply reversed. They called this process sMPH decoding.

   Decoded reading = sMPH encoded reading / 2.5

sMPH encoding allowed speed readings from 0.0 - 100.0 mph to be stored as single 8 bit bytes with values ranging from 0 - 250. The precision has however been reduced from 0.01mph to 1/2.5 = 0.4 mph. This reduction in precision helps compress the data for storage.

Realising that requirements might change in the future, the engineers decided that files of sMPH data should have details of the sMPH encoding/decoding process (“the sMPH profile”) embedded in the file. This would ensure that future users of the data files would know the data inside was sMPH encoded and they would know the correct way to recover (decode) the data.

The sMPH encoding and decoding process is shown schematically in Figure 1.

Figure 1
Figure 1

aMPH

As technology advanced engineers decided that they needed to record speeds of vehicles that could travel faster (up to 125mph) using a similar (1 byte/reading) file format. To accomplish this they devised a new encoding and decoding method which they called “Advanced MPH” or aMPH for short. To cover the extended speed range they changed the encoding and decoding factor from 2.5 to 2.0

     aMPH encoded reading = ROUND(2.0 x Sensor reading)

A speed of 125.0 mph can therefore be aMPH encoded in an 8 bit byte with a value of 250. To recover the original data, the process is simply reversed. They called this process is aMPH decoding.

     Decoded reading = aMPH encoded reading / 2.0

aMPH encoding allows speed readings from 0.0 - 125.0 mph to be stored as single 8 bit bytes with values ranging from 0 - 250. The precision has however been further reduced by the extra data compression from 0.4 mph (under sMPH encoding) to 0.5mph (under aMPH encoding). So although aMPH files can hold data for a 25% wider speed range than sMPH, the precision to which those speeds are recorded has been reduced by 20%.

To allow aMPH files to be distinguished from sMPH files they embedded the details of the “aMPH encoding/decoding” process (the "aMPH profile") in the file. This would ensure that future users of the data files would automatically know the data inside was aMPH encoded and the correct way to recover (decode) the data, and should not mistakenly use the sMPH process.

The aMPH encoding and decoding process is shown schematically in Figure 2.

Figure 2
Figure 2

ProMPH

As technology advanced again it was decided that the system needed to be further adapted to allow speeds up to 150mph to be encoded and decoded. This was achieved by changing the encoding and decoding factor to 5/3 and they called this process Professional MPH (ProMPH for short) encoding.

     ProMPH encoded reading = ROUND( 5 x Sensor reading / 3)

A speed of 150.0 mph can therefore be encoded in an 8 bit byte with a value of 250. To recover the original data, the process is simply reversed. They called this process is ProMPH decoding.

     Decoded reading = 3 x ProMPH encoded reading / 5

Note that using ProMPH encoding has increased the range of speeds that can be stored by 50% (relative to sMPH). But this reduces the precision to which speed is recorded by 33% to 0.6mph. Realising this reduction was becoming significant the engineers recommended that for high precision applications ProMPH data should be stored in double bytes (16 bit mode).

Analogy with sRGB, aRGB and ProPhotoRGB colour spaces

If sMPH, aMPH and ProMPH are conceptually replaced by sRGB, aRGB and ProPhotoRGB and vehicle speed is replaced with richness of colour (faster speed = richer colour), it’s possible to draw parallels between the process described above and those used to store image data.

When an sRGB image file is created, the image sensor data is encoded using the sRGB standard and the sRGB profile information is (usually) embedded in the file so that the data can be correctly decoded automatically.

The aRGB and ProPhotoRGB standards were developed to allow richer and richer colours to be stored in the file, in a similar way to which aMPH and ProMPH allow higher and higher speeds to be encoded.

The power of the analogy becomes clear when analysing what happens when files are decoded using a different standard to that used to encode the data. For example, what happens if sRGB image data is decoded using aRGB profile, or vice versa? These two examples are considered below.

sRGB data decoded using aRGB profile

This is analogous to using the aMPH process to decode speed data which was encoded with sMPH. The effects of this are shown in the Figure 3 below. Note how a true vehicle speed of 100mph has been incorrectly decoded as 125 mph. The decoded data indicates the vehicle is going faster than it really was. Therefore, by analogy, when sRGB data is decoded (rendered) using an aRGB profile, the colours will be displayed incorrectly and will appear richer than they should. The situation gets worse if sRGB files are rendered using a ProPhotoRGB profile as the colours will appear richer still.

Figure 3
Figure 3

aRGB data decoded using sRGB profile

This is analogous to using the sMPH process to decode speed data which was encoded with aMPH. The effects of this are shown in the Figure 4 below. Note how a true vehicle speed of 125mph has been incorrectly decoded as 100 mph. The decoded data indicates the vehicle is going slower than it really was. Therefore, by analogy, when aRGB data is decoded (rendered) using an sRGB profile, the colours will be displayed incorrectly and will appear more muted than they should. The situation gets worse if a ProPhotoRGB file is rendered using a sRGB profile as the colours will appear even more muted.

Figure 4
Figure 4

Missing profiles, profile conversion and profile assignment

If files are correctly encoded and include the relevant profile, incorrect decoding errors shouldn’t occur. But there are various scenarios where problems can arise, or compromises are required.

Missing profiles

If the profile used to encode the data is missing from the file, it's unclear how the data should be decoded. Many systems assume sRGB as a default profile and will apply that profile to decode the data. This is fine if the data was encoded using sRGB, but if aRGB or ProPhotoRGB was used instead, the decoded colours will be rendered incorrectly and will appear more muted than they should (analogous to the scenario in Figure 4).

To avoid creating files with missing profiles it is advisable to embed the colour profile in the image file when saving. Photoshop provides a tick box to “Embed colour profile” when saving images. Photoshop can also be set to give warnings when opening images with missing profiles and ask what to do. These settings are found in the Color Management Polices section of the Edit>Color Settings… menu. It is suggested that all boxes in this section should be ticked, as shown in Figure 5.

Figure 5
Figure 5

Assign profile

Photoshop allows user to assign a profile (Edit>Assign profile…) to an image with a missing profile, or to overwrite the existing profile. This option must be used with caution. Colours in the image will be rendered incorrectly if the profile assigned to an image is not the same as the one used to originally encode the image. Assigning a different profile can be used creatively to make colours appear richer or more muted, but it may be more convenient to adjust the saturation or vibrance sliders instead as these allow more control. However, the “Convert to Profile...” option should be used to change an image from one profile to another without significantly altering the colours.

Convert to profile

Photoshop allows users to convert (Edit>Convert to Profile…) images from one profile to another. This operation works as follows. Firstly the image data is decoded using the original profile, then (after some adjustment if required*) the data is encoded using the new profile. *Although the conversion process may have some effect on the colours in the image, there are various settings that can be used to control any adjustments that may be needed, as shown in the Conversion Options section of the menu shown in Figure 5. A detailed description of the various options is currently beyond the scope of this document, but there are some potential compromises to be aware of.

  • If a ProPhotoRGB image contains a very wide range of colours, then converting to a colour space with less range (e.g. sRGB) will cause some alteration in colour. Colours maybe clipped or de-saturated slightly in an attempt to “squeeze” the larger colour range into the smaller colour space. This process is not reversible. Converting a ProPhotoRGB image to sRGB loses colour information which cannot be recovered by converting from sRGB back ProPhotoRGB.
  • A similar compromise occurs, but to a lesser degree when converting from ProPhotoRGB to aRGB, or from aRGB to sRGB. Again the process is not reversible.

Although these compromises may sound daunting a few key points should be remembered.

  • The visual differences between correctly rendered sRGB, aRGB and ProPhotoRGB images are relatively small. Indeed, on consumer grade monitors and printers, they can be difficult to spot. Even on professional grade monitors and printers the visual difference is often far less noticeable than the relative sizes of the colour spaces might suggest.

    Figure 6 gives an example. This figure was produced by creating ProPhotoRGB, aRGB and sRGB versions of the same RAW image of a Passport Colour Checker Target and then correctly rendering them all in Photoshop and taking a screenshot. Obviously there are limitations in this comparison as all images have been rendered on a monitor with restricted colour space. Therefore, to overcome this limitation I have posted the jpeg files for each image on-line at https://postimg.cc/gallery/1lm43xh4m/ The images can be downloaded and compared on screen or as printouts.

Figure 6
Figure 6
  • The visual differences between incorrectly rendered images are much more noticeable and clearly visible on screen, as illustrated by the Figure 7 below. This figure was produced by creating ProPhotoRGB, aRGB and sRGB versions of a RAW image of a Passport Colour Checker Target and then assigning the wrong profiles to some of them. The central image is a screenshot of the sRGB image rendered in Photoshop using the correct sRGB profile. The surrounding (incorrectly rendered) images are screenshots of the sRGB, aRGB and ProPhoto images rendered in Photoshop with the wrong profile is assigned, as indicated. Note that the differences are now much more obvious than those shown in Figure 6. The jpeg files for each of these images are also available on-line at the URL above.

Figure 7
Figure 7
  • Some of the images on the internet, which are used to demonstrate the differences between each colour spaces, are produced by generating various spectrum gradients in sRGB, aRGB and ProPhotoRGB workspaces using Photoshop. These images need to be interpreted with caution as they contain a large range of mathematically produced colours. These colours are concentrated at the edges of each colour space to deliberately emphasise the differences between each colour space. Such colours can lie outside the range that typical digital cameras are sensitive to, or appear in normal scenes. The spectrum gradient data created by the gradient fill tool in Photoshop is also not encoded (converted) to suit a particular colour space. The same numerical RGB values are simply inserted into the image and then decoded using whatever colour space profile is assigned to the image. Every pixel generated contains at least one colour that is fully saturated (value = 255). This is analogous to filling the vehicle speed data file with values from 0-250 and then examining how each decoding method (sMPH, aMPH or ProMPH) interprets this data.

    Examples of a spectrum gradient crossed with a luminosity gradient (often referred to as a Granger chart) created in each colour space are shown in Figure 8. (16 bit TIFF versions of these images are also available online at the same URL). This extreme test shows clear differences between the colour spaces.

Figure 8
Figure 8
  • Examples of simple spectrum gradients created in each colour space are shown in Figure 9. (16 bit TIFF versions of these images are also available online at the same URL). Again, this extreme test shows clear visible differences between the colour spaces.

Figure 9
Figure 9
  • Comparisons between synthesised images like these are often used to support recommendations to use AdobeRGB or ProPhotoRGB instead of sRGB.
  • However…. the differences between digital camera images of real scenes, taken in RAW format, then processed in each of the colour spaces and correctly rendered, will be less noticeable, especially when viewed or printed on consumer grade monitors and printers. This is illustrated by the following images of a real spectrum created by sunlight passing through a prism and projected onto a white sheet of paper to produce a saturated sweep of natural colours. The RAW image was processed to produce sRGB, AdobeRGB and ProPhotoRGB versions and saved as 16 bit TIFs at the same URL. Figure 10 shows a montage of the three images.

Figure 10
Figure 10

Conclusion

Hopefully the above has provided a useful insight into some of the basics behind digital colour spaces. To conclude I have three recommendations.

  1. Carry out your own tests to determine which colour space best suits your needs.
  2. Ensure that your images are embedded/tagged with whichever profile you select.
  3. Check your editing tools are set to check the colour space of any image opened.

Acknowledgements

  1. Photoshop is a registered trademark of Adobe Systems Incorporated
  2. The graphical representations of sRGB, AdobeRGB and ProPhotoRGB colour spaces in the opening figure were produced using the ColorSync Utility application - copyright Apple Inc.

Questions & Answers

    © 2019 Fotimageon

    Comments

      0 of 8192 characters used
      Post Comment
      • profile image

        Geoff 

        2 weeks ago

        Interesting and informative, and a great analogy using MPH to illustrate how different profiles affect images. Thanks for posting this.

      working

      This website uses cookies

      As a user in the EEA, your approval is needed on a few things. To provide a better website experience, turbofuture.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

      For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: https://turbofuture.com/privacy-policy#gdpr

      Show Details
      Necessary
      HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
      LoginThis is necessary to sign in to the HubPages Service.
      Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
      AkismetThis is used to detect comment spam. (Privacy Policy)
      HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
      HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
      Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
      CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
      Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy)
      Features
      Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
      Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
      Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
      Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
      Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
      VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
      PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
      Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
      MavenThis supports the Maven widget and search functionality. (Privacy Policy)
      Marketing
      Google AdSenseThis is an ad network. (Privacy Policy)
      Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
      Index ExchangeThis is an ad network. (Privacy Policy)
      SovrnThis is an ad network. (Privacy Policy)
      Facebook AdsThis is an ad network. (Privacy Policy)
      Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
      AppNexusThis is an ad network. (Privacy Policy)
      OpenxThis is an ad network. (Privacy Policy)
      Rubicon ProjectThis is an ad network. (Privacy Policy)
      TripleLiftThis is an ad network. (Privacy Policy)
      Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
      Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
      Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
      Statistics
      Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
      ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
      Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
      ClickscoThis is a data management platform studying reader behavior (Privacy Policy)