18. Building Color-Managed Workflows: Bringing It All Together
And so we come to the end of our color management odyssey. You’ve learned all about the many and varied ways our eyes interact with photons to produce the sensation we call color; how we use colorants such as inks, filters, and phosphors to make our color-reproduction devices emit or reflect photons that we interpret as color; and how we use profiles and CMMs to control these colorants so that we have a better chance of seeing the color we want. We’ve also told you repeatedly that color management does only two things—if you can’t remember what they are, you aren’t ready for this chapter!
More importantly, we hope you now realize that color management is part of a bigger picture. It’s more than just making or using ICC profiles—it requires calibration, process control, collecting good measurement data, understanding application and driver settings, and above all, bringing all these together into a coherent workflow.
We’ve tried to give you the insights and the vocabulary you need to think critically about color management, to understand the hidden meaning behind the often-abstruse menu commands and dialog boxes that you encounter in your applications and device drivers, and to break down the color management operations those menu commands and dialog boxes control into their component parts.
Why? Because in this chapter, we’ll show you how to bring all this knowledge together to build a color-management workflow that suits your unique requirements.
We can’t possibly spell out every possible color-management workflow, because there are probably as many workflows as there are practitioners. We don’t want to simply tell you which buttons to push—because for one thing, you won’t really learn anything except for a rote set of steps, and for another, as soon as you’ve learned the steps, one or another vendor will rename, move, or change the functionality of the buttons, leaving you back at square one.
Instead, we’ll show you how to break a workflow down into its essential components, step you through the questions you need to ask, and show you the possible strategies to use in building your workflow. We will, of course, include some examples, but you should take them as illustrations of the possibilities rather than hard-and-fast rules.
The Four Stages of Color Management
All color-management workflows can be broken down into four basic steps, and understanding these steps is the key to analyzing, and then meeting, your needs. The basic steps are:
• Defining color meaning—specifying just what colors your RGB and CMYK numbers represent, or collecting LAB measurements of colors that you’ll eventually translate into RGB or CMYK.
• Normalizing color—bringing all your color elements into a common color space. This step is optional, but most workflows benefit from the simplicity it brings.
• Converting for output—producing the set of numbers that will make your final output device(s) produce the desired color appearance.
• Proofing—making sure that your final output will, in fact, have the desired color appearance.
Let’s examine these steps in detail.
Defining Color Meaning
You can’t match a color until you know what that color is, so the first step in a color-management workflow is always to attach a specific color meaning to the document or object. Just how you accomplish that, and which color meaning you attach, depends on the nature of the document and its source.
Profiled captures
Profiled captures are pretty straightforward. If the capture device driver can embed the capture profile, allow it to do so. If it can’t, you must assign the profile manually, either in an editing application (such as Photoshop) or using automation (such as AppleScript).
Unprofiled captures
Unprofiled captures are trickier. You have to decide on a color appearance, perhaps arbitrarily. Typically, you’ll either assign a profile that produces something close to the desired appearance, or just assign an editing space. In the first case, you should convert to an intermediate editing space, and in either case, you’ll probably color-correct the document—see “Workflow Into and Out of Color Management” in Chapter 10, Color Management Workflow.
Unprofiled legacy images
Unprofiled legacy images present similar challenges to unprofiled captures. With RGB images, there’s a good chance that a monitor-based profile such as Colormatch RGB (gamma 1.8) or sRGB (gamma 2.2) will produce close to the desired appearance, since they’re almost certainly based on monitor appearance (see “When Color Management Starts” in Chapter 10, Color Management Workflow).
With CMYK images, our philosophy is that when the CMYK destination is known, you should simply assign that CMYK profile and edit as necessary—if the CMYK destination is unknown, you have no business working in CMYK in the first place. In desperate situations, though, we may try assigning different CMYK profiles, then convert to our CMYK space.
Vector art
Some vector art applications insist that all the content in a document must be either RGB or CMYK, though you can force them to accept imported graphics in the other mode. In the case of legacy vector art files, you have two options:
• If you know the new destination, make it the source profile, and rework the file.
• If you know the original destination, make it the source profile, then repurpose the file (either by converting at print time in a desktop application, or using automation).
In the case of new vector art files, you have three options:
• Work in RGB using the same space you use in your other applications, but realize many of the colors in this space won’t exist in the final output space. Take advantage of soft-proofing to a generic CMYK space (such as SWOP) to get a general idea of such limitations.
• Work in the widest-gamut device space in which the artwork could possibly be used, and the one with which you’re most familiar.
• If the destination is known, assign that profile, and work in that space.
Spot colors
Spot colors probably cause more trouble than any other type of color element. First, unless the color will actually be printed as a spot color, it makes little or no sense to choose a spot color from one of the many Pantone or Focoltone libraries, because many of these colors simply aren’t reproducible by CMYK printing—yet a depressingly large number of people continue to do so, with accompanying disappointment when the job hits production. Second, the published CMYK values in the various solid-to-process color guides are only valid for the printing process that was used to print the guides—if you use these values in your job, the resulting color may bear little resemblance to the intended one.
Currently, only the non-process Pantone libraries in Photoshop 7 and CS use LAB—they automatically produce custom RGB and CMYK values based on the active document’s profile. All other applications use libraries containing hard-coded CMYK values for print (see Chapter 15, Color Management in QuarkXPress, and Chapter 17, Automation and Scripting, for suggestions on how to deal with solid-to-process).
Normalizing Color
Once you’ve defined all your color, you may well find that you have a raft of profiles—several different capture devices, a default RGB and a default CMYK profile in each application, and possibly some legacy CMYK profiles. It’s conceptually possible, and even, with some difficulty, practically possible to carry these profiles through the workflow to final output—but your life will be made a great deal easier if you normalize all your color by converting it to a single space, or, more practically, to a single RGB and a single CMYK space.
Normalizing your color simplifies your life in two ways:
• It frees you from having to deal with profile mismatch warnings in all stages of production except the initial ones.
• It lets you rely on assumed profiles. Even if you prefer to embed profiles, most vector applications don’t embed profiles in EPS files, so they force you to rely on assumptions. Normalizing your color makes it much more likely that the default assumed profiles will be the correct ones.
In addition, most RGB capture spaces don’t work particularly well as editing spaces since they’re typically neither perceptually uniform nor gray-balanced. So for all these reasons, we recommend that you normalize your color as soon as is practical.
Standardize defaults
All color-managed applications let you set default profiles for RGB and CMYK. Your sanity will be much less endangered if you make sure that all your color-managed applications use the same default profile for RGB and CMYK. Even if you’re fanatical about embedding profiles, the occasional untagged file may slip through, and as noted above, vector EPS files often don’t contain embedded profiles. If you normalize all your color by converting to a single RGB and a single CMYK, and then set your defaults to these same profiles, your workflow will be much more robust than if you fail to do either.
When to normalize
In the vast majority of cases, we recommend normalizing RGB color as soon as your applications will allow you to do so. Ad and marketing agencies can normalize stock photography to the desired RGB intermediate space early in the design process, and ask photographers to supply files in the same space.
Prepress and printing shops already have dedicated preflighting, and can include normalization as a part of it. Typically, prepress shops will normalize everything to CMYK, converting RGB content to CMYK and repurposing CMYK content when the source is different from the intended destination. Converting RGB content to CMYK before the CMYK destination is known isn’t normalizing—it’s premature binding (see the sidebar, “Premature Binding,” in Chapter 10, Color Management Workflow)—and is an idiocy we’d like to see stamped out!
The one exception is black-only text. For example, neither InDesign nor QuarkXPress exclude black-only text from color management—in InDesign, it’s in Document CMYK, and in QuarkXPress it uses the CMYK Default Source Profile for Solid Colors. If these sources aren’t identical to the destination profile used on output, you’ll get rich black text, and registration headaches on press. We’d like to see vendors treat black text by default as device-dependent, and untouchable by color management.
Converting for Output
At some point, you need to convert your color to the final output space. The question is, when? Obviously, you can’t convert to the output space until you know what that output space is. Once you know, two issues bear on the decision of when to convert.
One output or many?
If you’re going to a single output process, the question of when to convert boils down to the trade-off between seeing and editing your color in final output space, and working with smaller, more agile RGB files. If you find that automated conversions in a color server, or even in the RIP itself, give you acceptable results, you can achieve significant productivity gains by working in RGB and adopting a late-binding workflow. The downside is that you don’t see the separations until they’re on press.
If you have multiple output destinations, the question then becomes, do you prepare separate files for each output scenario, or do you rely on late-binding separations? The issues are confidence and quality. If you’re confident that you can obtain usable results from automatic separations, a late-binding workflow where final separations happen in a color server or RIP may make sense.
Editing in output space
Our experience has taught us that for the ultimate in quality, you need to make final edits in the output space. Automated conversions can get you in the ballpark, but they only know about color spaces, not about the colors in the actual document. Hence they treat all content identically, ignoring the kinds of perceptual issues we raised all the way back in Chapter 1 (see “Where the Models Fail” in Chapter 1, What Is Color?), and so they sometimes produce results that fall short of ideal. If you need to edit color in the final output space, you need to make separate files for each output scenario.
You can, however, edit in an RGB working space while looking at a simulation of the final output, which in many cases is almost as good as editing in final output space (see “Soft-proofing,” below). But if you need to make different edits for different outputs, you’ll need to make separate files for each output.
Proofing
You can’t, obviously, proof your color until you know the final destination. But you can proof your color before converting it to the final output space.
Soft-proofing
Most color-managed applications let you view a simulation of final output while you’re working on files in some other space—for example, previewing CMYK output while working in RGB (see the sidebar, “Soft-Proofing Basics,” in Chapter 10, Color Management Workflow). While some types of edits, such as tweaks to the black plate, can only be made in CMYK, you can easily make many other kinds of optimization for tone and color on an RGB file prior to conversion, using an accurate display simulation as a guide.
Hard proofing
The majority of color-managed applications let you print a simulation of your final output to a composite printer, even if you haven’t yet converted to final output. We don’t recommend using prints made in this fashion as contract proofs, even if you can get the other party to agree to them, but they can be helpful in cutting the number of contract proofs you eventually need down to a single set. In a multiple-output scenario, this feature is particularly useful, because you can proof the different outputs before converting to final output from the same master file by simply changing the final output profile.
More-sophisticated proofing systems let you send the final output data to the proofer, and either perform an internal conversion in the RIP or color server, or configure the hardware to emulate the final output. In either case, you can make your color-managed application perform the conversion to final output space as part of the print process—so again, when dealing with multiple output scenarios, you can proof each one from the same master file by simply changing the final output profile.
Step-by-Step Color Management
The breakdown of color management that we’ve presented above should help you conceptualize the necessary steps in the workflow, from color capture or specification, through editing, to proofing and final output. The next stage in building a workflow is figuring out just what you need it to do.
Determining Your Needs
At the beginning of this chapter, we pointed out that there are probably as many color-management workflows as there are practitioners. We can’t possibly spell out all possible workflows in detail. Instead, we’ll step you through the questions you need to answer to determine your specific workflow needs.
Software, File Formats, and Devices
The first set of questions deal with the software and hardware you use to do your work. Ask yourself the following:
• Which applications will I use?
• What file formats will I need to support?
• What devices will I use to capture and reproduce color?
Applications
Your workflow options depend on the capabilities of the applications you use. Some applications let you attach a different profile to each element in a job, some are limited to a single RGB and a single CMYK profile, and some force you to normalize all your color into a single profile’s space.
If you’re working with a single application, the choices are relatively straightforward, but if you’re working with multiple applications, you need to make sure that your workflow accommodates them all—and that almost invariably means making sure that the workflow can handle the most limited application of the set.
File formats
TIFF, JPEG, and PDF have robust support for embedded profiles, though you need to be vigilant for applications that either fail to detect embedded profiles or use them incorrectly. EPS and DCS EPS, however, are much less reliable in terms of profile embedding.
You need to figure out which parts of your workflow can rely on embedded profiles, and which parts must rely on assumed profiles. Then you need to ensure that you have appropriate safeguards in place to make certain that the correct profiles are assumed.
Devices
Capture devices vary widely in their ability to handle and embed profiles. Can your input devices, or their drivers, embed profiles correctly, or do you need to assign them manually? Can they convert the captures into an intermediate space and produce normalized captures, or do you need to handle normalization elsewhere?
Proofing devices also vary in their capabilities. In theory, you can use any device whose gamut wholly contains the gamut of the final output as a proofer. The question is whether you can configure the proofer to accept final output data (as you can with a proofing RIP or color server), or whether you need to rely on application-level color management to send a simulation of final output to the proofer.
What Outputs Do I Need?
Your output needs may vary from a single output that’s known before you start the job, to multiple outputs that may be unknown until the last minute, or may even be unknown until after you’ve submitted the job. The issue is when to convert to final output space. You can’t do that until you know what the final output is.
Known output
If you know the output right from the start, and you’re dealing with a single output process, an early-binding workflow, where everything is converted to output space early in the process, makes a great deal of sense, particularly if you have to interact with outside providers who aren’t color-management savvy.
If you have to deal with multiple known outputs, things become a little more complex. Early binding keeps things simple, but increases the workload because you have to prepare separate documents for each output process.
One possible solution is to keep images and critical vector color in RGB until it’s time to generate final output, while defining black text and noncritical native color elements in CMYK, then assign the final output profile when you generate final output. You may have to tweak some CMYK color builds, but your black-only elements such as text stay black-only, and your imported RGB elements get separated to final CMYK when you create the final output file.
Unknown output
If you have to prepare files for unknown outputs, you’ll almost certainly find that the political issues outweigh the technical ones. From a technical standpoint, the best solution is to submit the job in a device-independent form such as profiled RGB color, or even LAB. In the real world, though, the chances of such a job getting processed correctly after it’s left your hands are uncertain at best. If you can obtain a signed contract stating unambiguously that the downstream operation will accept files in a specified, named RGB space (or in LAB), and will take full responsibility for the color from then on, by all means submit profiled RGB or LAB. Absent such a contract, you’re almost certainly inviting trouble.
Often, you’ll be forced into a premature-binding workflow instead (see the sidebar, “Premature Binding,” in Chapter 10, Color Management Workflow). From a color management standpoint, such workflows make no sense, but we do have to live in the real world, which of course doesn’t always make sense. If you’re stuck in a situation like this, we offer the following suggestions:
• Specify a contract proofing system, such as Kodak Approval or Fuji ColorArt, by name, then separate for the proofing system and submit proofer CMYK along with the hard-copy proofs created from the CMYK data.
• Obtain as much information as possible about the output—type of press, coated or uncoated stock, anticipated dot gain—and choose a generic profile that approximates those conditions. The press profiles that accompany Adobe Photoshop, Illustrator, and InDesign, for example, are fairly “safe,” but the more you know about the printing process, the better your chances of picking an appropriate profile.
• Absent any better information, use Adobe’s SWOP Coated v2 profile (or, if you know that the job will be printed on uncoated stock, the SWOP Uncoated v2 profile). The results may not be ideal, but they should be usable.
If you have to deal with multiple unknown outputs, the first and last of the three suggestions above are equally applicable. The unknown is the unknown, whether it’s one or many—the best you can do is to provide a file that’s approximately suitable for printing, preferably accompanied by hard-copy proofs that indicate your intentions clearly.
Automation and Quality
Automation can save a great deal of time and effort. But automated processes are dumber than the dumbest person you’ve ever had to deal with—we hold firm to the view that the acronym “AI” stands for Applied Ignorance rather than Artificial Intelligence!
Automated color management knows nothing about images, nothing about color context, nothing about memory colors. It simply performs one-size-fits-all operations, one pixel at a time, and it has no means of evaluating its own results. Automation does the same thing every time.
What you can automate
Good candidates for automation include things like normalizing profiled RGB captures to a single RGB editing space. For example, if all your image sources embed profiles, you can safely set Photoshop’s Color Management Policy for RGB color to “Convert to Working RGB.” Then, whenever Photoshop encounters an image whose embedded profile is different from the working RGB space, it converts it from the embedded profile space to working RGB.
The downside, of course, is that Photoshop has no way of knowing whether or not the embedded profile is the correct one—it just blithely goes ahead and makes the conversion. So if you also receive imagery from sources that don’t embed profiles correctly, the automation may produce a bad result, creating work instead of eliminating it.
Automated output conversions can often work well, but again, they treat all color identically. So you’ll get good quality, but not as good as you’d get with a skilled operator optimizing each image. You can, however, create optimized solid-to-process conversions for solid colors, then apply them automatically using a color server or Praxisoft’s VectorPro.
What you can’t automate
You can’t really automate anything requiring intelligent human intervention—optimizing images, choosing different outcomes on a case-by-case basis. That said, it’s often worthwhile, albeit humbling, to compare totally automated results with those produced by your careful handwork. The questions you need to ask in making such a comparison are
• Is there a discernible quality difference between the two?
• Can you make a business case for preserving that quality difference?
Once you’ve defined your needs, the last step in building your workflow is to look at the workflow tools that your applications and device drivers offer, and decide how best to employ them in the four stages of color management.
Workflow Tools
You understand the stages of color management, and you’ve determined what you need to produce. The last step is to look at the various tools your software and hardware offer, and decide how to apply them.
Embedded or Assumed Profiles
Color management workflows really only offer two ways to define color meaning, which is always accomplished by associating a profile with the document or object:
• Embedding a profile
• Assuming a profile
Each approach has its pros and cons. Our very basic rule of thumb is that we generally embed profiles in RGB, and we generally assume profiles for CMYK. We always try to use CMYK as a final destination—CMYK-to-CMYK conversions do work, but they rarely give as good results as going back to the original RGB and reseparating—so we seldom need to deal with more than one flavor of CMYK at a time. That makes CMYK an ideal candidate for an assumed profile, since we know we have only one flavor of CMYK.
CMYK
We often make families of profiles for a given CMYK process, with different black generation characteristics. For example, we used three different profiles to create the CMYK in this book, with different black shapes, but we only used the different profiles to convert from RGB to CMYK. Once the content is converted to CMYK, the black generation used in the profile is no longer relevant.
In this kind of workflow, all the assumed CMYK profile does is attach a color meaning to the CMYK values by acting as a source profile. Any of the three profiles we created can do that equally well—its sole purpose is to provide a source profile for display simulations and hard-copy proofing.
CMYK profiles are also quite large—the ones we used for this book are 2.4 MB each—so embedding would mean we’d have to sling a lot more data around, and since all our CMYK is the same CMYK, much of that data would be redundant.
RGB
RGB matrix profiles, on the other hand, are tiny. We normalize our RGB color into an editing space as soon after capture as is practical, and editing space profiles are tiny, so we always embed them.
One key difference between embedded-profile workflows and assumed-profile workflows are that in the former, the color meaning is automatically attached to each element, while in the latter, the color meaning is applied manually by you, the user.
The other key difference is that, in an embedded-profile workflow, each element can have a different profile embedded, while in an assumed-profile workflow, you can generally have only one RGB and one CMYK profile. Therefore, the trick to making assumed profiles work is normalization—making sure that all your content is converted to just one flavor of RGB and just one flavor of CMYK before it enters the assumed-profile part of your workflow. Do that, and you can safely rely on assumed profiles. Fail to do so, and all bets are off!
Normalization and Editing Spaces
The case for normalizing CMYK in an individual job should be obvious—ultimately, it’s all going to print using the same four CMYK inks on the same paper. The case for normalizing RGB is a little less so. Here are the main reasons we tend to do so:
• We prefer not to edit images in capture spaces because they’re usually far from gray-balanced or perceptually uniform, so we convert to an intermediate editing space. That being the case, it usually makes sense to settle on a single intermediate editing space.
• Applications vary in their ability to handle embedded profiles correctly, QuarkXPress being an example of one that often does not. If we know that all our RGB is, for example, Adobe RGB (1998), we can set it as the default RGB. Then, even if an application fails to honor the embedded profile, we know that it will use the correct interpretation of RGB because it’s the only interpretation available.
• It simplifies the workflow.
Some very quality-conscious workflows may need multiple RGB spaces: all editing spaces represent a series of trade-offs, and no single one can produce ideal results for all image sources and destinations—see “One Pixel’s Journey ...,” later in this chapter, for an example. In most cases, though, the incremental gain from using multiple RGB spaces is outweighed by the increase in complexity that doing so brings.
Choosing an RGB space
Our main criterion when choosing an RGB space is that its gamut provides a reasonable match to the gamut of our intended output without wasting a lot of bits on color definitions that don’t correspond to anything we can capture, reproduce, or possibly even see. This is always a trade-off.
Spaces defined by RGB primaries, white point, and tone curve all have a distinctive 3-D shape. An RGB space that completely encompasses the gamut of most CMYK outputs has to be very large indeed—so large that a lot of the color definitions it contains don’t correspond to real colors. For example, in ProPhoto RGB (which is certainly large enough to encompass any output process we’ve experienced), R 0, G 0, B 255 corresponds in LAB to a blue that’s fully saturated but has a luminance (L*) of zero! That doesn’t correspond to anything we can see—all colors with a luminance of zero look the same to us, and they’re black.
We use a variety of specialized editing spaces for different purposes, but our general recommendation is to start out with a single mainstream editing space such as Adobe RGB (1998) or Colormatch RGB, and stick with it unless and until you run into a specific limitation that another space can better address.
Some workflows avoid RGB altogether, and use LAB as the normalized space. Hardly anyone in the United States seems to use such a workflow, but they’re quite popular in Europe, where Heidelberg has evangelized them for years (see the sidebar, “LAB—The Great Normalizer”).
The Cop at the Door—Warnings
Some applications, notably the Big Three from Adobe—Photoshop, InDesign, and Illustrator—can be configured to warn you when they encounter color that hasn’t been normalized—that is, it contains an embedded profile different from the one specified as the default, or in Adobe terminology, the “Working Space.” You set this option by turning on the “Profile Mismatch: Ask When Opening” checkbox in the respective applications’ Color Settings (see “Warnings—Manual Overrides” in Chapter 12, The Adobe Common Color Architecture). Unfortunately, no applications warn you when you save a file in a space other than the default.
Most other applications lack such features, so you have to develop your own procedures for checking and enforcing normalization, perhaps using scripting (see “Scripting” in Chapter 17, Automation and Scripting).
Black Preservation and Device-Dependent Data
One of our biggest reasons for avoiding CMYK-to-CMYK conversions is that K-only elements such as black text or black-only drop shadows almost always wind up being converted to a rich black that contains other inks besides black. This is almost never a desirable outcome since it introduces all kinds of registration problems on press.
The simplest solution for page-layout applications is to define all native elements in RGB so they can be repurposed, and to define black-only text and anything else for which you want specific CMYK values preserved in CMYK. Then ensure that their CMYK source profile is the same as the destination profile to prevent conversion.
Early-binding workflows don’t usually have this problem, but late-binding workflows often do. There’s no single ideal solution. For QuarkXPress users, Praxisoft’s Compass Pro XT XTension lets you exempt 100% black-only objects from color conversions (see “Compass Pro XT” in Chapter 15, Color Management in QuarkXPress). For other users, server-based conversion products or devicelink profiles, both of which we discuss in Chapter 17, Automation and Scripting, provide possible solutions. Otherwise, you simply have to watch out, and assign the output profile manually to prevent any undesired conversion.
Named-Color Systems
Named-color systems such as Pantone and Focoltone present some special color-management problems. Some are technical—Pantone is noted for revising its libraries, so that different applications often wind up with different definitions of the same color. Some are human—users specify spot colors for process jobs, or specify the CMYK values from a spot-to-process swatchbook, failing to realize that the CMYK values provided may be totally inappropriate for the job at hand. Both cause trouble.
Libraries
Wherever possible, standardize your named-color libraries so that all your applications use the same definitions. Sometimes this isn’t possible—applications tend to use proprietary formats for their color libraries—but it’s always a good idea to check for updates, then apply those updates in a controlled fashion so that all your applications match.
The solid-to-process values for Pantone colors changed around May 2000 as a result of a change in the press behavior Pantone selected. The applications containing the post-May 2000 guide values are Photoshop CS, InDesign CS, Illustrator CS, and QuarkXPress 5. FreeHand 10 and CorelDRAW 10 both use pre-May 2000 equivalents.
However, we’ve found that we can almost always improve on profile-driven solid-color simulations by creating our own hand-tuned color builds. If accurate simulations of spot colors are very important in your workflow, consider one of the automated solutions for substituting hand-tuned color values for spot colors that we discussed in Chapter 17, Automation and Scripting.
Applications
Applications exchange named color through EPS or DCS. When you create artwork in an application, the CMYK equivalents defined in the libraries are included in the EPS file so that it can print on composite four-color devices. So artwork prepared with Illustrator 10 and Free-Hand 10 produce EPSs that contain different CMYK equivalents for the same Pantone color, and those are the values that get honored. Neither QuarkXPress nor InDesign modifies the CMYK equivalents for Pantone colors in EPS files.
However, if you open a QuarkXPress 4 document into QuarkXPress 5, or vice versa, native colors get updated—the CMYK equivalents used at print time for native Pantone elements are determined by the libraries belonging to the application from which you print.
People
It’s not easy, and it’s sometimes impossible, but we always try to train our users to refrain from specifying spot colors for process jobs. Many spot colors in the commonly used systems are outside the gamut of CMYK printing, and specifying one of them for a CMYK job inevitably leads to disappointment (or worse) later in the production process.
Simulations and Soft Proofs
Most color-managed applications let you force the monitor to simulate the final output. We find this vital in image-editing applications such as Photoshop, but we also find it surprisingly useful in page-layout applications. Our eyes always force us to judge color in context, and elements that look great in isolation sometimes look quite different when they’re placed in the final layout. When we’re working on a job with a single known output, we always view the simulation. If we’re working on a job with multiple known outputs, we look at the worst one!
Even when the final output is unknown, we often use a CMYK simulation (assuming the job will eventually wind up being printed with some kind of four-color-process printing). Doing so helps us anticipate the excesses of over-optimistic designers who make use of the full RGB palette. If you are one of these over-optimistic designers, try setting your monitor simulation to Adobe’s U.S. Sheetfed Coated v 2 profile—CMYK may get a little better than that on very high-quality jobs, but if you’re designing for print, it will give you a reasonable estimate of the color palette you can use for the job.
Hard Proofs
We don’t typically bother with hard-copy proofs before we know the output process—they basically won’t tell us anything that our monitor can’t do less expensively—but we often make use of our applications’ capability to produce a hard-copy simulation of final output before we actually convert to final CMYK.
Printing hard-copy simulations of your final output can alert you to potential problems with the final conversion, so that you can take any necessary remedial action before the potential problem turns into an actual one. It’s also a good idea to print hard-copy proofs after you’ve converted to final output—you may find very slight differences between the proof of the simulation and the proof of the final converted result.
It’s unrealistic at this stage in the acceptance of color management to try to use cross-rendered proofs as contract proofs (though many periodicals do so, having achieved a confidence level through repetition). But they are useful for guidance. Of course, they don’t show problems with screening or defects on the film or plates, but neither do most other digital proofing systems short of a Kodak Approval or Creo Spectrum. That said, inkjet printers are beginning to approach the resolution needed to produce actual dot-based proofs—we expect to see a lot of action in this area in the next few years.
One of the consequences of the adoption of direct-to-plate printing seems to be that nobody knows how to proof anymore. We’ve had the experience where a printer provided film-based proofs—Matchprints, in fact—for a job being printed direct-to-plate. More disturbingly, the Matchprints were all around 20 percent heavy on the cyan: a call to the printer provided us with the assurance that “the red always heavies up on press”—which left us wondering why they’d gone to the time and expense of running film in the first place!
In the end, the profiles we’d built for the press proved accurate, and at the press check, the press matched our Epson inkjet guidance prints closely as soon as it was brought up to density. The moral of this little tale is that contract proofing is as much about responsibility and confidence as it is about accurate color matching.
Output Conversions
Converting all your color accurately to the final output is the ultimate goal of color management. The keys to achieving that goal are first to make sure that you’ve selected the correct profile for output—that’s the trivial part—and second, to make sure that each element in the job has the correct source profile—that’s the nontrivial part.
Early binding
In an early-binding workflow, each element is either created in final output space or is converted to final output space early in the process, so early-binding workflows are relatively straightforward. It’s always a good idea to preflight the job, either using the built-in tools offered by the applications or a dedicated preflighting tool, to make sure that no stray RGB images have slipped through—but in general, early-binding workflows usually mean that someone, somewhere in the production process has seen and checked the final color.
Late binding
In a late-binding workflow, things are a lot trickier—in extreme cases, the final color may not exist until you burn plates. So you need to be very sure that every element in the job is handled correctly.
Normalization is a good safeguard for late-binding workflows, because it reduces the final output conversion to one conversion from a single source to final output—you still need to make sure that each element has the correct rendering intent applied, but you don’t have to worry about multiple source profiles.
Final Analysis
If you’ve planned your workflow carefully, you should know exactly what’s going to happen to every element in the job, including the tricky ones like black-only text, and spot colors destined for conversion to process. Remember the stages of color management, and ask yourself the following questions:
• Has each element’s color been correctly defined?
• Has each element been normalized as needed to either default RGB or output CMYK?
• Does each element have the correct rendering intent applied?
• Have special cases such as black-only text, black-only drop shadows, and spot-to-process conversions been adequately addressed?
• Are all the color-reproduction devices in the chain properly calibrated to ensure that they behave the way the profiles predict they will?
When you can answer each question with a yes, you can be pretty certain that you have a relatively bulletproof color-management workflow.
One Pixel’s Journey...
To illustrate at least part of the workflow we used to create this book, we thought it might prove instructive to trace the journey of just one of the many pixels that went into its making. This particular pixel started life one atypically sunny San Francisco afternoon in August 2001, as photons reflected from one of the many fine specimens in the Dahlia Garden in Golden Gate Park.
Capture a Pixel
Bruce captured these photons in his Kodak DCS 460 digital camera, took them home, and found, upon opening the image in the Kodak DCS Acquire plug-in, that they produced an RGB value of R 248, G 13, B 0 (see Figure 18-1). He then acquired the image into Adobe Photoshop.
Define the Color
Like many Photoshop Import plug-ins, the Kodak DCS Acquire plug-in doesn’t embed profiles. In fact, it has no facility for using profiles at all. In the ProPhoto RGB working space that Bruce usually uses for Kodak digital captures, the pixel’s values translated to a screaming fluorescent orange with LAB values of L* 60, a* 128, b* 103, quite different from the dahlia red that first attracted Bruce’s attention.
So the first step on the pixel’s color-management journey was to obtain the right color meaning by assigning a profile that correctly described its appearance—in this case, a custom profile he built for the camera using MonacoPROFILER 4.0. Assigning this profile in Photoshop changed the translation from RGB to much more reasonable LAB values of L* 50, a* 90, b* 72 (see Figure 18-2). Thus we gave the pixel (along with all its siblings that made up the rest of the image) not only a specific color meaning, but the desired color meaning.
Figure 18-2 Defining the color
Normalize the Color
Unfortunately, L* 50, a* 90, b* 72 simply isn’t a color that our four-color press can reproduce, so we knew that the image would need significant editing to preserve the spirit, if not the literal color values, of the original when rendered in print. The DCS 460 profile space doesn’t provide a good editing environment—it’s neither gray-balanced nor perceptually uniform—so we decided to convert the image to the ProPhoto RGB working space for editing, using Photoshop’s Convert to Profile command (see Figure 18-3).
Figure 18-3 Normalizing the color
Converting to ProPhoto RGB with relative colorimetric rendering preserved the LAB L* 50, a* 90, b* 72 values, while changing the RGB values to R 174, G 53, B 19. (We used ProPhoto RGB because converting the same pixel to Adobe RGB produced R 215, G 0, B 0—clipping both the green and blue channels—and LAB L* 53, a* 80, b* 69. It’s not that Adobe RGB is a bad space; it just doesn’t work well in the extreme reds with this particular camera and profile.)
Simulate the Output
In this workflow, our final output was known from the start—we’d printed other books on this press, and we’d already profiled it—so we went for relatively early binding. Before converting to CMYK, though, we opted to view a simulation of the CMYK conversion using Photoshop’s Proof Setup feature (see “Simulations and Soft-Proofing” in Chapter 12, The Adobe Common Color Architecture).
Optimize for Output
The soft proof immediately confirmed our fears—the predicted CMYK values of C 0, M 88, Y 89, K 0 produced corresponding LAB values of L* 52, a* 68, b* 48. We edited the image, still in RGB mode, while viewing the CMYK simulation, and by increasing saturation and reducing lightness we were able to change the predicted CMYK to C 0, M 91, Y 93, K 1, which we felt was as far as we could go in RGB mode. We decided to defer further editing until we’d converted to output CMYK.
Convert for Output
We converted the image to our output CMYK, using the settings that we’d determined worked best by looking at the soft proof—our heavy GCR press profile gave us the best saturation while still holding detail. One more edit produced a final output value of C 0, M 93, Y 95, K 2, LAB L* 50, a* 69, b* 48—a far cry from the original, but the best we could do in the circumstances (see Figure 18-4).
Figure 18-4 Converting for output
Proof the Output
Thus far, we’ve described the journey of our sample pixel from capture to output. But it also took some side-jaunts in the various proofing scenarios. Photoshop always does a conversion on the data sent to the display: to make the monitor reproduce our ProPhoto R 174, G 53, B 19, it had to send R 221, G 0, B 0 to the monitor. (You can’t get this information directly because the conversion happens under the hood, and it isn’t anything that normal people need to track anyway—we just mention it to illustrate that the pixel’s journey isn’t quite as straightforward as might seem at first glance.)
And it’s also mildly interesting that when we proofed the image on our Epson 2200 using Premium Luster paper, Photoshop sent R 245, G 41, B 102 to the printer to make it produce the same color as press C 0, M 93, Y 95, K 2.
Hand Off the Color
We saved the converted image as a CMYK TIFF with no profile embedded, and placed it in PageMaker, where the default CMYK source profile and the Separations profile were both set to our final output press profile. This ensured that our pixel had the final output profile assumed as its source, so no conversion would take place on output, but we could still enjoy accurate display and accurate inkjet proofing. The final image is shown in Figure 18-5—our pixel is in one of the petals on the left edge of the dahlia.
The Devil Is in the Details
Throughout this book, we’ve pointed out that color management is in essence quite simple, since it does only two things: define a color meaning and preserve that color meaning. But in a complex production workflow, you’ll encounter a host of details, each one of which must be addressed.
In Part I, we laid out the foundations for color management—the way we see color, the ways we make our devices produce color, the models we use to relate what we tell our devices to do with the results we see, and the basic operation of color management systems. We also pointed out the limitations of color management, and showed a few of the perceptual effects that the models simply don’t take into account.
In Part II, we told you not only how to build and tune profiles for your various devices, but also the things you must do before and after profiling to make sure that your devices behave—and continue to behave—the way their profiles predict. No color management system can compensate for uncontrolled device variation. We also pointed out the importance of the environment in which you make your color judgments—correct lighting is critical.
In Part III, we laid out the ground rules for parsing color-management workflows. We examined the color management features of some key applications, and walked you through their uses and their potential pitfalls, but if we’ve done our jobs correctly, we also gave you the vocabulary and insights necessary to analyze new applications, and to build a color management workflow that suits your unique needs.
The rest is up to you!