4. All About Profiles: Describing Devices

If color management is as simple as we say it is in Chapter 3, Color Management, you may be wondering why you even need this book. The answer is that, while color management is simple, color reproduction is not. The various machines we use to reproduce color are prey to a host of factors that affect their behavior, and color management is blissfully unaware of them—unless they are captured in a profile.

Color management systems know nothing about the various devices they drive except for the information that’s recorded in the profiles for those devices. All the intelligence in color management systems—rendering intents, previewing capabilities, simulations—is built into the device profiles. So it’s essential that you obtain or create accurate profiles for your various devices. We tell you how to create device profiles later in the book, but to make good ones, you need to know a little about what comprises them and how they work.

What Are Device Profiles?

Contrary to prepress legend, profiles aren’t magic, nor are they made by elves during the full moon in Orthutanga.

A profile is just a file that correlates device color values with corresponding device-independent color values that represent the actual color people see. The device values are expressed as the control signals—usually RGB or CMYK—that we send to our devices to make them reproduce color. The corresponding device-independent values that represent the color they reproduce are expressed in the profile connection space (PCS)—either CIEXYZ or CIELAB. (Refer to Chapter 3 for more on the PCS.)

The device profile contains information about the three main variables that describe how a device is behaving:

• Gamut—the color and brightness of the colorants (primaries)

• Dynamic range—the color and brightness of the white point and black point

• Tone-reproduction characteristics of the colorants.

(We tell you more about these variables in Chapter 2, Computers and Color, in the section, “Why the Numbers Vary.”)

Some kinds of profiles may contain additional information, such as instructions for handling out-of-gamut colors, more detailed tone-reproduction information, or special “secret sauce” information that’s only used with a particular CMM.

Profile Classes

Profiles come in a few varieties, or classes: input profiles describe scanners and digital cameras; display profiles describe monitors and LCD displays; and output profiles describe printers and presses.

Some people confuse the term input profile with source profile, and output profile with destination profile. Input and output profiles refer to distinct types of devices that these profiles represent, whereas source and destination profiles refer to temporary roles two profiles take at the moment a color conversion happens. We describe source and destination profiles in “Using Profiles—Source and Destination,” later in this chapter.

One factor that differentiates the three types of profiles is whether they are one-way or two-way—that is, whether they allow the CMS to convert from device space to PCS and from PCS to device space. Input profiles only have to define the conversion from the input device’s color space to the PCS. You can’t view or output color on a scanner or digital camera, so there’s really no need to convert color to scanner or digital camera space. Input profiles simply tell the CMS how people would see the color the scanner or camera captures (see Figure 4-1).

Figure 4-1 One-way and two-way profiles

On the other hand, display profiles must be two-way because your display acts as both an input and an output device. If you create or edit a color based on its appearance on your monitor, you’re using the monitor as an input device: the CMS needs to know what color you’re seeing on the monitor so that it can reproduce it on a printer, press, or another display. The CMS looks at the monitor RGB values being displayed and uses the profile to calculate what actual color those RGB values represent. Conversely, when you display an image on your screen, the monitor is the output device: the CMS evaluates the image’s embedded profile to determine what actual colors are represented by the numbers in the file, and then uses the monitor profile to calculate the monitor RGB values needed to display those colors accurately.

Output profiles are always two-way profiles, too. We use them not only to convert from the PCS to the output color space for printing, but also to display files already converted to output space on the monitor, or to convert a press CMYK image to some other output device’s space for proofing. When you display a CMYK image on your RGB monitor, the CMS relies on the CMYK output profile to tell it how to convert the numbers back to the PCS and, ultimately, to monitor RGB.

The device-to-PCS transform is known as the backwards transform, and the tables that specify it are known as the AtoB tables, while the PCS-to-device transform is known as the forward transform, and the tables that specify it are known as the BtoA tables (see Figure 4-2).

Figure 4-2 Matrix and table-based profiles

Stimulus and Response

One easy way to visualize the process of making profiles is to think in terms of stimulus and response. Empirical science often boils down to poking things and seeing what happens. Profilers work by sending a stimulus to the device, obtaining a response, and then comparing and correlating the two. In other words, they poke the device with known RGB or CMYK values, and then measure what the device produces.

For a display device, the profile maker sends a stimulus in the form of known RGB values and then measures the colors those RGB values cause the monitor to display. The measurements are made with an instrument that captures PCS (XYZ or LAB) values. Then it constructs a profile that correlates the RGB values and their PCS equivalents. Hence the profile can tell the CMS what actual color will result from a given set of RGB values. The profile can also tell the CMM what RGB values are needed to display a specific color (see Figure 4-3).

Figure 4-3 Monitor calibrators

For an output device such as a printer, the profile maker sends known RGB or CMYK values to the printer and then measures the printed output. Again, it builds a profile that correlates the stimulus and the response, so that the CMS can tell from the profile what actual color will result from specific RGB or CMYK values, and what RGB or CMYK values are needed to print a specific color (see Figure 4-4).

Figure 4-4 The IT8.7/3 target

For an input device such as a scanner, the process differs only in that the measurements are usually already done for you. The stimulus in this case is a scanning target that’s either supplied with the profiling package or obtained from a third-party vendor. Scanner targets are always accompanied by a data file that records the LAB or XYZ values of the color patches. You scan the target, and then feed the scanner profiler the scan and the target data file. The profiler compares the RGB values in the scan and the LAB or XYZ values in the target data file and builds a profile that tells the CMS how the scanner sees color (see Figure 4-5).

Figure 4-5 The HCT scanner target and reference data file

Profile Limitations

There are three limitations in this process of creating profiles that you need to keep in mind.

First, the profile maker can’t cover the entire set of possible device signals. For example, a printer profiler can’t send every possible combination of CMYK values to the printer to see what results—at one percent increments, doing so would require a target with 100,000,000 patches! Even if you had the equipment (and the patience) to measure all these patches, storing that many sample points in a lookup table would produce output profiles in the gigabytes.

So interpolation is unavoidable, both at the time the profile is created and when it is used by the color management system. We mention this because it helps explain what the CMM does, and why some color conversions are slower than others. Many people assume that with a big enough lookup table there would be no need for a CMM because there would be no interpolation, or at the least all CMMs should produce the same results with the same profiles. While in theory this is true, in practice, interpolation is unavoidable, which is why some vendors try to find better interpolation systems with different CMMs.

The second limitation is that profiles can’t make devices do things they cannot do. If a printer can’t produce a certain shade of red, a profile won’t somehow make it magically produce that color. The profile describes the gamut of the device, but it can’t enlarge the gamut.

The third limitation is that the profile is only as accurate as the measurements on which it’s based. A profile is a snapshot of the way the device was behaving when the measurements were captured. The majority of color devices drift over time, so you need to take steps to ensure that the device is behaving the way you want it to before you profile, and you need to take steps to keep it behaving that way after you profile; otherwise the profile will no longer provide an accurate description of the device’s behavior, and you won’t get the color you want. We discuss this topic in more detail in Chapter 5, Measurement, Calibration, and Process Control, and in the following three chapters that deal with the specifics of building display, input, and output profiles, respectively.

Using Profiles—Source and Destination

By itself, a profile does nothing at all—even when a profile is embedded in a file. It’s only when you’re converting colors from one device to another that a profile becomes active. At that time, the color management system doing the conversion needs to know where the colors came from and where they are going—and thus requires two profiles to do the color conversion.

In a color conversion, the profile you’re converting from is the source profile, and the profile you’re converting to is the destination profile.

Source and destination profiles aren’t types or classes of profile—they’re just temporary roles that two profiles play when a color management system uses them to convert colors from one device to another. Input profiles are almost invariably used only as source profiles—it makes much more sense to convert color from a scanner or camera space than to convert it to a scanner or camera space—but output and display profiles are equally at home as source and destination profiles. For example, if you have an image from an RGB scanner that you want to print on a press, you’d convert it using the scanner RGB profile as the source and the press CMYK profile as the destination. But if you then wanted to proof the converted CMYK image on an RGB inkjet printer, you’d perform another conversion using the CMYK press profile as the source and the RGB inkjet profile as the destination.

Generic Profiles

Just about every color device sold nowadays comes with one or more generic ICC profiles made by the device manufacturer and describing the typical behavior of the device model rather than the specific behavior of the individual unit. Some of the more rabid color-management enthusiasts will tell you that all such profiles are useless. While it’s probably true that the inappropriate or over-optimistic use of generic profiles—profiles that were made from something other than the measured behavior of your particular unit—have caused far more than their fair share of color-management headaches, some generic profiles are a great deal more useful than others.

Generic profiles are useful when they’re for very stable devices that display little or no variation from unit to unit in manufacturing, or little or no variation from batch to batch in consumables. The profiles that accompany many inkjet printers, for example, fall into this class: you may get slightly better results from a custom profile, but the generic ones are nevertheless quite useful. Generic profiles are also useful in representing standard conditions, such as SWOP (Specifications for Web Offset Publications), that define how a press should behave, or for common mainstream proofing systems.

Generic profiles are useless (Bruce would say worse than useless; Chris would say somewhere between lethal and catastrophic) for unstable devices, or for ones that display significant unit-to-unit variation, such as CRT displays. CRTs not only have a lot of unit-to-unit variation fresh from the factory, they drift over time and they offer controls that let you change their behavior radically, making generic monitor profiles a cruel joke at best.

Color Space Profiles

Thus far in this chapter, we’ve confined our discussion of profiles to device profiles—profiles that describe the behavior of an actual physical device or a class of physical devices. But there are also profiles that describe device-independent color spaces such as CIE LAB or CIE XYZ—these are known, logically enough, as color space profiles.

In recent years, another type of profile has become commonplace—device-independent RGB profiles. Technically, these aren’t color space profiles as defined in the ICC spec—they’re built like display profiles and appear to the CMS as display profiles—but in practice they behave a lot more like color space profiles than device profiles. They don’t represent devices, so they aren’t subject to variability, and they’re always accurate. We’ll discuss these profiles more fully in Chapter 10, Color Management Workflow.

Good Profiles

One entirely reasonable way to decide whether your profiles are accurate enough is simply to look at the results you’re getting and decide whether or not you’re happy with them. But if you bought this book, chances are that you’re less than satisfied with what color management is currently doing for you. In the next four chapters, we look at building profiles, and reveal our techniques for making sure that your profiles give you the best results from your devices and that your devices keep behaving the way your profiles think they do.