CMYK workflow

[Tech]

Hi All,
We have a typical Adobe RGB '98 workflow on most images because CMYK images simply doesn't look good to designers. Aside from stating the obvious that final product output is CMYK, what's another good way to explain and convert every designer to get used to working with CMYK images?

I would like to suggest using a generic CMYK profile for all images because we don't have a color management environment. Input profile is never the same as output and everything in between. Also doesn't most printers, if not all, ignore embedded profiles that isn't matching the press profile?

Thanks all in advance for any useful feedbacks.

 

[disbellj]

Re: CMYK workflow

I'll be glad to be corrected, but yes I believe most printers are not color managing incoming CMYK. They just print the CMYK numbers they receive (just like Adobe and Quark do in their color setups).

Having said that, it would be good for customers to soft-proof (not that mine do, they just use the defaults and so are opening CMYK image files and looking at them in the context of the default SWOP profile - without paper simulation, which is good since I don't print on SWOP paper, and they wouldn't actually see paper simulation unless soft-proofing and checking 'Simulate Paper Color', which I wouldn't want them to do unless they had a profile that actually described how the color looks when printed on our paper with our dot gains and densities). For them to know what the image/color will actually look like when printed, they must have an ICC profile to soft-proof final output with - an ICC profile that describes the press/paper/ink combo that it will be printed on. Since my custom press profile is not always good for soft-proofing (has some problems; the profile was made by my proofing rip and only sufficient to be used with the proofing rip), I don't ask my customers to soft-proof yet.

But once I move to GRACoL2006_Coated1 (after press and plates and proofs are verified for compliance), then I will use that coated CMYK profile in all programs as CMYK profile (TAC will be low enough to use coated separation if need be for coated or uncoated printing), and will use black channel of that profile as my grayscale profile. I will then be able to use these profiles for conversion and building (all while soft-proofing), and hardcopy proofing. I'll also be able to give to the same profiles (my coated and uncoated CMYK and grayscale profiles) to customers for conversion and building (all while soft-proofing if going by my directions), and hardcopy proofing (also going by my directions).

To soft-proof, one needs a calibrated and profiled monitor, and then in Photoshop, go to View menu > Proof Setup > Custom... and set CMYK profile as the Device to Simulate (hopefully conforming to international standard, such as GRACoL2006_Coated1 or ISOcoatedv2 for coated, ISOuncoated for uncoated, or custom profiles). If soft-proofing CMYK, you'll want to check 'Preserve CMYK Numbers'. If soft-proofing RGB or Lab, you'll need to use a Rendering Intent (the same one you intent to use for the actual conversion when it is done), and decide to use Black Point Compensation or not (also do the same in the actual conversion). For Display Options (On-Screen), check both 'Simulate Paper Color' and 'Simulate Black Ink'. Now save the Proof setup and you'll be easily able to choose it from the View menu > Proof Setup list. Make a Proof Setup for CMYK (remember 'Keep CMYK Numbers'), RGB and Lab (can make multiple ones with different rendering intents, some with BPC and some without if you want), for coated and for uncoated papers or whatever papers you print.

HTH.

Don

 

[Tech]

Re: CMYK workflow

Hi Don,
When you are not color managing incoming CMYK files, does it mean you guys do with incoming RGB files and convert them to you press profile?

If I understand you correctly, you prefer receiving CMYK files so there's less or no extra messing around on your end correct? What if our group actually thinks convert RGB files to CMYK is vendor's responsibility and that by converting RGB at the last prepress stage yields best results (after all, once the colorspace is changed, data is lost)? Do you think that's a good assumption on their part or just them trying to hold vendors responsible for the outcome?

I'm fighting an up hill battle here. I'm all for a strict CMYK workflow because I don't buy the idea of working in RGB and somehow if we work in CMYK workflow we'll screw up or compromised our image qualities.


Thanks for the detail explanation.

Tech

 

[disbellj]

Re: CMYK workflow

Tech,

"Hi Don,
When you are not color managing incoming CMYK files, does it mean you guys do with incoming RGB files and convert them to you press profile?"

No. Right now I convert them with the default SWOP profile (just like my customer does). I then proof them using my custom press profile (basically is would be seen as the CMYK assuming my press profile, or my press profile being assigned, before conversion to the proofer profile). This is because I can't use my custom press profile since it was made with a proofing rip and can only be used on that proofing rip. Sucks but true, and why I'm really wanting to move to using standard profiles).

Put it like this, I send the same SWOP CMYK image numbers and/or PANTONE-provided CMYK numbers and/or customer's custom CMYK numbers (none changed by me) to my proofers and plates:
For my Sherpa imposition proof, I use the SWOP profile as source in the conversion, Relative Colorimeric Intent conversion to my Sherpa custom proofer profile which is the destination, and printed on the Sherpa (so the paper is not simulated here, and the Sherpa proof shows exactly what is seen in Photoshop, within limitation of Sherpa).
For my Epson quality contract proof, I use my custom press profile as source in the conversion, my proofing rip uses Absolute Colorimetric Intent to do the conversion to my custom proofer profile which is the destination, and prints on the Epson (so the paper is simulated here, and the Epson shows what my press sheet will look like).
I can say that both proofs match closely. I can also say that if I was using the same profile as source for both - GRACoL2006_Coated1v2 - that the proofs would be virtually identical (so yes closer than I get now, but what I get now is close).

"If I understand you correctly, you prefer receiving CMYK files so there's less or no extra messing around on your end correct?"

Yes. If you have RGB, you may decide to use Perceptual Rendering Intent, where I would probably use the default (which also happens to be the safest rendering intent to use, and gives the closest colorimetric match to the source color within limitation of the destination gamut). So you may get a better conversion of out-of-gamut colors than I would get, but for consistency and to get the closest match colorimetrically to the colors that came in, I would use the default Relative Colorimetric.

"What if our group actually thinks convert RGB files to CMYK is vendor's responsibility and that by converting RGB at the last prepress stage yields best results (after all, once the colorspace is changed, data is lost)? Do you think that's a good assumption on their part or just them trying to hold vendors responsible for the outcome?"

Make sure you embed the RGB profiles in every image, or no telling what you'll get. I honor embedded profiles and don't get any complaints. For untagged RGB, I assume sRGB IEC61966-2.1 (because Adobe RGB (1998) gave me sunburned faces when I used to use it).

"I'm fighting an up hill battle here. I'm all for a strict CMYK workflow because I don't buy the idea of working in RGB and somehow if we work in CMYK workflow we'll screw up or compromised our image qualities."

It doesn't matter to me. Whether I continue printing this way, or start using GRACoL2006_Coated1v2 profile for conversions and proofs (requires also setting up press using G7 to match proofs). If I do move to GRACoL2006_Coated1v2, using GRACoL2006_Coated1v2 profile to do the conversion, of course incoming RGB will look closer to intended appearance when printed than SWOP images printed. Why? Because the image is converted to the actual paper/ink/density/TVI that the image will be printed on. Will some new proofs of reprints not match the previous prints? Images overall will look the same. Individual colors may not, and that's when I would scan the printed piece (if the customer had a problem with the proof and said they wanted to match the previous printed piece) to get Lab values, and use color management (RelCol, BPC, GRACoL2006_Coated1v2 profile) to get new CMYK values so that that specific color does closely match last time when printed this time. I've looked that the different approaches and this one is what I use and intend to use.

Don