The United Colours of Ubuntu

The lovely new grown up and professional branding of Ubuntu is great, I love it. The new Ubuntu Community Orange is great, however what colour is it exactly? Well looking at the design toolkit the official colour is an RGB hex specification of #DD4814 or a CMYK specification of  C0 M79 Y100 K0 or the Pantone colour 1665. So three different specifications, but they should all amount to the same thing surely? Well . . . no. If you put #DD4814 into Gimp or Inkscape or any Ubuntu app with a colour picker really, and then flip from RGB space to CMYK you will see that it corresponds to C0 M67 Y 91 K13. So is the design guide wrong? Well having discussed it with the design team they assure me that when actually printed on stuff C0 M79 Y100 K0 is absolutely the right colour  to match the screen colour of #DD4814.

Now in an EPS (Encapsulated PostScript) file you can specify colours in several ways including the pantone colour. Here is a screenshot of various files from the design toolkit opened in Ubuntu. First a PNG specified in hex as #DD2814, then EPS files with the Ubuntu Orange colour specified as CMYK, RGB and as a Pantone colour.

Quite a spectacular range of colours really! So is Ubuntu getting this all wrong then? I asked someone who still has a Windows machine to try the same thing. . .

That is Adobe Illustrator showing the EPS files and Windows picture viewer for the png. So a different range of assorted colours from the same files! How about a Mac, designers use them, they must get it right!

Yet another collection of colours (not entirely sure of the order of the EPS files, but the .png is the one that opened in the browser).

So it seems that colour matching across images and operating systems is in a confusing and contradictory state of affairs. Personally I think Ubuntu gets it right, stuff generated in an Ubuntu app with #DD4814 can then be printed to a PDF and it is still #DD4814. PDFs produced by the designers seem to have the colours not quite right. This evening there is an Ubuntu Developer Summit session on colour theory and the Ubuntu palette where the plans for colour will be discussed. Should be an interesting session.


  • John P says:

    You need to consider what the various colour specifications mean.

    The hex code specifies relative proportions of Red Green and Blue light (specifically since it’s meant for sRGB, proportions of the sRGB primaries).

    The CMYK and pantone values specify ways of putting ink on paper to make the required colour. The first specifies proportions of standard cyan, magenta, yellow and black ink to be screened onto paper, the latter a specific formulation of orange ink standardized by the proprietary pantone system.

    Since your monitor can’t display ink (no matter which OS you run), display applications are attempting to simulate the colour on a monitor. How close their soft-proofing gets depends on any ICC profiles used and how well calibrated your display system is.

    If you want to see the correct colour on screen, use the RGB spec and a monitor correctly set up to sRGB. You only need CMYK/Pantone if you’re planning to print the content via a printing service setup to use a particular standard.

    • Alan Bell says:

      Yes, I totally understand all of that. This is about colour calibration and matching. My thoughts would be that with the correct colour profiles set up you would be able to start from an RGB colour, flip to the CMYK colourspace through a totally sane algorithm, then print to a printer with a calibration profile correctly set and have that match what you see on screen. That does not work. Another interesting scenario is starting with a screenshot of #dd4814 on it and printing it out on a page that also includes what is supposed to be the same Orange. What happens? Will it match? Right now, probably not.

      • Jef Spaleta says:

        The only issue here I guess is, is the algorithm that converts from RGB to CMYK in the applications like gimp and inkscape performing that conversion correctly?
        You could use completely separate implementation of the algorithm to check that across the colorspace. For example:

        Just a quick check myself and these online tools agree with the conversion calculations you saw gimp and inkscape doing. Though you should do your own check. Something sure seems something has been miscommunicated in the original conversion between RGB and CMYK.


        • Alan Bell says:

          yup, that is my point! If you use Ubuntu (or any Linux, but hey Ubuntu is the topic of discussion) and start with an RGB colour #dd4814 in a Gimp image you can flip to CMYK, import to Inkscape, make a PDF, take a screenshot of that PDF, embed it in an document, convert it to another PDF and do any other mangling workflow you can think of and at the end of it all the Gimp colour picker will tell you that the colour is still #dd4814. If you use Mac or Windows you will be all over the place with multiple colour profiles in applications creating feedback loops and taking your colour who knows where! On Linux with our lack of colour management everything *just works* (with the possible exception of it displaying and printing “right”) I think that on the proprietary platforms the app vendors who wanted colour management built it into the applications because they needed it and didn’t have access to put in in the right place. Monitor calibration belongs in X, printer calibration belongs in CUPS, scanner calibration belongs in SANE. Apps and users shouldn’t have to care about calibration and colour profiles ever.

          • Jef Spaleta says:

            Excuse me if I find it deeply amusing that the root cause of this miscommunication could comes down to the fact that the paid designers working to design the premier open source user experience were themselves using proprietary tools on proprietary platforms to do their work. Is that irony or just tragedy?

      • John P says:

        Perhaps the problem is expecting them to match, apart from in rather specific cases. Colour science is a complex thing: the eye is sensitive to a spread of frequencies which go to produce your experience of colour; monitors emit three particular ones, inks reflect a different set, and how they look depends on the illumination (if your printout happens to match your monitor in sunlight, try closing the curtains and switching on the lights — it won’t any more). The gamut of colours on your monitor is different from that of your printer, and when you print your document you don’t usually want colours to be mapped exactly or the out of gamut colour will look bad.

        There is no simplistic answer. The naive algorithm which gimp uses to map to CMYK and back are not of any practical use; keep your data as RGB until you have a reason to use separations, then use the separation algorithm specific to the print press and process you will be using (with names like “ISO Coated v2” or “US Sheetfed Uncoated”). Seriously, if you’re not printing to a four colour separation process don’t convert to CMYK! Your inkjet printer may use CMYK inks but from a driver/colour management PoV it’s an RGB device.

        There is some good Colour Management Software for Linux (littleCMS, Argyll) and a few applications with good colour management support on Linux, for example Scribus. And there are people working to improve the integration with the desktop environment, projects such as OpenICC and Oyranos.

        One issue in the free software world is with getting reasonable default printer profiles for the Guttenprint drivers. Suppliers distribute generic profiles for their own drivers and printers, but they’re only valid for that particular rasterization system. The work to profile all the printers linux supports through guttenprint would be huge, but expecting all but the most committed individuals to profile their own printers is too much.

        In conclusion, don’t trust the GIMP to convert RGB to CMYK for you — it doesn’t mean anything. For that matter Canonical’s CMYK values should really be saying which process they’re aimed at. While Pantone does provide an exact specification of the colour meant, since Pantone colours aren’t licensed for Linux it’s not much use to Ubuntu users (more use to Canonical who have to order stuff from printers, I guess). If “PDFs produced by the designers” have colours “not quite right”, then they’re probably not using a sensible colourspace. For PDFs distributed on the web they ought to use sRGB which would correspond to your #DD4814.


        • Jef Spaleta says:

          I think this hits on the missing bit of information. The CMYK values published by Canonical appear to be color profile corrected values for some _unspecified_ device.
          I’ve found other external references to Pantone 1665 that disagree with the published values from Canonical.

          Pantone 1665
          CMYK 6, 86, 100, 1
          Hex #d54e21
          RGB 213, 78, 33

          Which by the way does not agree with Canonical’s values nor with the Gimp’s or the online calculations. Notice that the Hex value is even different even though WordPress and Canonical are supposedly using the same pantone 1665. I think what is happening is that perhaps different proprietary tools are doing different color profile corrections behind the scenes. Why else would pantone 1665 show up with different RGB values like that?


  • Do we have aubergine figured out yet? I want to print my flier for the release party. All this attention to new fonts and colors is great. It is a hassle to not know which colors are canonical representations.

  • Jef Spaleta says:

    Interesting analysis.


  • Thomas says:

    RGB colors depend on the monitor used. Common profiles are sRGB and Adobe RGB. Some LCDs have a red that is more orange, and so on. And do not forget color temperature. Some people have their screens really blueish, because it looks bright (9300K), others go for ‘standard’ (6500K), or warm (5000K). Now, a printed sample may be viewed under incandescent light (2800K) which does not have much blue light. Again, big differences.

    Thus, an RGB color (#AABBCC) does not really specify a color. But other RGB colors on that same screen will probably look ‘in balance’ if viewed together.

    With print it is not much different. in the USA, a set of inks called SWOP is used. In europe, this is Euroscale. Diffent inks. Then, the colors come out way different when printed on newspaper or glossy art paper. Newsprint will look brown next to the art paper sample.

    Pantone refers to printed colors: colors that can be compared with a predefined sample. A closed standard, but one that can be compared to if you print.

    Screen colors however are not comparable: if you keep the sample next to the screen, the lighting makes all the difference.

    Color management has to hide all the above. Algorithms are used to handle the difference in color spaces.
    Example: A full RGB blue cannot be printed in CMYK. The intense color/brightness match would be purple, but the most exact tint mathch is a quite pale blue. Which one is desired depends on the use: please no purple sky, but the purple may be suitable for a dark background. And if blue is reduced in this way, should the other colors also be ‘paled out’?
    This is the difference in ‘Rendering Intent’. Wikipedia knows about colorimetric (absolute and relative), and perceptual and saturation. Perceptual is one that has artistic input in its creation.

    So, a complex subject. I think in case of Ubuntu, the authority would be the Pantone swatches. The RGB numbers are good for web use (so your colors look the same as every other Ubuntu site) even though they may or may not match printed colors (dpending on screen and lighting).

    And whoever prints using the CMYK would do well to have the colors checked by the printer against the Pantone swatches. The printer can usually adjust ink density to shift colors to match.

    • Alan Bell says:

      the way I would like to see it work is that in the computer you work with the colour you intended to use. That might be an RGB colour, it might be CMYK, it might be pantone. There is a totally predictable algorithm for getting from RGB to CMYK (flip the values from the primary RGB colours to the secondary CMY colours, lighten them all until you can’t any more and add back the blacK equivalent to the darkness you just removed). Gimp, Inkscape, various web tools implement this algorithm and get the same answer every time. Pantone needs to map into this colour space somehow but as that is a closed proprietary standard and they won’t publish a mapping to RGB/CMYK it is basically useless.
      At the point of output, either to screen or print a colour profile should calibrate the device to what you want to see. That might be calibration to a reference card or a USB colour calibrator like the Pantone Huey, which is basically a calibrated webcam that you stick on the monitor. In theory with a good printed reference card you can calibrate a scanner, then use that calibrated scanner to calibrate a printer. I don’t see why apps should ever know about colour profiles. It should be easy to switch the xorg colour profile so you could calibrate your screen to the gamut of different printers or something, but if the calibration and profiling is done in the right place no apps need to worry about it. Everything will just work all the time, unless you use a legacy operating system in your workflow.

      • Thomas says:

        Alan Bell,

        That way to generate CMYK exists, but it does not add value to having the RGB values. The colors do not match up, for example. And it generally looks nicer to print a light grey as a mix of cyan, yellow and magenta than as black dots (the colored dots are lighter in tint and there are more of them). And for real life printing, it is not possible to print under a certain percentage of coverage (5 or 10%) – using no black in these situations avoids having a sudden ‘onset’ of darkness.

        The ‘easy way’ to generate CMYK does not handle this and will not be suitable for printing. Adjusting for printing will mean calculating the desired color from the values, and calculating that back to (wildly different) CMYK values.

        Also not that a set of RGB values does not make a color. It makes a color on YOUR screen. On mine, the color will likely be different.

        • Alan Bell says:

          What makes a colour is nothing to do with the screen or the print path. What makes a colour is how much the red, green and blue photoreceptors of the cone cells in my eyes get excited. Plus the rods which do brightness and low light levels. It seems that our vision is basically RGBW as we kind of have an additive white receptor capability. RGB seems to me to be the most logical base colourspace as that is what we see. It might be interesting for monitors to have 4 pixel clusters including a white pixel in an arrangement like:
          and it would be possible to algorithmically map to that colour space by reducing the brightness of the RGB components and adding it back as white.

  • Zac says:

    I like the colours too. I especially like the shade of orange used in the tab bar of Google Chrome using the GTK theme. It is a slightly dull orange that’s very easy on the eye.

Leave a Reply

XHTML: You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>