Colour management for Web Designers

Print Friendly, PDF & Email

Or in other words – why don’t my page elements match my CSS background colours!

Following on from my recent article exploring the basics of Colour Management, I am going to explain the reasons why getting consistent colour throughout your website design can sometimes seem troublesome. From the previous article, we can see why colour profiles are important. They provide information on how the colours contained within an image file should be rendered – not just on your monitor, but on anyone’s monitor.

Remember the sequence of Target Profile > Conversion > Destination Profile. In terms of the world wide web, this usually means

Target profile – This is usually, but not confined to:

  • Un-tagged (un-managed) RGB – the sort of JPEG output you get from Adobe Fireworks. Also, GIF and PNG files are by nature, un-tagged.
  • sRGB Images – most often the result of working in a colour managed application, such as Photoshop. sRGB is actually the standard for the web, but we will soon see how this can cause problems in Safari.
  • Adobe 1998 RGB – usually confined to situations where photographs have been included which have been tagged with the Adobe 1998 RGB profile.

Conversion – whichever default colour engine is being used by the operating system. The differences between the output from these engines, for the purposes of rendering web content is negligible, so don’t worry too much about which engine is doing the work.

Destination profile – This will be the default monitor profile on the end-user’s machine. Most uncalibrated systems just use a standard monitor profile that ships with the operating system. Often wholly inaccurate, but for the purpose of consistency, this isn’t really important. We are just trying to demonstrate how the colour shifts occur within the end-user’s system.

The problem

Graphics created for the internet commonly come in a variety of flavours – Bitmaps (jpg, gif, png), CSS colours, Flash/Silverlight, Java Applications etc. The problems start when an attempt is made to place page elements next to one another that belong to differing sources.

For example, placing a Flash animation smack bang in the middle of a CSS DIV element filled with a CSS defined background colour might look great in some browsers, but in others it appears as an ugly box because the colours in the Flash animation don’t match those of the CSS background.

Understandably, this has caused much hair loss in web design offices over the years!

How colour management affects web pages

We’re going to look at a practical example. The large red box below is a DIV element filled with a CSS background #CC2222 (darkish red). The DIV contains three horizontal rectangles – each one is a JPEG image saved with different colour management data.

No CMS Profile

No CMS Profile

No CMS Profile

In a fully colour managed browser (e.g. Firefox with colour management options turned on) then you should only see one large red box, with three sections of text, perfectly blended in.

However, it is far more likely that you will be looking at one, or two darker boxes for the bottom two JPEG images. This is because of the way different browsers treat the colours displayed within various page elements.

sRGB, CSS and the great Colour Management bun fight

It is said that sRGB is THE colourspace of the web. However, it would appear that the big three see things a little differently, and we will see how things go a bit squirly in the real world:

Internet Explorer 8

How it looks in IE8IE8 doesn’t do colour management, and so it will ignore sRGB (or any other) profiles in images. IE8 (and earlier) renders all RGB content in the monitor’s default profile. Regardless of the profile embedded in the image, IE8 will just look at the RGB values in the object being displayed and send them straight to the monitor without any Conversion. Therefore, the CSS, and all of the graphics get their raw RGB values sent to the monitor.

This means the only box to stand out here is the Adobe 1998 box at the bottom, as it has different RGB values. Because the Adobe 1998 colourspace is larger than sRGB, for an Adobe 1998 colour to appear the same as an sRGB colour, it actually needs to have slightly different RGB values.

In many ways, this could be seen as the best of a bad choice. At least untagged RGB content, and tagged RGB content is all treated the same (which is consistent, if not accurate). However, as can be seen, content which is profiled as anything other than sRGB will not match anything else. It also makes for the most hideous and garish colours on wide gamut monitors (such as the Dell Ultrasharp series).

Safari 5

How it looks in SafariSafari (as much as I like Apple products), have tried to take the moral high ground with regards colour management, and (in my oppinion) completely failed to live in the real world. Safari is arguably, a colour managed web browser. However, if you are using Safari, you are probably looking at the bottom two rectangles standing out.

This is because the CSS background colour, and the un-managed RGB image are both sent straight to the monitor profile without Conversion. Strictly speaking this is logical, as neither colour system has a profile, as such. However, in the real world, it just means that the only way to match CSS colours with bitmaps, is to use un-managed RGB in your JPEG files, or use GIF or PNG files (which are unmanaged by design).

This is particularly annoying as Flash now supports profiles, but you would still have to save your flash output un-managed for it to match any CSS backgrounds.

Firefox 3.6.x (with colour management enabled)

How it looks in Firefox 3.6.xAs I wrote in a previous article about Firefox 3.5 – it is possible to configure Firefox (and 3.6 is now configured this way by default) to treat any untagged JPEG content as through it were managed as sRGB AND to operate in colour management mode. This is nice in many respects because it means that CSS and managed content will all match up.

Any un-managed images will automatically get treated as though they were sRGB, and any managed content is displayed with its profile intact and respected.

Great! So, lets all use Firefox, and our colour management woes will be forever a thing of the past! Not quite – there is one caveat – any un-managed Flash content will still be rendered in the monitor’s default profile, so it would stand out like a sore thumb! You can’t win then all.

So where does this leave us?

Well, at the moment, for consistency sake (not accuracy), it may be safer to produce your entire website in un-managed colour. This means not assigning any colour profile to any graphics that you will want to match surrounding CSS design elements. In Fireworks this doesn’t matter as it does not apply colour profiles anyway. I can’t really speak for other applications, but if you leave everything untagged, then the results will be more consistent (although horribly over-saturated on some monitors).

Making Photoshop play dumb

If you use Photoshop, then just make sure that you are using the option to “Don’t color manage this document”, otherwise you may inadvertently apply a profile to your output. You may notice in Photoshop that the colours on screen may look more subdued than they appear in Fireworks or in a browser. This is because Photoshop is Colour Management aware and is correctly trying convert the colours to your monitor profile.

If you want photoshop to operate and display the same colours as Fireworks (i.e. unmanaged), then firstly, make sure you are in RGB mode (obviously!) Then choose View > Proof Setup > Monitor RGB and then make sure View > Proof Colors is ticked. Doing this sends the RGB values directly to your monitor device without any adjustment.


No comments yet.

Leave a Reply

Bot test * Time limit is exhausted. Please reload the CAPTCHA.