Color Workflow

From ColorWiki

Revision as of 18:48, 18 August 2006 by Chromix (Talk | contribs)
Jump to: navigation, search
Reserved Article

This page is a
Reserved Article.
For more details see
Reserved ColorWiki Articles

ColorNews

This reserved article originally appeared in CHROMiX ColorNews Issue 4 on July 31, 2001.

Click here to see the original in its original context.
Email
colornews(at)chromix.com to subscribe to the ColorNews newsletter.

by Steve Upton


I think it's about time to talk about workflow.

This article got a little long but when I tried to break it in half for next month I couldn't find a place that wouldn't make me frustrated if I were reading it myself. I always hated that "...to be continued" bit just when the show was getting interesting. So, here it is in all its mass.

Workflow, really, is where I find most people wanting to know the answers. This rubber-meets-the-road part of color management seems to where people start the journey of managed color and the majority of questions in our speaking and training sessions fall in this area. People really just want to know how to make this stuff work.

I always say that you only need two things to have good color: great profiles and proper use of them in your workflow. Even with perfect profiles, improper use of them will create frustration for you.

It helps to understand how all this stuff is to fit together if you start with some basic ideas and strategies:

  1. Anything that comes from a device will be in that device's color space and images headed out to a device should be in its color space. This means that your scanner is going to give you ScannerRGB and your monitor, printer, and press should be handed YourMonitorRGB, YourPrinterCMYK (or RGB) and PressCMYK respectively. These device-specific numbers are the reason why we build a good profile for each individual device.
  1. The location in your workflow where the conversion from one set of settings occurs (say ScannerRGB to PressCMYK) is changeable and will probably depend on your business, equipment, funds, time and other factors. This flexibility is powerful but contributes to the confusion surrounding color management.

So, let's take a hypothetical example of a scanner, monitor, printer and press. You would like to scan an image, have it look good on your monitor, separate it to PressCMYK, soft proof it on your monitor, and then hard proof it on the printer. Sound familiar?

Looking at just one of these conversions, ScannerRGB to PressCMYK, we see that we can do it many different places: RGB->CMYK in the scanner software, in Photoshop, in QuarkXpress, in the printer driver, in a color server, or in the RIP.

No wonder this stuff is so confusing!

I have counted 4 different ways of doing the conversion in Photoshop alone!

It is important to realize that after the file is separated to PressCMYK it needs to remain unaltered for the rest of its journey to the press. Although it may take side routes to the monitor and printer for proofing, your color for the press is done.

The best method to deciding what is right for you is to use the following criteria:

Most workflows can be roughly divided into single/raster image and composite/postscript images like created with a page-layout application.

In the single/raster image situation you have, for example, a great TIFF file that does not need to be joined by any other elements. Printing these files directly from Photoshop is usually the best course of action. You can either apply the profiles "by hand" in Photoshop using the "Convert to Profile" command or allow Photoshop to perform the conversion on the fly as you print.

When you have composite/Postscript images, like a brochure composed in QuarkXpress, then your life becomes quite a bit more complicated. One single file can contain TIFF's, EPS logos, and QuarkXpress elements (boxes, etc). QuarkXpress 4.1 does have some color management capabilities built-in but cannot manage embedded EPS files and does not allow all the control over color conversions that you may need.

For our example, say we have such a file and we would like to view it on screen (soft proof), print it to our printer (hard proof) and then send it off to press. If the job is only intended for press then I typically suggest that images be converted to CMYK prior to placing in Quark. This also fits most traditional workflows.

To soft-proof to screen, Quark needs to be set with the correct PressCMYK profile and your monitor profile. With the image previews set to 32 bits Quark will do a fair job of proofing to screen but EPS images are still unhandled.

Hard proofing is simply not going to work with Quark for our example due to the EPS problem.

Sending the job to press will work fine however as it's all in PressCMYK and was separated properly in Photoshop.

So what about the hard proof problem? This is an example of several places in today's workflows where color management breaks down due to applications not fully supporting all the features we need. Feel free to bug Quark about this one next time you have their attention, we all need this to work properly in version 5.

There are three solutions to this problem.

  1. CompassPro XT is a Quark-specific solution that comes in the form of a Quark Xtension. CP XT allows you to setup the conversion preferences and then interrupts the printing process to convert the document elements on their way out to your printer. It works well but only for Quark and you will need a copy for each member of your workgroup.
  1. Get a RIP for your printer that will allow you to load the PressCMYK and printer profiles and will perform the proofing conversion for you. This is becoming the most popular choice in digital prepress proofing today. A good RIP will do this job quickly and accurately and this will avoid the need to do this on each machine in a workgroup.
  1. The most powerful and flexible solution is a color server. Color servers are applications that reside on a server (not necessarily dedicated) on your network and perform color conversions for your whole workgroup. Most color servers work at minimum with hot folders, processing files dropped into one folder and placing the results in another. You can setup print queues to appear on the network and forward the resulting files to printers, RIP's etc with your existing server software. A full-featured color server will setup its own queues and hand off the files for you.

Color Servers have notable advantages over Quark plug-ins and in-RIP proofing:

There are other benefits of servers but these are some of the most significant. Suffice to say that if you are finding a break in your workflow due to some finicky software, a color server can probably be used to work around it.

Some feel color servers are simply a temporary solution until the OS, applications and RIPs get up to speed with color. I think this is partially true but they have other benefits that will continue make them valuable. Either way we have several years ahead of us before things are updated to the point where you would shut one down and in the meantime we all have better things to do with our time no?

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox