Dan Margulis Applied Color Theory

Color Management Workflows

Date: Wed, 26 Feb 2003 17:09:09 -0500
   From: "tbrain"
Subject: Color Management Workflows

I just finished REAL WORLD COLOR MANAGEMENT, and it has been very insightful. I am struggling to learn how to piece together my own color management "workflow" as well as how to make suggestions for clients who have expressed an interest.

I thought I had a good handle on SOURCE and DESTINATION profiles, but depending on the workflow choice below, I'm not entirely sure I'd know which profiles to use, particularly when it comes to tagging images and when to drop the embedded profile and reassign a new one.

Anyway, I've attempted to summarize the various color management workflows. I encourage feedback, clarification, and answers to the few questions I've added:

When implementing color management, there are several workflows in a print environment. Here are the major ones from which to choose (realizing some shops may choose a hybrid):

*** Scanner-Based Color Management: images are converted to CMYK during the scanning phase, using the scanner's profile for SOURCE and a proofer/press for DESTINATION.

*** Photoshop Color Management: digital photos or scanned images are converted to CMYK within Photoshop (or equivalent). The digital camera or scanner is the SOURCE profile and the proofer/press is the DESTINATION profile.

*** Application-Based Color Management: vector and raster images are placed into Quark 5 or the latest versions of InDesign, Illustrator, Freehand, or Photoshop. The application is able to color manage its own "native" objects, as well as RGB TIFF images (using either embedded, assigned, or assumed profiles). Questions: what does one use for the assumed SOURCE profile? I assume the DESTINATION profile is still the proofer or press. Can I use CMYK TIFF or does that defeat the purpose of color management at the application level?

*** PDF-Based Color Management: one can set up Acrobat Distiller to apply SOURCE and DESTINATION Profiles while converting PostScript to PDF. I assume all embedded ICC profiles are honored, unless specified otherwise.

*** Printer-Driver Color Management: there is an option to use Color Management in the Print Dialog Box, on both Mac and Windows, but my limited experience tells me to avoid it like VX gas ("the plague" seems so outdated). Although, it might work OK when printing Office application files or other non-PostScript data???

*** Queue-Based/Color Server Color Management: similar to PDF-based, one prints PostScript to a print spooler, which then assigns SOURCE and DESTINATION profiles.

*** In-RIP or Printer-Based Color Management: at this point, the color has already been CMYK-separated, but the CMYK color space for one device can be converted to simulate another CMYK device.

In-RIP color management is the workflow with which I am most familiar and currently using. The results are good and it's relatively easy to implement and maintain, although I believe additional benefits would also be gained by using the Scanner-based or Photo-Editing conversion. This appears to be the classic question: scan images into "raw" RGB on a high-end drum scanner and then use ICC profiles to convert to CMYK in Photoshop or let the scanner do what it was designed to do... I have yet to hear a definitive answer to this one.

I'm also not sure we'll be switching from an "Early-Binding" workflow (where color is converted into final output space as soon as possible) to a "Late-Binding" workflow anytime in the near future. As a print shop, 99.99999% of our work is to one of several Heidelberg Speedmasters, all with similar color characteristics.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thomas Brainard
Baesman Printing Corporation
4477 Reynolds Drive
Hilliard, OH 43026
The United States of America
P: 614-771-2300
F: 614-771-2323
http://www.baesman.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
____________________________________________________________________________

Date: Wed, 26 Feb 2003 20:13:53 -0700
   From: Andrew Rodney
Subject: Re: Color Management Workflows

on 2/26/03 3:09 PM, tbrain wrote:
 
I thought I had a good handle on SOURCE and DESTINATION profiles, but
depending on the workflow choice below, I'm not entirely sure I'd know
which profiles to use, particularly when it comes to tagging images and
when to drop the embedded profile and reassign a new one.

To make things more (or less) confusing, a profile can be a source or a destination depending on where it1s used in the workflow. For example, you have a scan and it1s tagged with a source profile (which describes the meaning of the numbers provided by the scanner). Now you want to convert into a Working Space (Adobe RGB). Simple. Now you1ve edited the file and you want to print it out. Well you convert FROM Adobe RGB (the source now but the destination previously) TO SWOP. So at one point Adobe RGB was the Destination and at one point the Source.

What you need to keep in mind is you always need to profiles (a source and destination). And this isn1t any different from the old days prior to profiles. We had sources and destinations we just didn1t use profiles.

*** Scanner-Based Color Management: images are converted to CMYK during
the scanning phase, using the scanner's profile for SOURCE and a
proofer/press for DESTINATION.

I wouldn1t recommend doing this (scanning into an output space) but yes, that1s one possibility.

*** Photoshop Color Management: digital photos or scanned images are
converted to CMYK within Photoshop (or equivalent). The digital camera
or scanner is the SOURCE profile and the proofer/press is the
DESTINATION profile.

Well yes but I don1t think it1s necessary to specify the actual devices here. That is, you could have received RGB data from the canner in your first example.

*** Application-Based Color Management: vector and raster images are
placed into Quark 5 or the latest versions of InDesign, Illustrator,
Freehand, or Photoshop. The application is able to color manage its own
"native" objects, as well as RGB TIFF images (using either embedded,
assigned, or assumed profiles).

Quark? Trying to do color management in Quark without 3rd party support is very dangerous. Quark is about as brain dead about color as MacPaint 1.0 was <g>

Questions: what does one use for the
assumed SOURCE profile?

Untagged data is always a guess. It1s (as Bruce Fraser likes to say) Mystery meat. You know the old saying about making assumptions don1t you? Untagged files are just a means or playing a nasty guessing game.

*** PDF-Based Color Management: one can set up Acrobat Distiller to
apply SOURCE and DESTINATION Profiles while converting PostScript to
PDF. I assume all embedded ICC profiles are honored, unless specified
otherwise.

PDF? That1s where the wonder from Bolder will enter the picture.

*** Printer-Driver Color Management: there is an option to use Color
Management in the Print Dialog Box, on both Mac and Windows, but my
limited experience tells me to avoid it like VX gas ("the plague" seems
so outdated). Although, it might work OK when printing Office
application files or other non-PostScript data???

Not at all if properly written. Photoshop1s print command is quite well behaved.

*** Queue-Based/Color Server Color Management: similar to PDF-based, one
prints PostScript to a print spooler, which then assigns SOURCE and
DESTINATION profiles.

Maybe. The big issue I have with this and the other kinds of conversions you asked about after (In Rip etc) is you don1t get to see what the conversions will do to the data. Doing in RIP (or Queue) conversions is wonderful as a workflow enhancement for production but you don1t get to see the color until the print comes off the printer. Can be dangerous (or let1s put it this way, you don1t get much chance to edit the file based on it1s output condition). While I recognize it1s wonderful for moving a lot of files through a printer (and since the data is RGB, repurpose is insured), you can1t really control the process to a fine degree like opening a file in Photoshop, setting up a soft proof with the output profile and editing (if necessary) based on the output device.

Andrew Rodney
____________________________________________________________________________

Date: Thu, 27 Feb 2003 11:30:52 -0700
   From: Chris Murphy
Subject: Re: Color Management Workflows

On Wednesday, February 26, 2003, at 03:09  PM, tbrain wrote:

*** Scanner-Based Color Management: images are converted to CMYK during
the scanning phase, using the scanner's profile for SOURCE and a
proofer/press for DESTINATION.

That destination profile immediately becomes the source profile for the post-converted (now) CMYK image.

*** Photoshop Color Management: digital photos or scanned images are
converted to CMYK within Photoshop (or equivalent). The digital camera
or scanner is the SOURCE profile and the proofer/press is the
DESTINATION profile.

Same as above.

*** Application-Based Color Management: vector and raster images are
placed into Quark 5 or the latest versions of InDesign, Illustrator,
Freehand, or Photoshop. The application is able to color manage its own
"native" objects, as well as RGB TIFF images (using either embedded,
assigned, or assumed profiles). Questions: what does one use for the
assumed SOURCE profile? I assume the DESTINATION profile is still the
proofer or press. Can I use CMYK TIFF or does that defeat the purpose
of color management at the application level?

Use an assumed source profile that makes the document look the way you want. Usually you want to make sure the document assumed profile (if CMYK) matches the intended destination in order to prevent conversion of native elements, like type. InDesign and QuarkXPress *will* convert black only type into four color black if the document (source) profile is not the same as the destination at print time.

*** PDF-Based Color Management: one can set up Acrobat Distiller to
apply SOURCE and DESTINATION Profiles while converting PostScript to
PDF. I assume all embedded ICC profiles are honored, unless specified
otherwise.

Distiller is a little confusing. It doesn't really  have source and destination profiles per se - rather it depends on context. If you are working with PDF spec 1.3 or higher, then profiles get embedded, the document does not get converted so there isn't a destination. EXCEPT in one instance where you specify converting the document to sRGB (as the color management policy).

If you are working with PDF spec 1.2 things are different and I'd avoid it.

*** Printer-Driver Color Management: there is an option to use Color
Management in the Print Dialog Box, on both Mac and Windows, but my
limited experience tells me to avoid it like VX gas ("the plague" seems
so outdated). Although, it might work OK when printing Office
application files or other non-PostScript data???

Correct.

*** Queue-Based/Color Server Color Management: similar to PDF-based, one
prints PostScript to a print spooler, which then assigns SOURCE and
DESTINATION profiles.

Actually it's assuming a source, then converting to a destination PRIOR to being handed off (by iQueue) to the printer.

*** In-RIP or Printer-Based Color Management: at this point, the color
has already been CMYK-separated, but the CMYK color space for one device
can be converted to simulate another CMYK device.

The color has not necessarily been separated to CMYK. It is possible to send RGB PostScript to a RIP and for it to do separations at RIP time. What you are saying (CMYK to CMYK conversion) is also possible.

In-RIP color management is the workflow with which I am most familiar
and currently using. The results are good and it's relatively easy to
implement and maintain, although I believe additional benefits would
also be gained by using the Scanner-based or Photo-Editing conversion.

You're the first person I've ever heard of successfully using in-RIP color management let alone PostScript color management. Do tell!

I'm also not sure we'll be switching from an "Early-Binding" workflow
(where color is converted into final output space as soon as possible)
to a "Late-Binding" workflow anytime in the near future.

In-RIP color management is synonymous with a late-binding workflow, by definition, UNLESS it is only used for proofing. So now I'm not following what you're saying.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________

Date: Thu, 27 Feb 2003 11:36:45 -0700
   From: Chris Murphy
Subject: Re: Color Management Workflows

*** PDF-Based Color Management: one can set up Acrobat Distiller to
apply SOURCE and DESTINATION Profiles while converting PostScript to
PDF. I assume all embedded ICC profiles are honored, unless specified
otherwise.

I forgot to full respond to this. Embedded ICC profiles in objects are stripped at print time and don't survive the conversion to PostScript unless they were embedded in EPS files. However, even ICC profiles in EPS files are ignored by Distiller. So embedded ICC profiles are NOT honored by Distiller.

Embedded CSA's in EPS files however, are converted into ICC profiles for those objects, by Distiller.

One thing to keep in mind is that a layout has multiple objects and elements. Each of these objects can have a profile associated with it, and PDF supports this. If the PDF has 20 images in it, plus text, each text element can have a profile, and each of the 20 images can have a profile. They could also share the same profile. The way profile embedding works in PDF is that the profile is embedded once, and then referenced to each object it applies to.

Once you have such a PDF, with ICC profiles in it, those profiles are honored for display purposes in Acrobat no matter what the Acrobat settings are (not sure about Acrobat Reader, haven't tried it). At print time however, it is possible to ignore those embedded profiles, pass them on as PostScript CSA's, or use them as sources for Acrobat to convert to a specified destination profile.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________

Date: Thu, 27 Feb 2003 17:26:56 -0500
   From: "tbrain"
Subject: RE: Color Management Workflows

Chris Murphy wrote:

You're the first person I've ever heard of
successfully using in-RIP color management let alone PostScript color
management. Do tell!

First, thanks for the feedback.

I'll try to clarify. What you call color management and what I call color management may be two different things (surprise!).

Here's my primitive but, mostly effective, "color" workflow:

  -Scan images into CMYK on drum scanner.

  -Place images into page layout.

  -Create Postscript (or EPS in the case of Rampage)

  -RIP job in Rampage

  -Ask Rampage to create proof data (TIF, CT, RTL) using SOURCE and DESTINATION profiles.
         Source = Kodak Approval.
         Destination = IRIS (or color laser or DesignJet inkjet proof).

Asked in all earnestness: is this NOT a color-managed workflow? It doesn't address all color management goals, but it does address one primary goal: using ICC profiles (generated by Gretag-MacBeth's ProfileMaker and Spectrolino/Spectroscan) to make various color devices match a target device, in our case our Kodak Approval.

So, I guess this really isn't In-RIP color management. It's a post-RIP process converting from one proofer's CMYK color space to another. What would I call this instead? Is this a Device Link?

Thom
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thomas Brainard
Baesman Printing Corporation
4477 Reynolds Drive
Hilliard, OH 43026
The United States of America
P: 614-771-2300
F: 614-771-2323
http://www.baesman.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
____________________________________________________________________________

Date: Thu, 27 Feb 2003 17:43:14 -0700
   From: Andrew Rodney
Subject: Re: Color Management Workflows

on 2/27/03 3:26 PM, tbrain wrote:
 
  -Scan images into CMYK on drum scanner.

Color Management is over now <g>. Well not really. You can at least see the data in a color managed environment, get an idea what your flavor of CMYK would look like on any other CMYK output device you have a profile for. But you1ve gone from RGB to CMYK in one operation (which does save time), the file is in an output space and I expect you1re pretty much done (except for getting ink to hit paper of course).

  -Place images into page layout.

  -Create Postscript (or EPS in the case of Rampage)

  -RIP job in Rampage

  -Ask Rampage to create proof data (TIF, CT, RTL) using SOURCE and
DESTINATION profiles.
         Source = Kodak Approval.
         Destination = IRIS (or color laser or DesignJet inkjet proof).

Ah, proofing! I forgot about that one <g>. Yes, even in a closed loop CMYK centric operation, you still want to do that and the CMS will help you. And yes, assuming you have good profiles for the Approval and Iris, you can (as you probably already know), simulate the Approval on the Iris when it1s not spilling ink all over the floor ;-)

Asked in all earnestness: is this NOT a color-managed workflow?

I'll let Chris answer his opinion but I1d say yes, that part of what your doing involves color management.
 
It doesn't address all color management goals, but it does address one
primary goal: using ICC profiles (generated by Gretag-MacBeth's
ProfileMaker and Spectrolino/Spectroscan) to make various color devices
match a target device, in our case our Kodak Approval.

I agree. You1ll likely need to use some profile editor to assist in 3forcing2 the Iris to match the Approval depending on how close you want them to match. What you1re doing is called cross simulation and I find that when I need to do this, some minor selective color edits in the proofer (Iris) profile is usually necessary even with the best built profiles (and I1d submit you have one of the best packages).

So, I guess this really isn't In-RIP color management. It's a post-RIP
process converting from one proofer's CMYK color space to another. What
would I call this instead? Is this a Device Link?

It could be done with a device link but that wouldn1t change the basic concept of what you1re doing. A device link is just a cousin of an ICC profile.

Chris, you1re up...

Andrew Rodney
____________________________________________________________________________

Date: Thu, 27 Feb 2003 21:24:53 -0500
   From: Jim Rich
Subject: Re: Color Management Workflows

 Thomas,

Let me ask this question, do the color results you get in your workflow make your employer and clients relatively happy? And do you use profiles to help you get those results in a dependable and straight forward fashion?

In academic terms your workflow might not fit into Chris's definition. Practically speaking, it sounds like you are having success with using profiles to get good color results.

If that is the case and in terms of modern day color management tools, it sounds like your workflow is color managed. Though, the way you work might not fit into an exact definition of color management. And from your first post, it sounds like you are using the profiles to your advantage for scanning, page layout and proofing (though I would stay in RGB and do the image editing before converting to CMYK).

Jim Rich
______________________________________________________

Date: Thu, 27 Feb 2003 17:56:20 -0700
   From: Chris Murphy
Subject: Re: Color Management Workflows

On Thursday, February 27, 2003, at 03:26  PM, tbrain wrote:

Asked in all earnestness: is this NOT a color-managed workflow?

It is color managed. And not because ICC profiles are being used for proofing, but because there is a clearly defined workflow for handling color.

It doesn't address all color management goals, but it does address one
primary goal: using ICC profiles (generated by Gretag-MacBeth's
ProfileMaker and Spectrolino/Spectroscan) to make various color devices
match a target device, in our case our Kodak Approval.

Specifically

So, I guess this really isn't In-RIP color management. It's a post-RIP
process converting from one proofer's CMYK color space to another. What
would I call this instead? Is this a Device Link?

Hmm terminology - what fun :) Umm, I think I'd classify it as a prepress color management based workflow product since you're referring to Rampage. In-RIP color management refers to color management actually occurring in the RIP itself at RIP time. This is generally quite rare, and mostly useful only in proofing scenarios because of the near total lack of control. Color management workflow products for prepress have quite a bit more control than the in-RIP category.

DeviceLink profiles are a totally separate class of ICC profile where the source and destination are concatenated into a single DeviceLink  profile that is unidirectional and doesn't contain a PCS (conversions occur directly from source to destination space without using CIELAB or CIEXYZ as the connection space between the two device spaces). I think Rampage supports DeviceLinks in addition to the Display, Input and Output class of profiles (device profiles), but I'm not sure. There can be significant advantages to using a DeviceLink in proofing and repurposing scenarios, instead of two Output device profiles (as source and destination). We discuss this on 427.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________

Date: Thu, 27 Feb 2003 19:33:49 -0700
   From: Chris Murphy
Subject: Re: Color Management Workflows

On Thursday, February 27, 2003, at 03:26  PM, tbrain wrote:

It doesn't address all color management goals, but it does address one
primary goal: using ICC profiles (generated by Gretag-MacBeth's
ProfileMaker and Spectrolino/Spectroscan) to make various color devices
match a target device, in our case our Kodak Approval.

I wrote:

Specifically

Yeah - it probably would be a good idea for me to finish my sentences...

Specifically using ICC-based color management here *GENERALLY* makes it pretty clear cut and dried that this part of the workflow is color managed. Other areas of the workflow where ICC-based color management is not being used does not inherently mean that the workflow is "not color-managed." When ICC-based color management isn't being used, color management may still be happening, you just have to look a little deeper at how color issues are being handled by human blobs and their equipment.

Likewise, even if you use ICC-based color management, it is possible for the workflow to NOT be color managed. One can use ICC-based color management improperly and have color mismanagement. Color management isn't self-audited.

The summary here, and bottom line is that "color managed workflow" as a term is something that is defined in context. I have a tendency to look at things as a combination of equipment, tools and humans. Color management is typically seen as just equipment and tools, but I prefer to include a human element into the definition because humans are the ones doing the managing. If they aren't doing the managing, this stuff simply doesn't work push button (and even if it did, who's pushing the buttons?).

I digress...

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
____________________________________________________________________________

Date: Fri, 28 Feb 2003 08:23:59 -0500
   From: "tbrain"
Subject: RE: Color Management Workflows

Jim,

Yes. In general, my employer and clients are very happy with the proofs.

Since we've switched to Rampage's ICC profile workflow (post-RIP, pre-Proof...PRPPICCCM Workflow), it provides a more consistent process for managing color anytime we add a new color proofer/device to the mix. (As opposed to the old method where we had to learn the intricacies of each devices color tools.)

As Andrew pointed out yesterday, using raw unedited ICC profiles will get you close, but for an ideal "match," some editing of the ICC profiles has to take place. And we do edit our profiles in Gretag-MacBeth's Profile Editor. It usually takes a few stabs at the color until we're satisfied. (As I told Andrew, it's hard to say when a color "match" is as good as it can be...usually I find it's time to quit when I discover that our fourth attempt is better than our sixth.)

Unfortunately, there are times where the proof doesn't quite match the press sheet close enough. It's not often, but when it happens it does leave us scratching our heads. Oh sure, we can pull out our GATF press sheets and show the customer how great our gray balance is and how well the GATF images match from proof to press, but there are still situations where we feel the color match could be closer.

I guess, deep down, we all know there is no such thing as a perfect color match... But, it would be nice to know that we've done the best match possible. Some of that's luck. Some of it's skill. Experience is also critical. I suspect many of us are self-taught, so we never quite know what it is that we don't know.

Thom

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thomas Brainard
Baesman Printing Corporation
4477 Reynolds Drive
Hilliard, OH 43026
The United States of America
P: 614-771-2300
F: 614-771-2323
http://www.baesman.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
____________________________________________________________________________

Date: Fri, 28 Feb 2003 09:34:42 -0500
   From: "tbrain"
Subject: RE: Color Management Workflows

So... If one wanted to learn more about implementing color management into "real world" situations--say at a client's location--where would one go for hands-on training?

I've taken note of GATF/PIA's Color Management Workshops, but the descriptions make it sound like we're just going to learn how to use a variety of spectrophotometers and profile packages to make ICC profiles.

Not that my ICC profile creation skills are "expert" level, but I'm more interested in workflow implementation, not profile creation.

Of course, there's the annual Color Management Conference, which I think takes place in Phoenix in December. That's pretty far off, and I'm afraid it would simply cover esoteric topics such as "metamerism" and "CIE LAB vs. XYZ LAB," topics that are of more importance to color management product developers and vendors than end users.

 How does an end user, say one of my clients, learn to implement color management? So far, I've seen two books on color management: REAL WORLD and GATF's. Both are good, but books only take one so far...

Thanks,

Thom

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thomas Brainard
Baesman Printing Corporation
4477 Reynolds Drive
Hilliard, OH 43026
The United States of America
P: 614-771-2300
F: 614-771-2323
http://www.baesman.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
____________________________________________________________________________

Date: Fri, 28 Feb 2003 10:53:50 -0500
   From: Jim Rich
Subject: Re: Color Management Workflows

Thom,

As you have pointed out there are different levels of training needs.

The GATF/PIA's Color Management Workshops are very good and cost effective for introducing someone  to color management and getting them thinking the right way to make it work. GATF even offers an advanced class that is quite good.

I find, once you get to the next level you have to either start networking with more advanced color management types or hire an expert to come to your site and train you on your workflow.  If you have never hired a consultant then you might want to check out some tips I have for hiring one. http://www.photoshopfocus.com/tips.htm

Jim Rich
____________________________________________________________________________

Date: Fri, 28 Feb 2003 11:58:05 -0500
   From: Kim Oravecz
Subject: RE: Color Management Workflows
 
Another place you might want to check out is the Graphics Intelligence Agency:

http://www.graphintel.com/

They offer 2 day color management seminars and then they also offer one specifically for Gretags Profilemaker both at their site -or- they will come out to you.

. . . Kim

Adobe Photoshop training classes are taught in the US by Sterling Ledet & Associates, Inc.