At this point in time, we’ve all grown pretty comfortable with the basic tenets of color management— a method of objectively defining color and a vehicle to preserve (or interpret) that definition from one device to another. But the details of utilizing color management are more elusive. While the concept of an interpretive color space (L*a*b*, XYZ, etc.) is firmly rooted, we’re currently inventing the architecture and methodology for using it in desktop publishing.

Color management complicates the publishing workflow. With analog proofing, the proof was inextricably tied to the film from which it was made. Linear film, proper exposure and a correctly set processor were the operators’ only responsibilities, and each of these was easy to validate. The manufacturers of the consumables took care of the rest. The efficiencies of computer-to-plate (CTP) have rendered film obsolete in offset printing, and today’s digital proofing makes color management an absolute necessity. And the color-matching opportunities now are far superior to anything from an analog workflow.

Color management—once solely in the realm of raster imagery—has migrated into the vector world and into all of the desktop publishing applications. This is a great thing. Instead of concentrating only on scans or photos, we now have the ability to manage all of our colors. A file can be built for one output condition and then everything in the document can be repurposed for a different output condition—be that another printing method, use on the web or in a presentation. Since these capabilities are relatively new, there are several obstacles to overcome.

THE RABBIT HOLES
The downside of having color management move into QuarkXPress and InDesign (and Illustrator, too) is that we’re in a transitional period: These applications don’t have the interfaces to appropriately control International Color Consortium (ICC) transforms yet. To control any ICC transform, you’ve got to be able to specify the source profile to be used for items (if a profile isn’t already embedded), the destination profile and the rendering intent(s) to be used. I find it useful to think of these as: where we are, where we’re going and the path we’re going to take to get there.

The four biggest obstacles to color management in page-layout applications today are:

1. Black channel handling

2. Consistent rendering intent

3. The ability to handle vector and raster graphics the same

4. Undue difficulty identifying the current color space

ICC transform takes a color from the source color space into a profile-connection space—like XYZ or CIEXYZ—and out to the destinationcolor space. Profileconnection spaces are device-independent mathematical constructs that map color in 3D. There is no equivalent for black in profile-connection spaces—black is rather the byproduct of less light, either light reflected off a surface (paper) or emitted by a source (scanner or monitor).

The black channel
Proper handling of black type and grayscale objects is a key issue—maybe the key issue. Looking at the anatomy of an ICC transform—say from CMYK color space to XYZ color space and back to CMYK—the problem is in the middle of the transform. The profile connection space is a way to objectively map out color and black (K) is not a color. Black is the uncolor—the absence of color.

There’s no black in XYZ, L*a*b* or any profile-connection space. What is black gets mapped into the profile-connection space (e.g., XYZ) and then out to the destination space (e.g., printer), where it’ll contain three or more inks. For example, taking a 100K—100 percent black-object in Photoshop from the U.S. Web Coated (SWOP) v2 color space into the U.S. Sheetfed Coated v2 color space—using the Relative Colorimetric rendering intent option—yields a tint mix of 78C, 68M, 66Y, 49K (see example above).

Imagine this happening to 6-pt. black type in the disclaimer of a marketing piece. A registration issue on press is created that will keep the type from looking crisp. Black type has to be protected from being inadvertly transformed.

For a tint—like a drop shadow or a grayscale image—the problem is worse. Run the same color transform from before, but start with a 50K screen, and you wind up with 38C, 28M, 27Y, 1K—a chromatic gray with almost no black … the hardest thing there is to print. What was once a simple screen is now very sensitive to color casting on press. Any inks pushed out of balance—say some extra magenta to “cherry up” the reds—will cause a color shift in these three- and four-color neutrals long before the saturated colors are affected.

Rendering intents
An Illustrator file saved with PDF compatibility is two files in one. It contains the Illustrator portion as well as the same file in PDF form. When you place an Illustrator file into InDesign, you are making use of the PDF portion. Part of the PDF specification says a PDF should have a rendering intent associated with it. InDesign honors this embedded rendering intent. The rendering intents you specify in InDesign apply to raster objects and native InDesign elements only. But any Illustrator elements will use the rendering intent that was set as the default in Illustrator’s color settings when the file was saved in Illustrator. This creates the potential for mismatching elements that started out as the same color.

Over this past week, I was engaged in a debate online with a friend and colleague, Roger Breton, about rendering intents. In a situation in which a transform is required, he chooses to use the Perceptual rendering intent for scans and the Relative Colorimetric rendering intent for vector-based art. He said that to his eye, the Perceptual rendering intent yielded more attractive results on his scans, but he used the Relative Colorimetric rendering intent on vectors in an effort to remain more faithful to the original colors.

I disagree with this approach, as it means that the same color will appear differently, depending on whether it’s found in a vector or raster element. How different? Well, that depends on the color. The Perceptual rendering intent utilizes gamut compression—the mechanism whereby out-of-gamut colors are remapped into the destination-color space (e.g., any colors that fall outside the destination-color space are remapped to colors within the destination space). But gamut compression is more exaggerated in the saturated colors at the periphery of a color space.

For example, if we go to Photoshop and begin in the U.S. Web Coated (SWOP) v2 color space and convert into the U.S. Sheetfed Coated v2 color space—starting with an area of 50C, 40M, 40Y, 0K, we get the same result—43C, 31M, 31Y, 2K—using either the Perceptual or Relative Colorimetric rendering intents. But, if we start off with a saturated red (0C, 100M, 100Y, 0K), the Perceptual intent yields 1C, 99M, 88Y, 0K; while the Relative Colorimetric intent gives us 0C, 99M, 85Y, 0K—an estimated deltaE(ab) of 2.45 (as calculated from the L*a*b* numbers indicated in Photoshop’s Info palette). If we uncheck Black Point Compensation for the same conversion of the red, the Perceptual intent yields 1C, 99M, 87Y, 0K; while the Relative Colorimetric intent yields 0C, 96M, 78Y, 0K for an estimated deltaE(ab) of 5.4. So, in the worst of all situations you would have a vector-based piece of artwork next to, or on top of, a CT (Continuous Tone picture data refers to all data rasterized for the image), containing the same color—and the colors would be noticeably different.

Rendering intents are a means of dictating how users want the CMM to handle ICC transforms. Perceptual rendering intents use gamut compression strategies to maintain color relationships when moving from a large color space into a smaller one—like RGB to CMYK. Colorimetric rendering intents don’t use gamut mapping, but instead map colors to the closest Colorimetric equivalent in the destination color space. Colors that fall outside the boundaries of the destination color space are clipped. Using different rendering intents can produce significant differences in the final color.

Color management inequality for raster and vector images
So, what about all your vector art? For years we’ve spent our energies managing the color of raster artwork and ignoring vector elements. By not managing the color of vector elements, we assume they are in the color space of the final output device—whether that assumption is valid or not. Most often, corporate colors will appear in vector artwork, and all too often they are specified as percentages of CMYK. Surely it’s just as important to optimize these colors for final output.

As I stated earlier, to control any ICC transform you’ve got to be able to specify the source profile to be used for items that don’t have a profile embedded, the destination profile and the rendering intent(s) to be used. GretagMacBeth’s iQueue was the first application to allow the setting of all these parameters for raster elements, vector elements and PDFs; and the controls from iQueue have yet to be surpassed.

iQueue was the first product to support the color management of PDFs, the first to allow black objects to be excluded, the first—that I am aware of—to allow the selection of rendering intent by color space, and one of the first color-management tools to support the use of Device Link Profiles. Alas, iQueue was orphaned as a product and does not support PostScript 3 operators, nor will it run under OS X. But hopefully it laid a path that other applications will follow.

iQueue
iQueue was an advanced colormanagement server product offered by GretagMacBeth. After setting up the parameters for iQueue’s operations, you simply fed files into hotfolders and iQueue worked unattended. It made use of cascading hot-folders—so a number of workflows could be built—and was capable of handling raster, vector and PDF data in a large number of formats. Development was stopped at PostScript level 2, and alas, the product hasn’t been updated to run on OS X.

Adobe Acrobat
In Acrobat 7, Adobe introduced the Convert Colors function—giving users the ability to color-manage PDFs, but with an incomplete set of controls. Acrobat 8 has “PDFfixups”—preflight functions allowing for specification and other rendering intents, but it’s not straightforward. Acrobat 8 also has a new Color tab in TouchUp Properties for individual object conversions. Unfortunately, you can’t see what Source Profile is used.

So, what does Acrobat have that the other applications don’t?
Well, let’s start at the top of our list. Item number one is the black-channel handling. Acrobat recognizes grayscale color spaces, allows for the use of grayscale profiles and allows you to choose which color spaces you wish to convert. This means that you can choose, for example, to convert the RGB and CMYK elements in a PDF, while simply leaving the gray items alone.

There’s also a check box in the Convert Colors palette labeled Preserve Black Objects. Without checking this option—even though you’ve chosen not to convert grayscale elements—black vector elements that are tagged with a CMYK profile are treated as CMYK. If you export a PDF out of InDesign and embed profiles, black type will be tagged and will then be treated as CMYK. (A raster element that is built as CMYK but contains only black is recognized as gray if there is no profile attached to the element.)

The second item is consistent rendering intent. Recall that above we discussed the fact that PDFs are to have a rendering intent associated with them? Neither in Acrobat’s Convert Colors dialogue nor the Color Management tab of preferences do you have the option of specifying a rendering intent. Acrobat uses the Relative Colorimetric rendering intent, because that’s what the spec says. The upside is you can achieve consistent color transforms between native and imported elements. The downside is you can’t take advantage of any gamut compression when you’re performing an ICC transform. Colors that fall outside the gamut of your destination color space will be clipped, and those close to the boundaries may become indistinguishable.

Fortunately, there are several third-party plugins for Acrobat that give you greater control over ICC transforms. Callas pdfColorConvert, Apago PDFEnhancer and Heidelberg ColorEditor are just a few. And Acrobat 8 has “PDFfixups” under the Preflight function that give access to different conversion options based on element type (image, line art, text or smooth shade) and color space … but I haven’t been successful in using this approach.

I currently use ColorEditor because it gives me the level of control I want, it’s quick and it informs me of embedded Output Intents. ColorEditor lets me specify what profiles to assume, override embedded profiles or Output Intents, embed the destination profile as an Output Intent, specify what color spaces get converted, protect black objects, and even change elements made of equal amounts of red, green and blue to black. The only thing that ColorEditor doesn’t do is make use of Device Link Profiles.

The third trouble area we identified on our list is the ability to handle color in vector and raster graphics in the same manner. By color-managing everything in one step, you utilize one CMM, one application and one group of color-management options. This is the holy grail of color management.

Undue difficulty identifying the current color space
Lastly, the ability to identify the current color space: On this front Acrobat fares worse than other applications. Photoshop is the best. The color mode of the image is displayed in the top of the image window, and the associated profile can be displayed at the bottom. When a soft proof is called for, the profile through which the image is being viewed is displayed in the top of the window, too.

Illustrator CS3 has the ability to display the document working space in the bottom of the application window, just as Photoshop does. In QuarkXPress you must first go to Preferences > Print Layout > Color Manager to identify the Source Setup. Then you must go to Edit > Color Setups > Source to see the associated color settings. In Acrobat you have to run a preflight to see the Output Intent and/or embedded ICC profile. Even using the new TouchUp Properties tool in Acrobat 8 only lists the color space as “ICCBased DeviceCMYK.”

The good news for you and for Acrobat: There are third-party plug-ins to access and make use of that information.

FINDING THE LIGHT
At this point, I recommend avoiding the color management coming out of QuarkXPress and InDesign. The inability to spare black type and grayscale elements is fatal on its own. Combine that with the fact that InDesign doesn’t honor the rendering intent you specify for placed Ai and PDF elements, and you’ve got a recipe for failure.

From InDesign you can export to PDF without converting colors. Or in the Color Management tab of the Print dialog, you can set the Options to “PostScript Printer Determines Colors” and check “Preserve CMYK Numbers.” However, InDesign will still transmit unwanted information to your printer (or RIP), in the form of a color space array (CSA) that the printer can use to convert colors—so you must be certain that the printer/RIP is set up to ignore such information. If your document contains elements that make use of transparency, then you must make sure those elements are either untagged or that the embedded ICC profile matches the document. For raster elements, you also have the option of overriding the embedded profile.

From QuarkXPress you can also export to PDF without a color conversion by using the As Is color setting in the PDF options. To print without a color conversion, you must go to Preferences > Default Print Layout > ColorManager and set the Source Setup to QuarkXPress Emulate Legacy. Then Quark will act as it has in the past.

It saddens me that we have to avoid color management altogether in these applications. In time, I expect that repurposing a document will be less perilous. PDF is evolving into a format with huge colormanagement potential and the ability to repurpose a document in its entirety. And with third-party plugins the quality and efficiency gains are stellar.

QuarkXPress
To turn off color management in QuarkXPress 7, go to Preferences > Color Manager > Source Options. In the dropdown menu, activate QuarkXPress Emulate Legacy. Then Quark will act as it has historically. Alternately, you can export files to PDF using the As Is setting in the PDF Export options.

Adobe InDesign
Color management cannot be “turned off” in InDesign, nor can it be in any Adobe application. Rather, you must bypass it to avoid unwanted color transforms. In the print dialog box, choose Color Management > Options > Color Handling and set the option to PostScript Printer Determines Color and check Preserve CMYK Numbers. This will keep InDesign from performing any conversions, unless you have elements that use transparency and/or have an embedded profile other than the document working space.

SIDEBARS:

Definitions:
L*a*b* and XYZ are mathematically derived color spaces that define colors in 3D. They are completely objective and are not associated with any device.

CMYK is shorthand for Cyan, Magenta, Yellow and Key (black)—the primaries for four-color process printing. CMYK is always device-dependent, which means it is associated with (or descriptive of) a specific device.

RGB is short for Red, Green and Blue—the additive primaries (primary colors for light-emitting devices like monitors). RGB color spaces may be device-independent or device-dependent. They may be mathematically derived (like working-space profiles such as Adobe RGB 1998 or sRGB) or may be descriptive of the behavior of a specific device—such as a monitor or scanner.

Rendering intents—Perceptual, Saturation, Relative Colorimetric and Absolute Colorimetric: Each has certain characteristics that influence how a color transform is carried out. The Perceptual intent employs gamut mapping, which remaps colors from a large color space—like RGB—to smaller color spaces—like those for offset printing. The Saturation intent works in the opposite way, pushing colors out to the periphery of the destination color space. The Colorimetric intents employ no gamut mapping, but instead are an effort to provide the most accurate mapping from one color space to another. The Absolute Colorimetric intent remaps white elements to the white point of the destination color space, while the Relative Colorimetric intent leaves white alone.

deltaE is the unit describing how far one color is from another in a 3D space (like L*a*b*). There are many variations on the formula, so it’s important to note which is being used. deltaE(ab) or deltaE(76) use the original formula. deltaE(2000), deltaE(cmc1:1) and deltaE(cmc1:2) are some other varieties that attempt to more closely link color differences with human color perception.

CMM is a color management module. It’s software that handles the math involved in an ICC transform (they are very math-intensive). There are several vendors who have developed their own CMMs: Logo (Gretag- MacBeth), Kodak, Heidelberg, Imation, Adobe, Apple (ColorSync was the first). When you initiate a color transform, the application pulls data from tables inside the profile. These tables mark the colors for specific grid points in the color space. The tables differ by the rendering intent chosen. If a pixel’s color falls directly on a grid point, then the color is easily found. But if a color doesn’t line up with any of the grid points in the color space, then some math has to be done to figure out where to map it. Each CMM handles the information you pass to it a little differently; that’s why it’s important to settle on one for any particular group of color transforms. If you have to handle different data types (i.e. vector vs. raster graphics) in different applications, then you run the risk of involving more than one CMM—thus having disparate results for items that should be identical.

Rich Apollo (rich@prioritylitho.com) is a 1991 graduate of Southwest Missouri State University (now Missouri State University) with a BFA in Design. Following time spent in design, digital print and a stint as a window washer, he is now head of prepress for Priority Litho in St. Louis.