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
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.
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.
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.
