# PDF colour model and LaTeX

(Strictly speaking, this is a question about XeLaTeX and the xcolor package but I’m assuming that the issue is actually with the color model of PDF.)

I’m having the problem that colours in my PDF don’t match. For example, I screen grabbed a colour value as RGB, declared it in my document and the resulting colour was completely different. To illustrate:

Both colours were grabbed off the screen – on the left, from the PDF generated by XeLaTeX. On the right, the original colour whose RGB value I tried using in LaTeX (in case my issue isn’t clear: the colours on top are differnt, yet they have the same HSB values).

So I thought that perhaps RGB doesn’t map without loss to whatever colour model PDF used and tried the obvious alternative – CMYK, which, after all, is often used in print (right?). Again, the colours are off, but now less perceptibly.

Another example (this time using CMYK values):

The colour is supposed to have the CMYK value (0.94, 0.63, 0.04, 0.07). I have declared the colour in my code as follows:

\definecolor{primary}{cmyk}{0.94,0.63,0.04,0.07}


The bottom half of the picture is created by TikZ. The top half is actually an EPS that I included via includegraphics. The EPS was created in Inkscape. Neither of the above colours has the correct CMYK value when examined with a colour picker:

The top is (0.96, 0.67, 0.08, 0.19). The bottom is (0.92, 0.61, 0.06, 0.09).

(Incidentally, when I try to enter the “correct” CMYK value in Inkscape, it “auto-corrects” my value to some other value. Wut?)

Now, this mightn’t seem like a TeX related question at all. But, long story short,

How can I reliably reproduce colours in pdfLaTeX/XeLaTeX?

I know that the issue is confounded by the fact that PNG (which is the format of the above screenshots) uses an own colour model and so the screen shots may look different on your PC than on mine. But since I pasted the colours into the same image, I think that the difference should be preserved.

-
I have no clue about this, but it's funny that when I try to read the color from your first image (on OS X with the DigitalColor Meter) even on the “solid” area the values flicker when you move a bit up and down. (Edit: Ah, it's a jpg, that's why) –  Juan A. Navarro Jan 31 '11 at 15:48
did you \usepackage[dvipdfx,cmyk]{xcolor} ? –  Herbert Jan 31 '11 at 15:59
According to the GIMP, the two colors in your first picture do not have the same HSV values, the first one has hue of 30, the second mostly 35 (with few spots of 34). I believe that in general, conversion between different color spaces is device dependent, so if you use different device profiles, you can get different results. –  Jan Hlavacek Jan 31 '11 at 16:16
@Konrad: \usepackage[xetex,...]{xcolor} is also supported by xcolor –  Herbert Jan 31 '11 at 16:26
This question opens up a huge can of worms. Colour spaces are immensely complicated beasts: Even RGB and RGB be different things! There is sRGB, which is the standard colour profile for computer monitors, and there is Adobe RGB, which allows for a bigger gamut of colours (especially, more greens) and is more suited for photos. It is my understanding that one should avoid CMYK altogether unless the goal is to produce PDF for a specific printing press and paper whose characteristics are known. –  Harald Hanche-Olsen Jan 31 '11 at 16:35

The colour model of PDF is extremely sophisticated and bewilderingly flexible. You can read all about it in section 8.6 of the pdf specification (you can download it here). There are a number of prepress tools that exist for managing a colourspace workflow with PDF. Adobe Acrobat Professional has an "output preview" tool which is what I use.

PDF supports many colour spaces: gray, cmyk, rgb, indexed, LAB, deviceN. This allows for things like spot colours (and tints thereof), special metallic or varnish inks, 6-colour printing, duotone, multitone, registration colours, and so on. You can have multiple such colour spaces within the same PDF (although for printing you'll need to convert to some common space, at least for each page). There can even be multiple variants of the same colour space family (for example sRGB and the variant of RGB that your scanner or digicam uses; cmyk with different dot gains, etc).

The situation gets even more complicated when you involve transparency (see section 11.7 of the spec): in order to overlay one object on another the PDF viewer needs to convert them to a common "blending" colour space, which can be specified in various ways in the PDF (including at the "page group" level: this explains why including transparency on a page can change the appearance of other objects on that page, because those objects now have to run through a colour space conversion). There are various restrictions and special cases, for example device colours cannot be converted reliably into CIE based spaces (such as sRGB). Since transparency groups can nest, there can be multiple rounds of colour space conversion during rendering.

## TeX support

Now for latex support via xcolor: If you load xcolor with the (default) natural option there will be no colour space conversions, and you will have access to the PDF "DeviceRGB", "DeviceCMYK" and "DeviceGray" spaces. Eg, \textcolor[rgb]{1,0,0}{DeviceRGB red}, and \textcolor[cmyk]{0,1,1,0}{DeviceCMYK Red}. Your PDF viewer (for screen) or your printer driver (for hardcopy) will have to convert colour spaces if necessary. If you load xcolor with options like rgb or cmyk then xcolor will convert to that colour space, using the formulas from section 6.3 of the xcolor manual (which are not very sophisticated -- compare them to the formulas in 10.3 of the PDF spec, with BG(k) and UCR(k) functions, etc).

If you use the dvips route to producing PDF then you may be able to access also spot colours and other colour spaces, using the named and ps models. I believe Context makes these things somewhat easier, but I don't speak from experience.

Remember that converting device colour spaces to the screen colour space is in general not well defined, and different viewers may do it slightly differently, resulting in the mismatches you've observed.

One good solution with pdflatex is to use only deviceRGB (for screen) or deviceCMYK (for most printers) and then set an "Output Intent" to define the device space as, eg, sRGB IEC61966-2.1. See section 14.11.5 of the PDF spec. The pdfx package does this, for example (although that package is pretty rough around the edges and you'll generally need to edit it directly to get it to work). A more "proper" way to use calibrated colour spaces would be the "Default Color Spaces" mechanism (section 8.6.5.6) which specifies a way to remap DeviceRGB, DeviceCMYK, DeviceGray into device-independent CIE-based colour spaces. I'm not aware of any latex package that makes use of this PDF1.1 feature, though. (Grepping through the sources suggests that again Context may have some support for this).

## The case of the different coloured swatches

In your first pair of images, note that the left image has a gray triangle in the upper right corner. This indicates that it is a deviceRGB colour from a screen grab. Click on the icon to the left of the "HSB Sliders" indicator and choose the colour space as for the right swatch, and you'll see that the colours will then match.

## The case of inkscape "autocorrecting" CMYK

-
This answer is awesome on so many levels. It gives a concise explanantion of (1) PDF colour models, (2) TeX support for colour models, (3) OS X colour support and the correct usage of the “Colors” dialog, which has somehow eluded me for years, and finally (4) a pointer to the bewildering behaviour of Inkscape. What can I say? Thanks a lot –  Konrad Rudolph Jan 31 '11 at 20:46
@Konrad What can you say? Maybe you could accept the answer? :-) –  Alan Munn Feb 1 '11 at 1:17
@Alan: I will, but first I will wait two days and make this question a bounty. Then I can award more points for the answer. –  Konrad Rudolph Feb 1 '11 at 7:50
Do I understand it right, that for example \usepackage[cmyk]{xcolor} will convert all color definitions in the document that use another color model? sth like \definecolor{halfblack}{gray}{0.5} would in the end be CMYK? –  Nyiti May 6 '11 at 7:41
@Christian: yes, having separate screen and print versions gives the most control over colour, although such a level of control is rarely needed for most simple documents, in which case I would choose CMYK or RGB depending on the primary medium of the document. You only want complete control if you're at the level of worrying about rich blacks, trapping, and such things. (There may be other reasons, unrelated to colour, to have separate print and screen versions, such as doing away with recto/verso distinction for screen, adding a thumb index for print). –  Lev Bishop Feb 25 '13 at 5:47