Print CMYK and RGB Devices | Photoshop Training with Dan Margulis

Dan Margulis Applied Color Theory

Printing CMYK to an RGB Device

Date: Tue, 20 Apr 2004 08:55:52 -0600

From: Ron Kelly

Subject: printing CMYK to an RGB device

Most knowledgable and humble Group:

Printing to a cmyk device is very straightforward for us old photographers. I understand the color space and can get good results when things are destined for off-set.

When printing to an rgb device such as an Epson ink-jet, you need to send rgb data. Why is that? The printer uses cmyk inks, right?

Perhaps it's because the manufacturers think photographers are not sophisticated enough to do a reasonable conversion.

My problem is, learning the rgb colorspace looks about as easy as learning a second language. Setting white and black points is easy, but what about the colors in the middle that aren't neutral? Sheesh.

To take advantage of the larger gamut of the rgb device I need to send it rgb data, which I cannot work with very well. Fine tuning color, accentuating shadow detail and other activities best suited for cmyk are no longer possible. You adjust a curve a little bit in rgb and the image veers for the opposite ditch. Michael Schumacher doesn't use a sledgehammer for his corrections either, I'll bet.

What about simply using a larger cmyk gamut? Is is possible to define one thusly, thereby preserving the entire gamut of my digital camera upon conversion? Then I could use my cmyk techniques and keep the larger gamut, having the best of both worlds.

I presently use a RIP that can send cmyk data to the printer, so no problem there. I just want to keep the maximum color, but be able to work in cmyk. Should that be so difficult?

Your thoughts and feedback are very welcome.

Cheers,

Ron Kelly

___________________________________________________________________________

Date: Tue, 20 Apr 2004 12:01:30 -0700

From: Paul D. DeRocco

Subject: RE: printing CMYK to an RGB device

There's no intrinsic reason why RGB should be harder than CMYK. Indeed, the fact that you don't have a separate black channel simplifies things. Remember, the colors are complementary, so R really is just C upside-down, etc. You're just used to think in terms of color being something that absorbs light, so higher numbers make a darker picture. In RGB, it's the other way around, because you're adding light, rather than adding darkening.

Ciao, Paul D. DeRocco

___________________________________________________________________________

Date: Tue, 20 Apr 2004 14:36:16 -0400

From: Ed Atkeson

Subject: Re: printing CMYK to an RGB device

Ron, I know the feeling.

Try this, adjust as if you were in cmy, in rgb. Just substitute cmy for rgb in your mind and go for it. Setting your info palette to give cmyk values helps too.

best,

Ed A

___________________________________________________________________________

Date: Tue, 20 Apr 2004 11:41:09 -0600

From:Andrew Rodney

Subject: Re: printing CMYK to an RGB device

on 4/20/04 8:55 AM, Ron Kelly wrote:

When printing to an rgb device such as an Epson ink-jet, you need to

send rgb data. Why is that? The printer uses cmyk inks, right?

Quickdraw and GDI drivers don1t understand CMYK. In addition, while the Epson1s and so on DO print using CMYK (or CcMmYK or more), there1s a 3black box2 in the middle of the process (these print drivers) that need to produce a very specific and proprietary conversion. So if you send CMYK to these devices, the printer/Black box simply does a heinous CMYK to RGB conversion since it needs RGB data to produce it1s CMYK (or CcMmYK) conversions. With a RIP you can bypass this black box and send CMYK directly to the same printer. So this is a driver issue, not a printer hardware issue.

My problem is, learning the rgb colorspace looks about as easy as

learning a second language.

I don't see why. RGB is much easier to deal with than CMYK. At least with RGB in a well behaved working space whenever you have equal amounts of RG and B, you have a neutral. There isn't a CMYK device on this planet that you can guarantee will produce a neutral with a fixed numeric value of CMYK throughout the tone scale that will produce the same results on any other CMYK device.

Setting white and black points is easy, but

what about the colors in the middle that aren't neutral? Sheesh.

CMYK is NO different. Take an RGB image, in Photoshop put an eyedropper on any color in the middle, open the Convert to Profile command and toggle as many CMYK profiles as you have and tell me that the numbers don't change. They do. Every CMYK process will require a different mix of CMYK to produce the same color appearance. CMYK is device dependent. RGB is too but RGB working space are Quasi-Device Independent in that they are not based on any real world device. So they are constructed so we do get this gray behavior although all the "middle" colors will be different in each working space.

What about simply using a larger cmyk gamut?

Which CMYK gamut? Why such a small gamut? For every CMYK device (and there are plenty) using every possible kind of CMYK ink or similar material and paper, you get a different CMYK value and gamut. And since you really can't send CMYK to these and many other devices (Lambda, Lightjet, Pictography, etc), why deal with CMYK? IF you need to produce an image on a device that expects CMYK, send it CMYK. IF you need to produce an image on a device that expects RGB, send it RGB. What would you be using if you had to publish an image on the world wide web, or a video?

I just want to keep the maximum color, but be able to

work in cmyk. Should that be so difficult?

CMYK is a highly device dependent color space. RGB is far less so. With a good, wide gamut RGB file, I can convert to as many CMYK color spaces as I need all with different black generation, UCR/GCR AND I can send to as many RGB devices as I need. The RGB file is smaller, it contains more colors (gamut) and it can be converted as often as I like to as many color spaces as I need. CMYK by it's very nature is a color space based on ONE device (the device you converted to for output). CMYK is very limited and inflexible.

Lastly, every capture device and scanner on this planet produces RGB.

Andrew Rodney

http://www.digitaldog.net

___________________________________________________________________________

Date: Tue, 20 Apr 2004 12:06:15 -0600

From: Chris Murphy

Subject: Re: printing CMYK to an RGB device

On Apr 20, 2004, at 8:55 AM, Ron Kelly wrote:

When printing to an rgb device such as an Epson ink-jet, you need to

send rgb data. Why is that? The printer uses cmyk inks, right?

Perhaps it's because the manufacturers think photographers are not

sophisticated enough to do a reasonable conversion.

The operating systems are the limiting factor. They don't know what CMYK is. So a print job going to a non-PostScript printer must be converted to RGB by the sending application first. Then the driver deals with the necessary conversion. Mac OS X theoretically could deal with CMYK starting with OS X 10.3.x but as of yet there are no native drivers that accept CMYK data. So in practice it's still RGB and will likely remain that way with the manufacturer drivers.

Second, ink jet printer behave in no way like a litho press. The native behavior of ink jet printers is totally bizarre, and extremely dependent on the media used. The media type settings alter the RGB to CMYK conversion in terms of ink limits, gray balance, and black generation, so that these necessary functions are masked from the user. And the photo printers are dealing with at least six inks which means a 600% to often less than 250% ink limit. The sophistication of ink limiting and black generation to deal with this kind of drop is substantial and beyond the vast majority of users out there. The manufacturer drivers must cater to a wide range of users with their drivers.

My problem is, learning the rgb colorspace looks about as easy as

learning a second language. Setting white and black points is easy, but

what about the colors in the middle that aren't neutral? Sheesh.

It would be a lot worse if we had access to CMYK let alone the full native number of channels of the printer.

I presently use a RIP that can send cmyk data to the printer, so no

problem there. I just want to keep the maximum color, but be able to

work in cmyk. Should that be so difficult?

Yes, because inkjets aren't printing presses. Their natural behavior defies comparison. Only through masking native behavior do you get something reasonable worth working with, and at that point you rapidly lose the per channel control you get with a CMYK RIP. As I previously mentioned, the photo printers aren't even CMYK.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Tue, 20 Apr 2004 15:29:00 -0700

From: Paul D. DeRocco

Subject: RE: printing CMYK to an RGB device

From: Andrew Rodney

I don't see why. RGB is much easier to deal with than CMYK. At least with

RGB in a well behaved working space whenever you have equal amounts of RG

and B, you have a neutral. There isn't a CMYK device on this planet that you

can guarantee will produce a neutral with a fixed numeric value of CMYK

throughout the tone scale that will produce the same results on any other

CMYK device.

The neutrality of equal RGB values is only true of abstract color spaces. If you work in a device space, then it's not true any more. That may be a dumb thing to do in RGB, but that's the moral equivalent of what people do in CMYK.

Ciao, Paul D. DeRocco

___________________________________________________________________________

Date: Tue, 20 Apr 2004 17:01:40 -0600

From:Andrew Rodney

Subject: Re: printing CMYK to an RGB device

That1s what I said. That1s why we want to bring images into these RGB working space for editing. One can edit in input or output RGB color spaces but then that nice neutral value from equal parts of RGB files out the window.

What I might not have been clear about was the term "well behaved working space" which means, one of the synthetic Quasi-Device Independent spaces we have to choose from with Photoshop.

Andrew Rodney

http://www.digitaldog.net

___________________________________________________________________________

Date: Tue, 20 Apr 2004 21:22:14 -0600

From: Ron Kelly

Subject: Re: printing CMYK to an RGB device

On 20-Apr-04, at 11:41 AM, Andrew Rodney wrote:

I don't see why. RGB is much easier to deal with than CMYK. At least with

RGB in a well behaved working space whenever you have equal amounts of RG

and B, you have a neutral.

Yes, yes, we all know that. Sometimes neutrals ARE very important, no doubt about that. But what about all the other colors? Skin tone? Wood of various colors? I understand what ratios to look for in CMYK but with RGB, the numbers all look like a foreign language.

You make it sound develishly difficult to know what makes a neutral in CMYK. It's not that tough; just like the books says - cyan 5 to 10 points higher, magenta and yellow equal. The amount of black is irrelevant.

CMYK is NO different. Take an RGB image, in Photoshop put an eyedropper on

any color in the middle, open the Convert to Profile command and toggle as

many CMYK profiles as you have and tell me that the numbers don't change.

They do. Every CMYK process will require a different mix of CMYK to produce

the same color appearance. CMYK is device dependent.

That's not a particular concern to me. I want to be able to print to a SPECIFIC device and control it precisely. I don't particularly care what happens in a theoretically more neutral colorspace which could apply in different situations. That's not my situation; I want to make beautiful prints on MY printer.

Which CMYK gamut? Why such a small gamut? For every CMYK device (and there

are plenty) using every possible kind of CMYK ink or similar material and

paper, you get a different CMYK value and gamut.

Ah, now we're getting somewhere. I have a paper I like, and I have some inks I like. How do I define the gamut? Maybe I should just define my own custom CMYK conversion with a higher ink limit than the 340 I typically use for off-set. Wouldn't this give me a larger gamut?

It seems to me that the printer has the gamut. My difficulty is not that the printer's gamut is too small, but that the CMYK colorspace I'm working in is too small. If I send some RGB files to the printer, the blues are much richer, no doubt.

CMYK is a highly device dependent color space. RGB is far less so. With a

good, wide gamut RGB file, I can convert to as many CMYK color spaces as I

need all with different black generation, UCR/GCR AND I can send to as many

RGB devices as I need.

Right. Maybe some folks out there are sending their files thither and yon to all kind of devices to be purposed by someone else perhaps. It's more important to me to control the color precisely for my situation.

If I were to write a book and translate it into different languages, I'd have no choice but to trust the translators to do a proper job. If my prose is delicately nuanced, with many ambiguities, I'd have to expect less than perfect results. It may be beyond ANY translation to be perfect.

That's why I'm staying in my native tongue. The question is, if we're finishing up in English and I'm sending English to the printer, why does translation have to enter into it?

I don't like the idea of driver changing my files into what IT thinks is the best result. I'm not talking about CMYK to CcMmYK translations, I'm talking about rgb to CcMmYK translations or the like. If the printer has to have CMYK anyway, why can't I have the controls?

Probably the feature that I'd miss the most if I were unable to work in CMYK is hiking the contrast in the shadows. I just don't know how to do this in rgb, and I need to use it most of the time.

Lastly, every capture device and scanner on this planet produces RGB.

And nearly every print on this planet is made in CMYK. That's just physics.

___________________________________________________________________________

Date: Tue, 20 Apr 2004 21:25:54 -0600

From: Ron Kelly

Subject: Re: printing CMYK to an RGB device

On 20-Apr-04, at 12:06 PM, Chris Murphy wrote:

The operating systems are the limiting factor. They don't know what

CMYK is. So a print job going to a non-PostScript printer must be

converted to RGB by the sending application first. Then the driver

deals with the necessary conversion. Mac OS X theoretically could deal

with CMYK starting with OS X 10.3.x but as of yet there are no native

drivers that accept CMYK data. So in practice it's still RGB and will likely remain that way with the manufacturer drivers.

If that is the case, all I can do is ask why? It seems like such a cop-out.

Why hasn't this problem been solved, except by specialty RIP engineers?

Ron Kelly

___________________________________________________________________________

Date: Tue, 20 Apr 2004 21:27:28 -0600

From: Ron Kelly

Subject: Re: printing CMYK to an RGB device

On 20-Apr-04, at 12:36 PM, Ed Atkeson wrote:

Ron, I know the feeling.

Try this, adjust as if you were in cmy, in rgb. Just substitute cmy for rgb

in your mind and go for it. Setting your info palette to give cmyk values

helps too.

Ed:

Thanks. I'll probably have to give it the old college try, but I just want you to know that I've got other things to do. I really don't want to learn a new colorspace, if I don't have to.

Ron Kelly

___________________________________________________________________________

Date: Wed, 21 Apr 2004 12:13:37 -0000

From: Stephen Marsh

Subject: Re: printing CMYK to an RGB device

Here is my take, based on no facts apart from what I have picked up...

Forgetting about PostScript and RIPs which do know what INK is.

The non PS print pipelines are translations of a monitor display language (QuickDraw on classic Mac for example). So thus RGB.

Now I will wait for Chris, Andrew and the others who live and breath this stuff to correct me if I am wrong. <g>

The CCW (current conventional wisdom) for RGB inkjets is to work in a safe neutral RGB and editing space slightly larger than the gamut of the output and to convert on the fly during printing to the profiled RGB output of said device...and the ICC gods will perfectly transform the working image into the output.

One can convert to the profile instead and tweak in a 'non safe' RGB device space if one is not happy with the results of the on the fly conversion (just like CMYK, one can only do a conversion or tweak the conversion too)...and send through unaltered values to the printer.

And no - getting neturals from a device space (either CMYK or RGB) is not rocket science, as some make out. Sure the ratio of inbalance (or balance?) is not linear from highlights to shadows...but with a valid profile to assign and LAB readings it is easy to establish PERFECT values which equate to a true neutral of 0A 0B in LAB.

There are various ways to work the shadows in RGB, using either masks and or blend if sliders to isolate the shadows for curves, contrast masks or using the new shadow/highlight command of CS.

Stephen Marsh.

___________________________________________________________________________

Date: Tue, 20 Apr 2004 23:58:20 -0700

From: Paul D. DeRocco

Subject: RE: printing CMYK to an RGB device

From: Ron Kelly

It seems to me that the printer has the gamut. My difficulty is not

that the printer's gamut is too small, but that the CMYK colorspace I'm

working in is too small. If I send some RGB files to the printer, the

blues are much richer, no doubt.

I think inkjets that take RGB input are designed so that their native RGB color space can push the printer pretty much to the limit of the gamut possible with the ink and the paper. For instance, there should be some RGB combo, probably equal R and G, that gives pure yellow ink, and so on.

You're approach is that of a craftsman, someone skilled with particular inks and papers, who mixes them perhaps like a painter mixes paint. RGB inkjets require that you rely on their translation, where a profile is used to convert to the printer's RGB space, and then back to the monitor's RGB space, to get the best possible proof of what the print will look like given the gamut of the monitor. With good profiles, this workflow works very well.

If I were to write a book and translate it into different languages,

I'd have no choice but to trust the translators to do a proper job. If

my prose is delicately nuanced, with many ambiguities, I'd have to

expect less than perfect results. It may be beyond ANY translation to

be perfect.

Your analogy is limited, because there is a huge range of paper/ink colors that _can_ be represented exactly in an RGB color space, and displayed exactly on a monitor. The art of translation applies only at the gamut limits, where the monitor and printer differ in their capabilities. Soft proofing effectively prevents the monitor from displaying colors that are out-of-gamut for the printer, and if the monitor image looks good to you (meaning that your image doesn't need those colors that are within-gamut for the printer but out-of-gamut for the monitor), then your prints should look like your monitor. That's assuming you have a good profile.

I don't like the idea of driver changing my files into what IT thinks

is the best result. I'm not talking about CMYK to CcMmYK translations,

I'm talking about rgb to CcMmYK translations or the like. If the

printer has to have CMYK anyway, why can't I have the controls?

Sounds like you need a RIP. But even then, I would think it preferable to put one's craftsmanship into building CMYK profiles that give you WYSIWYG results from RGB files viewed on an RGB monitor, rather than into tweaking the CMYK values for individual images.

Probably the feature that I'd miss the most if I were unable to work in

CMYK is hiking the contrast in the shadows. I just don't know how to do

this in rgb, and I need to use it most of the time.

It's not hard. You just use a curve, but increase the slope at the low end of the scale rather than the high end.

Ciao, Paul D. DeRocco

___________________________________________________________________________

Date: Wed, 21 Apr 2004 14:14:28 -0400

From: Ed Atkeson

Subject: Re: printing CMYK to an RGB device

Ed:

Thanks. I'll probably have to give it the old college try, but I just

want you to know that I've got other things to do. I really don't want

to learn a new colorspace, if I don't have to.

--------------------------------------------------------------

It's a good trick, helped me.

r = c,

g = m,

b = y.

Just like crayons in kindergarten.

best,

Ed A

___________________________________________________________________________

Date: Wed, 21 Apr 2004 09:22:10 -0600

From: Chris Murphy

Subject: Re: printing CMYK to an RGB device

On Apr 20, 2004, at 9:22 PM, Ron Kelly wrote:

You make it sound develishly difficult to know what makes a neutral in

CMYK. It's not that tough; just like the books says - cyan 5 to 10

points higher, magenta and yellow equal. The amount of black is

irrelevant.

The rule works on a press. It will not work with an inkjet. They have a decidedly green gray balance, and they have cross overs so the rule is not consistent. And the RIP being used will also make a difference. 36c, 44m, 39m is what I get for a midtone neutral that corresponds to L*=50 on an Epson 2200 using Velvet fine art paper. And this is one of the better behaved ones. Change papers and the rules change also.

That's not a particular concern to me. I want to be able to print to a

SPECIFIC device and control it precisely. I don't particularly care

what happens in a theoretically more neutral colorspace which could

apply in different situations. That's not my situation; I want to make

beautiful prints on MY printer.

A lot of people are making a lot of beautiful prints without having to learn CMYK to have explicit control over an inkjet printer. Even CMYK is a mask for direct control. You'd have to have a CcMmYKk (for Epson 2200, 7600, 9600, 4000) file and ability to edit in that to have the fine control you're talking about. Trust me, you don't want it and you don't really need it.

That's why I'm staying in my native tongue. The question is, if we're

finishing up in English and I'm sending English to the printer, why

does translation have to enter into it?

Because that's not how it works with photo inkjets. They speak Ugambani, and no one but programmers and engineers speak it. You don't want to learn it. You just need to get the best Ugambani translator you can find. Most of them prefer RGB data because it's easier for them to take RGB and convert to printer specific six or seven channel color instead of CMYK which requires them to recombine and recompute black generation anyway.

I don't like the idea of driver changing my files into what IT thinks

is the best result. I'm not talking about CMYK to CcMmYK translations,

I'm talking about rgb to CcMmYK translations or the like. If the

printer has to have CMYK anyway, why can't I have the controls?

In your view, why is there a difference between CMYK>CcMmYKk conversion and RGB>CcMmYKk conversion? Why do you somehow trust more of the former? That K is not being honored directly with photo inkjet printers. The entire behavior is being masked. If it weren't you'd rapidly realize how completely unlike a press an inkjet printer is.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Wed, 21 Apr 2004 10:32:37 -0400

From: Dolores Kaufman

Subject: Re: printing CMYK to an RGB device

Ron, if it makes you feel any better I've been doing all of my edits on my RGB files destined for my Epson 2200 printer by simply looking at the cmyk palette as I work (old habits die hard!). I hardly ever look at the RGB numbers. In Photoshop I have the cmyk color set to U.S. Sheetfed Coated v.2 so those are the numbers I am dealing with even though the file is in RGB and my working space in Adobe RGB. I also find that this helps keep the colors from going out of gamut by avoiding the !!! after the out-of-gamut colors, which you don't get if you only watch the RGB numbers. I do sometimes wonder if I am limiting my gamut by doing this and welcome Andy and Chris to chime in here if they feel this is so. I do find, however, that if I allow the colors to go out of the cmyk gamut I often get ugly results under incandescent lighting (would you believe TOO red?). By staying inside the cmyk gamut, however, I seem to get very pleasing results with little metamerism. You might want to try this method and see how it goes.

Dolores

___________________________________________________________________________

Date: Wed, 21 Apr 2004 09:25:11 -0600

From: Chris Murphy

Subject: Re: printing CMYK to an RGB device

PostScript understands both RGB and CMYK. The native language used by OS's don't. They simply weren't designed for it. Under OS X 10.3.x came along the only way for an application to communicate CMYK (or more channels) was using PostScript. The legacy is with us today as OS X has only been here for 6 months. Will there ever be drivers from manufacturers that support CMYK? I seriously doubt it because a.) they have way too much work to do cross-platform and b.) they gain nothing doing it, c.) there are 3rd parties to handle the market that wants CMYK control on a photo printer, which really doesn't make much sense anyway.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Wed, 21 Apr 2004 07:36:08 -0600

From:Andrew Rodney

Subject: Re: printing CMYK to an RGB device

on 4/20/04 9:22 PM, Ron Kelly wrote:

Yes, yes, we all know that. Sometimes neutrals ARE very important, no

doubt about that. But what about all the other colors? Skin tone? Wood

of various colors? I understand what ratios to look for in CMYK but

with RGB, the numbers all look like a foreign language.

You know the ratio based on what device, ink, paper? From experience to that one or two devices OR from the numbers in your info palette? If the info palette, you1re getting it from a device profile. That1s also true for RGB. I have no idea what a good skin tone value in RGB is for an Epson going to Matt paper verses a Canon going to glossy photo. But if I have a device profile, I can view the image correctly and begin to get an idea numerically what those values should be. Numbers do NOT tell us what a color looks like without having a description of the device it is going to. That's what a profile does.

Take your CMYK file with any set of numbers you like. Let's say it's for SWOP coated. Fine. You know from either years of experience or whatever that those numbers produce a known color appearance. Now Assign a different CMYK profile and watch the color appearance change. IF you send those numbers to this device you just used for assignment, that's the color appearance you'll get. Wrong numbers. Wrong for that device. RGB is no different.

RGB's BIG advantage is that in a well behaved editing space, neutrals are not even something to think about since they are always equal. RGB allows me to create any additional RGB or CMYK recipe for any device I want using a good device profile. CMYK twists this all around since as I said, it's totally a device dependent color space with all kinds of issues "locked" in like black generation and ink limits. Does this make RGB "better"? Well yes for flexibility it's clearly a better color space to archive and use for any subsequent output you might need. With a good choice of working space you have a vastly larger color gamut in a file that's smaller.

You make it sound develishly difficult to know what makes a neutral in

CMYK. It's not that tough; just like the books says - cyan 5 to 10

points higher, magenta and yellow equal. The amount of black is

irrelevant.

I never said it was devilishly difficult I said every CMYK device will require a different mix and every RGB working space that's well behaved is identical in this regard. I can find all kinds of CMYK devices where your rule above will fail and all over the tonal range. An ink jet which is a CMYK device is a prefect example! Are we talking CMYK to every device on this planet or CMYK ink on paper with a specific ink/paper you are familiar with? Big difference here.

That's not a particular concern to me. I want to be able to print to a

SPECIFIC device and control it precisely.

That's all any of us what to do! Now what if you happen to need to deal with a dozen different devices all using different media, inks/toner/sliver processes? Each device will require a different mix of numbers to produce the same (or similar) color appearance. And some will need RGB sent to the driver for this.

I have a paper I like, and I have some

inks I like. How do I define the gamut?

You build a device profile. Oh, those dreaded ICC profiles. That fingerprints your device/ink/paper and also allows you to map the gamut. It also allows other devices to mimic (cross render) to your device so you CAN make that $200 Epson ink jet produce a proof that matches your printer. Useful.

I should just define my

own custom CMYK conversion with a higher ink limit than the 340 I

typically use for off-set. Wouldn't this give me a larger gamut?

No, not really. Gamut is a function of the inks and to some degree paper in your case. Their purity/saturation. I can make a larger gamut device like my Epson 2200 match your process (with two profiles) because the Epson has a larger color gamut. I can't make your process match the Epson because your process has a smaller gamut than the Epson. So unlike Spinal Tap, there is no 11 to dial on your device. I can dial down the Epson to 9 to match your 10. I can't any of this without a device profile.

It seems to me that the printer has the gamut. My difficulty is not

that the printer's gamut is too small, but that the CMYK colorspace I'm

working in is too small. If I send some RGB files to the printer, the

blues are much richer, no doubt.

The CMYK for the printer is the CMYK you need and that gamut is fixed. There are thousands of different CMYK's out there with vastly different sized gamuts all based upon the device. You can't send RGB to your printer, it needs CMYK. So a conversion is necessary and during that conversion, the larger gamut has to be mapped well to the smaller gamut. That's why we have various rendering intents in device profiles. Gamut mapping is very complicated. When done poorly, you get color shifts. Remember years and years ago when everyone complained that Photoshop produced poor blues to CMYK. Part of it was we didn't have ICC profiles and part was just poor color settings. But you can get color shifts when gamut mapping is done poorly. That's not a big issue with good device profiles and people who understand how to setup soft proofs and view images with different intents to pick the best one for the image at hand. That's why humans need to look at images and make subjective judgments. ICC color management doesn't negate this (in fact it encourages people to look at images to make these judgments just like it encourages people to look at the numbers. The numbers however are empirical numbers).

If I were to write a book and translate it into different languages,

I'd have no choice but to trust the translators to do a proper job.

Bingo! That's what ICC profiles are, they are translators. Nothing more.

I don't like the idea of driver changing my files into what IT thinks

is the best result. I'm not talking about CMYK to CcMmYK translations,

I'm talking about rgb to CcMmYK translations or the like.

Then toss your ink jet or get a different driver that will accept CMYK. It's like me saying "I don't understand CMYK so why can't I send RGB to a printing press?" Can't do it.

And nearly every print on this planet is made in CMYK. That's just

physics.

Yes but that doesn't change the fact that we begin in RGB and many devices will only accept RGB. If you have a problem with that, stay away from those devices.

Andrew Rodney

http://www.digitaldog.net

___________________________________________________________________________

Date: Wed, 21 Apr 2004 13:39:49 +0100

From: Andrew Haley

Subject: RE: printing CMYK to an RGB device

Paul D. DeRocco writes:

I think inkjets that take RGB input are designed so that their

native RGB color space can push the printer pretty much to the

limit of the gamut possible with the ink and the paper.

As far as I can tell, that's right. Certainly the Epson 7600 will print yellows and cyans well outside Adobe RGB.

Andrew.

___________________________________________________________________________

Date: Wed, 21 Apr 2004 08:57:37 -0600

From: Ron Kelly

Subject: Re: printing CMYK to an RGB device

On 21-Apr-04, at 12:58 AM, Paul D. DeRocco wrote:

It's not hard. You just use a curve, but increase the slope at the low end

of the scale rather than the high end.

Well, it doesn't seem that easy to me. In cmyk I work with the K, if I'm talking shadow contrast in a rgb, now I have to adjust 3 curves, and every shadow move impacts what else may going on with color in those curves.

Ron Kelly

___________________________________________________________________________

Date: Wed, 21 Apr 2004 07:36:32 -0600

From:Andrew Rodney

Subject: Re: Re: printing CMYK to an RGB device

on 4/21/04 6:13 AM, Stephen Marsh wrote:

The CCW (current conventional wisdom) for RGB inkjets is to work in a

safe neutral RGB and editing space slightly larger than the gamut of

the output and to convert on the fly during printing to the profiled

RGB output of said device...and the ICC gods will perfectly transform

the working image into the output.

True for CMYK too...

And no - getting neturals from a device space (either CMYK or RGB) is not

rocket science, as some make out. Sure the ratio of inbalance

(or balance?) is not linear from highlights to shadows...but with a valid

profile to assign and LAB readings it is easy to establish PERFECT values

which equate to a true neutral of 0A 0B in LAB.

With a profile. LAB values only tell us the equivalent RGB or CMYK values based on the profile of the device. So yes, IF you have a good device profile, be it RGB or CMYK, you can get neutrals from that specific recipe based upon the profile. That part isn't rocket science. Getting a good profile and by god, getting some shop or printer to supply you with one is worse than rocket science. The "magic" numbers are all in the profile.

Andrew Rodney

http://www.digitaldog.net

___________________________________________________________________________

Date: Wed, 21 Apr 2004 16:07:14 -0600

From:Andrew Rodney

Subject: Re: printing CMYK to an RGB device

on 4/21/04 8:32 AM, Dolores Kaufman wrote:

In Photoshop I have the cmyk color set to U.S. Sheetfed Coated v.2

so those are the numbers I am dealing with even though the file is in RGB

and my working space in Adobe RGB.

If that makes you feel better <g>. But since the CMYK process that goes on inside the black box to a 7 color printer like your Epson has absolutely no relationship to a Sheetfed coated press process, what1s the point? You might as well pick SWOP, Eurocoated or any other CMYK profile which equally has no relationship to this printer.

IF you are printing to a device that behaves like your CMYK color settings, I can see how the numbers could be useful.

out-of-gamut

colors, which you don't get if you only watch the RGB numbers. I do

sometimes wonder if I am limiting my gamut by doing this and welcome Andy

and Chris to chime in here if they feel this is so.

Yes, you're limiting this big time! Better would be to load an ICC profile for the Epson and paper in your soft proof. You'll visually SEE the colors that are not printable AND you'll get the correct output numbers (in RGB) for this printer when you set the info palette to Proof Colors.

By staying inside the cmyk gamut, however, I seem to get very pleasing results

with little metamerism.

I don't see how. Metamerism in this case is caused by the yellow ink and how it reacts to light. Working in a smaller gamut really doesn't make this issue go away. You might notice less with desaturated colors but I'm not sure a print that doesn't take full advantage of a devices gamut is any upside.

Let's get to the REAL color theory here. You're working with a device that demands you feed it RGB. If you want to feed it CMYK, you need to drive it with a RIP. So even if you did this, the CMYK numbers would be TOTALLY different than the CMYK numbers to a sheet fed press. We're talking radically different inks! Totally different color gamuts.

Please allow me to provide REAL numbers to illustrate. I do have a CMYK profile for an Epson 2200 for Premium Glossy Paper for a RIP to that device.

I place the eyedropper over a nice skin tone and I get:

C19%/M61%/Y48%/K13%

Now I use the Sheetfed profile and on the same sample I get:

C19%/M42%/Y43%/K1%

Close enough? I don't know. But I know they are not the same. Change just the paper and the values go even farther.

Andrew Rodney

http://www.digitaldog.net

___________________________________________________________________________

Date: Wed, 21 Apr 2004 15:26:23 -0600

From: Chris Murphy

Subject: Re: printing CMYK to an RGB device

On Apr 21, 2004, at 8:57 AM, Ron Kelly wrote:

Well, it doesn't seem that easy to me. In cmyk I work with the K, if

I'm talking shadow contrast in a rgb, now I have to adjust 3 curves,

and every shadow move impacts what else may going on with color in

those curves.

If you have an adjustment that calls for manipulating shadow contrast using K only, then why not do the same adjustment on the RGB master channel? It's more gray balanced than K is (K is often assumed to be neutral but really isn't exactly neutral).

And in actuality, I would propose if you have Photoshop CS to use the new Shadow/Highlight tool instead of using curves to make these kinds of adjustments. And currently it only works in RGB (at least directly).

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Wed, 21 Apr 2004 17:50:49 -0400

From: Ed Atkeson

Subject: Re: printing CMYK to an RGB device

Convert to LAB to work with shadow contrast.

Ed A

------------------------------

From: Ron Kelly

Well, it doesn't seem that easy to me. In cmyk I work with the K, if

I'm talking shadow contrast in a rgb, now I have to adjust 3 curves,

and every shadow move impacts what else may going on with color in

those curves.

___________________________________________________________________________

Date: Wed, 21 Apr 2004 19:25:28 -0400

From: Dolores Kaufman

Subject: Re: printing CMYK to an RGB device

on 4/21/04 6:07 PM, Andrew Rodney wrote:

Yes, you're limiting this big time! Better would be to load an ICC profile

for the Epson and paper in your soft proof. You'll visually SEE the colors

that are not printable AND you'll get the correct output numbers (in RGB)

for this printer when you set the info palette to Proof Colors.

Well, I'll be darned. I DO visually softproof the printer/paper profile but didn't notice (knock on head) that I could preview those numbers in the info palette! Lovely. When did they sneak that one in <gr>.

I don't see how. Metamerism in this case is caused by the yellow ink and how

it reacts to light.

Yes, I have only noticed this "screaming red" effect under incandescent light, and I do find that I end up removing a lot of yellow from the reds to satisfy my taste (I'm not talking skin tones here!)

Please allow me to provide REAL numbers to illustrate. I do have a CMYK

profile for an Epson 2200 for Premium Glossy Paper for a RIP to that device.

I suppose this profile is only available with the RIP? Might be worth the expense. Although I don't share Ron's aversion to working in RGB I do find the numbers difficult to interpret in any meaningful way after so many years of preparing files in cmyk. Thanks for your reply, Andrew. This has been an informative thread.

Dolores

___________________________________________________________________________

Date: Wed, 21 Apr 2004 17:36:36 -0600

From:Andrew Rodney

Subject: Re: printing CMYK to an RGB device

on 4/21/04 5:25 PM, Dolores Kaufman wrote:

I suppose this profile is only available with the RIP?

Yes but then it would be useless without the RIP. Or for that matter any profile you get that doesn't also reflect how you print the image with regard to the driver. IOW, a profile only fingerprints how a device produces color. If you had RIP A but a CMYK profile for RIP B, you'd be no better off. Since we've said you need a RIP to send CMYK to the Epson, any CMYK profile you use OTHER than that profile made for the RIP would be no more benefit that the profile you are currently using (which equally has no bearing on how your Epson is behaving.

The same is true for RGB. I have an RGB Rip I use for my Epson (ImagePrint). It comes with good profiles. I can't use those profiles with the Epson driver any more than I can use the profiles I build for my Epson driver within ImagePrint.

Andrew Rodney

http://www.digitaldog.net

___________________________________________________________________________

Date: Thu, 22 Apr 2004 09:07:28 -0000

From: Stephen Marsh

Subject: Re: printing CMYK to an RGB device

--- Andrew Rodney wrote:

on 4/21/04 6:13 AM, Stephen Marsh wrote:

The CCW (current conventional wisdom) for RGB inkjets is to work in a

safe neutral RGB and editing space slightly larger than the gamut of

the output and to convert on the fly during printing to the profiled

RGB output of said device...and the ICC gods will perfectly transform

the working image into the output.

True for CMYK too...

Although some may be pushing for placing RGB in layouts, or even making device independent layouts/illus files and letting colour management handle all the rest - that is not for me or the majority of the general prepress/print market that I have experienced.

I will make an active use of ICC CM in Photoshop, but not in layout or illustration software.

So a blind conversion at the RIP or layout print stream is not for me. I will convert in Photoshop and place/output unaltered CMYK values, yes device dependent values...and the illus and layout elements will use a build that is device dependent too.

So yes, IF you have a good device

profile, be it RGB or CMYK, you can get neutrals from that specific recipe

based upon the profile. That part isn't rocket science.

Sending of value of say 15c 10m 10y to a SWOP type device is fairly neutral, but this is an idealised number which is good for humans...if using a referenced device profile then the mix may instead be 15c 11m 12y. On press, they are both probably going to appear netural - but if one evaluates via a profile instead of using pleasing idealised rounded aimpoints then things will not be 0A 0B. So to me, it all depends on if you are just sending to this output device, or if you need to convert to RGB or LAB and still retain a true neutral.

Getting a good

profile and by god, getting some shop or printer to supply you with one is

worse than rocket science. The "magic" numbers are all in the profile.

Off the general point from the current thread with this quote/reply but...I have had to resort to writing down neutral CMY values in say 10% increments and using these aimpoints to edit to, when dealing with non ICC savvy devices. These numbers were not established with a profile, but they did work with the drum scanner and the proofing system in use at the time. Of course, this process can be ICC profiled (and should be, but that is not to say it is the only way that works).

Stephen Marsh.

___________________________________________________________________________

From: Stephen Marsh

Subject: Re: printing CMYK to an RGB device

---Andrew Rodney wrote:

IF you are printing to a device that behaves like your CMYK color settings,

I can see how the numbers could be useful.

Andrew, I find this approach useful for example when dealing with critical skintones (for me it is often SWOP and CMRGB). Endpoints

and neutrals are easy in RGB...but memory colours are not.

There was a recent post to the list in which a member stated that many supplied images had almost no cyan values when converted to CMYK. I took a guess that this sounded like A98 and perhaps edits done only visually on a monitor, which was probably not set-up to display an accurate image...and even if it was the INFO palette should still be referenced for critical tonal areas in both RGB and in CMYK.

Knowing what makes a good ratio/balance in CMYK seems to be a lot more intuitive and efficient than trying to look at the values as RGB ratio/balance, although the basic RGB 'ratio' is similar to SWOP type CMYK ratio/balance (but this depends on your RGB edit space) - the RGB values seem less intuitive and harder to finesse than the smaller % values (the ratio of 100 possible levels vs. 256 can be daunting).

Given time, one can learn - just as they did with CMYK. I have not needed to get to know RGB that well, for me I still use SWOP CMYK as a crutch for memory colours.

Although using this technique on a RGB file may not guarantee the visual result that you are seeing in the CMYK value preview in the info palette - it will guarantee that the skintone will be pleasing on any device if the RGB is handled correctly for that device.

The SWOP type CMYK gamut should not have gamut concerns for natural skintone, the skintone should not be out of gamut. With masks in Photoshop, one can 'spot' merge CMYK edits back into the RGB file, preserving the RGB gamut in most areas (one does not need the entire RGB file in CMYK if one really must edit in CMYK but still wish to retain the benefit of the larger RGB gamut). Just becuase CMYK is smaller in most colours, it does not mean that the colours you are dealing with are out of CMYK gamut, so apart from mode conversions, rounding errors, unique levels losses, dither etc...there may be no real 'visual' loss. This may not be ideal or the chosen way to work for myself or most users, but it is an option.

The info palette and its use is a very critical aspect of image editing, more threads should be devoted to it. <g>

Stephen Marsh.

___________________________________________________________________________

Date: Thu, 22 Apr 2004 06:15:16 -0400

From: todie

Subject: Re: Re: printing CMYK to an RGB device

Good morning!

My name is Laurentiu Todie and I am <s>an alcoholic</s> insane.

I edit color in AdobeRGB but my monitor cannot display all of that space.

I am aware of some compromises between my monitor's RGB and CMYK, but have no clue about where the missing colors are and how they affect my images.

Laurentiu Todie

___________________________________________________________________________

Date: Thu, 22 Apr 2004 11:12:32 -0400

From: Lee Clawson

Subject: Re: printing CMYK to an RGB device

on 4/20/04 11:22 PM, Ron Kelly wrote:

Yes, yes, we all know that. Sometimes neutrals ARE very important, no

doubt about that. But what about all the other colors? Skin tone? Wood

of various colors? I understand what ratios to look for in CMYK but

with RGB, the numbers all look like a foreign language.

Ron,

May help to display a color target. You can use it as an aid to get color mixes and/or ratios in RGB. I've used a "traditional" scanner target that we always named "The 3 Musicians" (don't know mfg; it has 3 women dressed in ethic clothing with instruments). It showed a variety of skin colors and tones along with a wide assortment of colors.

Lee

___________________________________________________________________________

Date: Thu, 22 Apr 2004 09:03:52 -0600

From: Ron Kelly

Subject: Re: printing CMYK to an RGB device

On 21-Apr-04, at 9:22 AM, Chris Murphy wrote:

A lot of people are making a lot of beautiful prints without having to

learn CMYK to have explicit control over an inkjet printer.

Yes, I'm sure there are. The question is, could they be better still? Mine could, if I could get the control I want in the colorspace I know, which happens to be the same, or substantially the same colorspace that the printer is using anyway.

Even CMYK

is a mask for direct control. You'd have to have a CcMmYKk (for Epson

2200, 7600, 9600, 4000) file and ability to edit in that to have the

fine control you're talking about. Trust me, you don't want it and you

don't really need it.

Don't really want it? Perhaps not; don't really need it? Probably not. My experience is that RIPs which translate one style of CMYK to another (with more # of inks) is not a problem.

It seems to me that you are equating an rgb to CMYK (or CcMmYKk) conversion to be equivalent to a CMYK to CcMmYKk conversion. I don't think it is, not by a longshot.

Translation between languages is analagous. English to French is one thing; English to Chinese is quite another.

That's why I'm staying in my native tongue. The question is, if we're

finishing up in English and I'm sending English to the printer, why

does translation have to enter into it?

Because that's not how it works with photo inkjets. They speak

Ugambani, and no one but programmers and engineers speak it.

Now I need a translator. Is this a euphimism, or is there such a thing as "Ugambani" which actually refers to code for printers? Perhaps we should be having this discussion in Esperanto.

You don't

want to learn it. You just need to get the best Ugambani translator you

can find.

This sounds like: "Leave it up to the experts; the software engineers, the people with initials after their name, the people who wear lab coats, especially in advertisements. They know best, because they're the experts! If they've figured it out, it must be the best possible solution for everyone, including you."

You also suggested using the new Photoshop highlight/shadow command as a means of controlling shadow contrast. While it seems to be an excellent tool, it doesn't really accomplish everything you can do by manipulating the black plate. I typically want to increase contrast in the shadows, and this isn't exactly what the shadow/highlight command does.

Adobe would make this tool even better if they put it on an adjustment layer. As it stands, you make a correction based on the visual appearance. If you went too far, or not far enough, how do you evaluate it? I would make a print. When it's not right, go back to the original and start over - a tedious method.

Ron Kelly

___________________________________________________________________________

Date: Thu, 22 Apr 2004 06:44:43 -0600

From:Andrew Rodney

Subject: Re: Re: printing CMYK to an RGB device

on 4/22/04 3:07 AM, Stephen Marsh wrote:

So a blind conversion at the RIP or layout print stream is not for

me.

Me either. It1s a big leap of faith. But for some workflows (500 images of wigets on a white bkgnd for some parts catalog), it can work fine.

Andrew Rodney

http://www.digitaldog.net

___________________________________________________________________________

Date: Thu, 22 Apr 2004 10:35:41 -0600

From: Chris Murphy

Subject: Re: printing CMYK to an RGB device

On Apr 21, 2004, at 5:36 PM, Andrew Rodney wrote:

The same is true for RGB. I have an RGB Rip I use for my Epson (ImagePrint).

It comes with good profiles. I can't use those profiles with the Epson

driver any more than I can use the profiles I build for my Epson driver

within ImagePrint.

Just to clarify for some people out there, that the profiles themselves are interchangeable on a technical level. The problem is that Epson's driver, and Imageprint (and each RIP on the market) causes very different color behavior for the printer they drive.

As I keep saying, inkjets have fairly psychotic behavior on their own. If you were to have direct control over cyan (example) on a 7600 and asked for 100% cyan, implying the maximum amount of cyan, you'd have cyan ink pouring off the page. Literally. So each of these products that drive inkjets has their own idea of how to mask the native behavior of the printer, and get something optimal for their target end user.

Thus, since the drivers/RIPs all cause different output behavior, a profile is not merely for the printer, but for the printer, paper and driver/RIP combination.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: 22 Apr 2004 20:26 +0200

From: Jeff Suckow

Subject: Re: printing CMYK to an RGB device

Ron,

The best place to understand the inter-relation between all the existing color spaces is Dan's book.

Professional Photoshop

by Dan Margulis.

I often edit my images in multilple color spaces (RGB, CMYK & LAB) and then and mixe them in various way (layer with luminosity, overlay, etc...).

As Dan says: "Every file has ten channels"

Regards,

Jeff Suckow

___________________________________________________________________________

Date: Thu, 22 Apr 2004 23:07:45 -0600

From: Ron Kelly

Subject: Re: printing CMYK to an RGB device

On 22-Apr-04, at 12:26 PM, Jeff Suckow wrote:

The best place to understand the inter-relation between all the existing

color spaces is Dan's book.

Yes, I think so too. I've read them all, and I re-read them from time to time.

However, I have my own thoughts. No doubt, my incomplete understanding is on full display. I still feel that the best course is to ask questions at the risk of looking ignorant.

Even though I don't always agree with everyone on the list, I enjoy the discussion. It's often informative, and always entertaining.

Thanks to all who contributed to this thread.

Ron Kelly

___________________________________________________________________________

Date: Fri, 23 Apr 2004 10:14:39 -0500

From: Lori Sabo

Subject: Re: printing CMYK to an RGB device

Hmm, . . . the black channel is really good for some things . . . what if Photoshop had a feature that would create a black channel (where you could choose heavy/light/equivalents of UCR/GCR/whatever in creating it) for editing in an rgb file. Either it could be combined back into the rgb when done with the edit, or PS could assign a new profile (based on the rgb profile) of RGBK type that would allow the file to be translated back to rgb. Shouldn't be a big deal, really rgb=cmy after all. And it is nice to work in a color space where equal values in all three channels ensures a neutral, especially if you are going to rgb output device anyway.

___________________________________________________________________________

Date: Fri, 23 Apr 2004 18:13:59 -0600

From: Ron Kelly

Subject: Re: Re: printing CMYK to an RGB device

On 23-Apr-04, at 9:14 AM, sabo wrote:

Hmm, . . . the black channel is really good for some things . . . what

if Photoshop had a feature that would create a black channel (where you

could choose heavy/light/equivalents of UCR/GCR/whatever in creating it)

for editing in an rgb file. Either it could be combined back into the

rgb when done with the edit, or PS could assign a new profile (based on

the rgb profile) of RGBK type that would allow the file to be

translated back to rgb. Shouldn't be a big deal, really rgb=cmy after

all.

IF it really wasn't such a big deal this might be a great idea.

I'm not quite sure if this would work, however. Black is from a subtractive color model, and rgb is additive.

Having said that, some imaginitive programmer SHOULD be able to do it, whatever color model it would live in.

You'd still have the concerns of going from a 3 part colorspace to a 4 part one, and then back again, but that's no different than making your choices as we do already. In principle it's a very interesting idea.

Maybe you should patent it, before Microsoft does.

Ron Kelly

___________________________________________________________________________

Date: Sat, 24 Apr 2004 12:04:19 -0000

From: Stephen Marsh

Subject: Re: printing CMYK to an RGB device

Ron Kelly wrote:

I'm not quite sure if this would work, however. Black is from a

subtractive color model, and rgb is additive.

List member Mike Russell has all this and more on offer for PC users:

http://www.curvemeister.com

Regards,

Stephen Marsh.

___________________________________________________________________________

Date: Sat, 24 Apr 2004 10:14:17 -0700

From: Lee Varis

Subject: Re: Re: printing CMYK to an RGB device

On Apr 23, 2004, at 5:13 PM, Ron Kelly wrote:

I'm not quite sure if this would work, however. Black is from a

subtractive color model, and rgb is additive...

I think you're making this harder than it needs to be. If all you're concerned about is using black plate editing to get better shadow detail/contrast and you're not trying to preserve that black plate for a specific output (how could you if you end up in RGB) then all you need to do is:

1. Duplicate your RGB file

2. Convert the duplicate to the CMYK of your choice (heavy/light - GCR/UCR)

3. Edit the black channel

4. Shift-drag this version back onto the original RGB file the CMYK will be converted to RGB on-the-fly where it will end up as a registered "layer" on top of the original

5. Change the layer apply mode to "Luminosity" !!!

You now get the benefit of the new shadow detail/contrast with the color gamut of the original RGB. You don't need any special software or plug-ins and you can use the CMYK editing skills you already have to do this.

regards,

Lee Varis

http://www.varis.com

888-964-0024

___________________________________________________________________________

Date: Sat, 24 Apr 2004 18:45:05 -0400

From: todie

Subject: Re: Re: printing CMYK to an RGB device

If you convert to CMYK (temporarily), copy the Black channel (go back to RGB in history), paste in QuickMask mode (exit QuckMask) and make a curve adjustment layer, you can (with some skill and imagination :) simulate any style (GCR, UCR, long, short...) Black channel in RGB.

Laurentiu Todie

___________________________________________________________________________

Date: Sun, 25 Apr 2004 02:08:02 -0000

From: Stephen Marsh

Subject: Re: printing CMYK to an RGB device

---Andrew Rodney wrote:

on 4/22/04 3:07 AM, Stephen Marsh wrote:

So a blind conversion at the RIP or layout print stream is not for

me.

Me either. It1s a big leap of faith.

Indeed, when I wrote this I was thinking of the concept of the entire page layout file and linked images (raster/vector) being totally device independent and simply hoping for the 'best' at output.

Even if the CM is handled correctly, the builds for a colour that a profile chooses may not be what a human would use. Colour management of contone images is one thing, illustration and page layout files are often handled very differently to raster files.

But for some workflows (500 images of

wigets on a white bkgnd for some parts catalog), it can work fine.

Yes, I imagine so. There are many production benefits to this and if it is known that the elements are not too demanding for a one size fits all conversion then I can see where this would be attractive - final image quality is not always the primary factor in a job brief, budgets have a nasty habit of getting in way.

The gamut trade off between RGB>CMYK (CcMmYK etc) between a inkjet and press often means that the decisions one makes for the inkjet are a lot

simpler and one can get by with the profile doing the work, where as with

CMYK press work - a RGB>CMYK is often not as good as a the same file with just a little massage work done to the K plate (presuming an in-gamut

file that does not suffer from the trip to CMYK).

Stephen Marsh.

___________________________________________________________________________

Date: Sun, 25 Apr 2004 15:09:56 -0600

From: Ron Kelly

Subject: Re: Re: printing CMYK to an RGB device

On 24-Apr-04, at 11:14 AM, Lee Varis wrote:

I think you're making this harder than it needs to be. If all you're

concerned about is using black plate editing to get better shadow

detail/contrast and you're not trying to preserve that black plate for

a specific output (how could you if you end up in RGB) then all you

need to do is:

This is very interesting indeed. I shall give it a go and see what happens. Thanks,

Ron Kelly

___________________________________________________________________________

Date: Tue, 27 Apr 2004 11:58:22 -0400

From: Alex Lippisch \

Subject: Re: printing CMYK to an RGB device

I have printed RGB images many times to Epson inkjets with great results.

However, when I print RGB to a color laser machine like a Xerox Phaser 7700 or Docucolor, the results are poor. These machines seem to like CMYK images, and I do get better results sending them CMYK. As several of you have pointed out, the inkjets are designed to prefer RGB. I'm curious as to why the laser printers prefer CMYK? I imagine it all boils down to how the RIP is designed.

Does anyone use a printer like the Xerox Phaser 7700 to proof their CMYK? If so, can you offer any tips for getting the best results. Longtime readers might remember my past color struggles with sending Quark EPS files to this machine. I have bought and read "Real World Color Management" (great book Chris!) and know that there are suggestions for building CMYK just for these printers, but I would like to use it to create a reasonable pre-press proof. Even though I'm sure some of you would cringe at the thought.

I am a photographer, so please excuse the fact that I don't completely know what I'm doing in CMYK - but I'm trying to get there!

Thanks,

Alex Lippisch

___________________________________________________________________________

Date: Tue, 27 Apr 2004 12:37:01 -0400

From: Jim Rich

Subject: Re: Re: printing CMYK to an RGB device

Alex,

I think it has to do with the fact that laser printers come with a PostScript rip. And 99.99% of all PostScript rips that drive laser printers pass through the CMYK file.

I have a publisher client who uses the 7700 and they use ICC profiles for some level of color proofing.

In this case they have the GretagMacbeth IQ in front of the 7700 that way they can send most any type of file and have a chance at influencing the color prints with profiles. Using profiles with the laser printer is not perfect but they help.

Jim Rich

___________________________________________________________________________

Date: Tue, 27 Apr 2004 10:33:52 -0700

From: "Kyle L. Hildebrant"

Subject: RE: printing CMYK to an RGB device

Hello, new to the list.

Question: I'm a little confused, or maybe disheartened is more appropriate.

Dealing with PMS to RGB conversions. Im at the point where I don't know what to believe.

I don't do a whole lot of work in RGB, mostly CMYK and SOLID colors. Where I use RGB most is trying to match

Say, website colors, to an identity system I have developed. I can input the PMS color in Photoshop and get a RGB Equivalent, I can input the PMS color in Illustrator and get a different number, then there are numerous "PMS to RGB"

Resources I have seen that even detail (most likely less accurate) other numbers. Do I just need to purchase the SOLID to RGB Pantone Guide? If so then what about CMYK numbers?

Cheers!

Kyle L. Hildebrant

Art Director

SYNERGY PRODUCTIONS

14362 N. Frank Lloyd Wright Blvd.

Suite 1340

Scottsdale, AZ 85260

___________________________________________________________________________

Date: Thu, 29 Apr 2004 09:10:29 -0400

From: Lee Clawson

Subject: Re: printing CMYK to an RGB device

Kyle,

From Pantone I received a chart (pdf file) that specs Solid to RGB. It converts to "coated", uncoated" and "matte". I want the conversion for sRGB. so it goes unused.

Lee

___________________________________________________________________________

Date: Thu, 29 Apr 2004 11:52:23 -0400

From: Lee Clawson

Subject: Re: Re: printing CMYK to an RGB device

John,

We've had good experiences with the Xerox Phaser, good color, ability to take heavy stock and printing on both sides and works well in multi-platform environment. Cost of color cartridges is high. Contact me off list for more details.

Lee

___________________________________________________________________________

Date: Thu, 29 Apr 2004 17:55:30 -0600

From: Chris Murphy

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

On Apr 28, 2004, at 4:10 PM, Kyle L. Hildebrant wrote:

Do you mean "visually represents", as far as the "spot color preview" is

displayed on screen?

When selecting a Pantone solid color in Illustrator or InDesign, the display is predicated on CMYK equivalents, not LAB. Neither Pantone nor InDesign differentiate between solid swatch libraries and solid to process swatch libraries like Photoshop does. A solid swatch library in Photoshop is defined in LAB as it should be. A solid to process swatch library is defined in CMYK, also like in Photoshop.

One day Illustrator and InDesign will get it together and stop defining solid colors using CMYK.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Fri, 30 Apr 2004 13:41:48 -0700

From: "Kyle L. Hildebrant"

Subject: RE: printing CMYK to an RGB device

From Pantone I received a chart (pdf file) that specs Solid to RGB. It

Where can I get this?

___________________________________________________________________________

Date: Fri, 30 Apr 2004 22:15:10 -0400

From: John Castronovo

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

From: "Chris Murphy"

One day Illustrator and InDesign will get it together and stop defining

solid colors using CMYK.

Obviously, Adobe knows what the LAB values are. My guess is that it has to do with the licensing fees that they negotiated with Pantone.

john c.

___________________________________________________________________________

Date: Fri, 30 Apr 2004 23:29:03 -0600

From: Chris Murphy

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

On Apr 30, 2004, at 8:15 PM, jc castronovo wrote:

Obviously, Adobe knows what the LAB values are. My guess is that it has to

do with the licensing fees that they negotiated with Pantone.

No actually it has to do with a circular problem where a.) Adobe has persisted in fibbing to designers about the nature of Pantone colors being definable with CMYK; b.) Designers and a few pre-press people would have a cow if suddenly they started getting LAB values when previously they got CMYK values when selecting Pantone solids, so Adobe just leaves well enough alone to keep from getting a thousand tech support phone calls from people freaking out.

Of course, in this case, I say, "No pain, no gain." We just need to get over this idea that CMYK equates to a specific color, especially when defining solids that aren't in the CMYK gamut by design.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Sat, 01 May 2004 09:39:19 -0000

From: Stephen Marsh

Subject: Re: PMS to RGB (was: printing CMYK to an RGB device)

Chris Murphy wrote:

No actually it has to do with a circular problem where a.) Adobe has

persisted in fibbing to designers about the nature of Pantone colors

being definable with CMYK;

Sitting on the sidelines, I find it 'amusing' that AID has not attempted to beat QXP in this area, where in many other areas it attempts to do so...Spot solid [Pantone] coated colours in Xpress are LAB based (CIE LAB not ICC LAB as in Adobe).

b.) Designers and a few pre-press people

would have a cow if suddenly they started getting LAB values when

previously they got CMYK values when selecting Pantone solids, so Adobe

just leaves well enough alone to keep from getting a thousand tech

support phone calls from people freaking out.

As you say, this sounds like good economic sense for a SW vendor, but perhaps not the best for industry education or for colour matching.

Of course, in this case, I say, "No pain, no gain." We just need to get

over this idea that CMYK equates to a specific color, especially when

defining solids that aren't in the CMYK gamut by design.

CMYK does equate to a specific colour if you are only concerned with one CMYK target - this is what the whole CMYK PostScript workflow is about, the same source value between different apps should all equate to the same colour...raster or vector source should not matter...but

I understand your main point here Chris. What is it, 20% or so of

the 'average' PMS solid coated colours are in gamut for average

SWOP type CMYK?

Folk who have a solid to process swatch book from Pantone know how poor CMYK can be at reproducing many spot inks, but when entering colour values in software this may not be as obvious to the same user.

People also know that going from RGB to CMYK can be a problem for out

of gamut hues, but they may forget this when defining spot colours or

using a default library build which is limited to CMYK.

Agreed Chris - this becomes very obvious when dealing with default library build named spot colours in QXP (LAB based) and with composite colour output of spot colours in other software, things

do not always match.

Stephen Marsh.

___________________________________________________________________________

Date: Sat, 1 May 2004 09:49:45 -0400

From: John Castronovo

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

From: "Stephen Marsh"

Sitting on the sidelines, I find it 'amusing' that AID has not

attempted to beat QXP in this area, where in many other areas it

attempts to do so...Spot solid [Pantone] coated colours in Xpress are

LAB based (CIE LAB not ICC LAB as in Adobe).

Has this been consistent across Quark versions 4, 5, and 6? When one converts from spot to process in Quark, what are the process assumptions? How about PhotoShop?

john c.

___________________________________________________________________________

Date: Sat, 01 May 2004 10:12:42 -0400

From: Lee Clawson

Subject: Re: printing CMYK to an RGB device

From Pantone I received a chart (pdf file) that specs Solid to RGB. It

Where can I get this?

Kyle,

From Pantone (Pantone.com)...updates, the traditional color guides and other software. 2 relevant items are: PANTONER ColorWeb Pro (web color guide, a system "extension" color picker) Pantone Colors-RGB Values.pdf (the chart I spoke about)

If you need more info write off-line

Lee

___________________________________________________________________________

Date: Sat, 01 May 2004 14:39:17 -0000

From: Stephen Marsh

Subject: Re: PMS to RGB (was: printing CMYK to an RGB device)

Has this been consistent across Quark versions 4, 5, and 6?

I can only comment up to v4.

I would not expect things to be consistent between pre/post 2000 Pantone formula changes.

When one

converts from spot to process in Quark, what are the process assumptions?

Not sure about CM, I don't use it in QXP. The CMYK values given are the default from Pantone, which should match other software from the same or other vendors (except for pre/post 2000 formula issues).

I could also ask those more knowledgeable on the list - what are the assumptions about colour in Adobe software such as AI9 or higher...if colour management is off and emulating v6 behaviour...as one can no longer have a mixed mode file with both RGB and CMYK elements...so you are forced to convert the entire file to one mode or the other...so there is an assumption made somewhere in this blind conversion which we are now forced into.

But that would be heading off this current topic.

How about PhotoShop?

John, this is where the fun starts...

Point of interest...Before v7 the named colour systems were hard wired, v7 introduced them as files which could be enabled/disabled like other components.

The default values for the spot colours going to CMYK were the same between say Quark 4, FreeHand 7 and Photoshop 6 (pre 2000 formula). A PMS 072 would be 100c 79m in all these different apps if going by CMYK values (but what condition to use to describe or 'tag' to these numbers, which mean nothing by themself?).

As Chris has mentioned, the CMYK gamut is not ideal for describing the composite colour appearance of most spot colours.

There was a trick which I learnt from Dan, where the colour picker was changed from custom so that the ICC LAB values for the PMS colour were presented...then one could enter the LAB value box's and retype the same values over themself...which would then force Photoshop to re-caluculate the CMYK values for this colour, based on the working CMYK (render intent will affect things) rather than the undocumented colour that Pantone supplied as the 'magic numbers' which many treat as law. These values are often poor for the intended target condition and one can use a profile or trial and error to make a better recipe for the CMYK simulation than is supplied by default.

So one should be able to compare the ICC LAB values from Photoshop for a spot colour against Quark 4 or higher CIE LAB for the same colour and as long as they are both using the same formula (either pre or post 2000)...apart from rounding differences between the different LAB systems AB components...I would not expect major variation, but I have not tested this!

By default the LAB values were hidden, and CMYK values were presented in the old Pantone Solid library system (as opposed to Pantone Solid Coated).

In v7, as well as colour book files being added instead of being hard wired - the build of some of the library files was changed to present LAB values up front, and to then calculate the RGB/CMYK values on the fly to the workspace in use...rather than having to do the trick mentioned above manually retyping the LAB values back in.

The Pantone Coated library became Pantone _SOLID_ Coated...if one wants the old hard wired CMYK values presented up frot to seamlessly sync with illustration and layout software, then the Pantone Solid to Process library...or let Photoshop calculate the colour based on the expected output condition and make the other software match that custom value rather than using the default build supplied by Pantone.

Stephen Marsh.

___________________________________________________________________________

Date: Sat, 1 May 2004 12:40:09 -0400

From: John Castronovo

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

Yup, but even better fun starts when designers begin specifying tints of Pantone colors in Quark.

Thanks for the information. I intend to rub a few noses in it if you don't mind.

john c.

___________________________________________________________________________

Date: Sat, 1 May 2004 12:44:32 -0600

From: Chris Murphy

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

On May 1, 2004, at 3:39 AM, Stephen Marsh wrote:

Sitting on the sidelines, I find it 'amusing' that AID has not

attempted to beat QXP in this area, where in many other areas it

attempts to do so...Spot solid [Pantone] coated colours in Xpress are

LAB based (CIE LAB not ICC LAB as in Adobe).

Are you sure? While the on-screen preview of solids may be LAB based, those values are not used at output time. Whether I print specifying a laser printer or various printing presses I get the solid to process values. Also, in this context I'm not sure what you mean by CIE LAB vs. ICC LAB.

As you say, this sounds like good economic sense for a SW vendor, but

perhaps not the best for industry education or for colour matching.

Right.

CMYK does equate to a specific colour if you are only concerned with

one CMYK target - this is what the whole CMYK PostScript workflow is

about, the same source value between different apps should all equate

to the same colour...raster or vector source should not matter...but

I understand your main point here Chris.

CMYK + a specific output condition = color

We have CMYK values for Pantone solid to process, but a specific output condition is not available in the form of an output profile. So Pantone's numbers are ambiguous unless you can replicate their non-standard print behavior (i.e. it's not SWOP, GRACoL, or ISO 12647 based.)

What is it, 20% or so of

the 'average' PMS solid coated colours are in gamut for average

SWOP type CMYK?

It depends on what your tolerance is. But it might be as high as 50%. It's kindof subjective.

Folk who have a solid to process swatch book from Pantone know how

poor CMYK can be at reproducing many spot inks, but when entering

colour values in software this may not be as obvious to the same user.

People also know that going from RGB to CMYK can be a problem for out

of gamut hues, but they may forget this when defining spot colours or

using a default library build which is limited to CMYK.

It's worse than this. They think that if they use the CMYK values they will get the process version in the solid to process guide on *any* device they print it to. Really. They don't get that these colors can be out of gamut for the press condition or output device they are using, let alone that the numeric values will work in a completely different way on something other than a press per Pantone's expectations.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Sat, 1 May 2004 12:53:19 -0600

From: Chris Murphy

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

On May 1, 2004, at 7:49 AM, jc castronovo wrote:

Has this been consistent across Quark versions 4, 5, and 6? When one

converts from spot to process in Quark, what are the process

assumptions?

I just did a few tests to confirm, and in PostScript it's specifying both the Pantone reference and an alternate reference in CMYK which matches the process builds found in the Solid to Process Color Guide. So even if LAB (or RGB or whatever it is) being used to better simulate them on-screen as spot colors, it's not affecting output which is unfortunate.

How about PhotoShop?

If you add a channel and select a color, only the Pantone reference survives in a DCS file. There is no alternate which means it's just a grayscale channel to anything that doesn't know explicitly what the Pantone reference is.

If you select a solid color in the picker and draw in an existing RGB or CMYK document with master channel selected, the LAB color has already been converted to the assigned profile for that document. So you are getting custom RGB or CMYK values for that device, attempting to preserve the color appearance of the original (LAB) color. The reference to the Pantone color itself is lost.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Sat, 1 May 2004 13:06:46 -0600

From: Chris Murphy

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

On May 1, 2004, at 10:40 AM, jc castronovo wrote:

Yup, but even better fun starts when designers begin specifying tints of

Pantone colors in Quark.

All bets are off with tints as well as overprints with Pantone solids. First you need to know the dot gain of that ink on press, second you need to know it's opacity. Photoshop calls it solidity, and is used for preview purposes only. This is why these sorts of things are done the old fashion way - experience. And they cost more.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Sat, 1 May 2004 13:04:37 -0600

From: Chris Murphy

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

On May 1, 2004, at 8:39 AM, Stephen Marsh wrote:

I could also ask those more knowledgeable on the list - what are the

assumptions about colour in Adobe software such as AI9 or higher...if

colour management is off and emulating v6 behaviour...as one can no

longer have a mixed mode file with both RGB and CMYK elements...so

you are forced to convert the entire file to one mode or the

other...so there is an assumption made somewhere in this blind

conversion which we are now forced into.

The color setting itself doesn't matter per se, what matters are the working spaces. When you select a solid color, Illustrator treats it as solid (spot) until you tell it to be RGB or CMYK (depending on the mode of the document). The preview is based on Pantone's solid to process numbers, with the working space being assumed as source. If you convert the document to RGB, spot remains spot, but if you want it RGB (or it was previously convert from spot to CMYK) then you get pantone's solid to process values + working space CMYK as source + document profile as destination (which if you just do a mode conversion on the document is the working space RGB profile).

So basically you get a mess if you're trying to match a Pantone solid (or get close). But what you see on screen is what you'll get in print if you a.) have a calibrated/profiled display and b.) have a good output profile.

So one should be able to compare the ICC LAB values from Photoshop

for a spot colour against Quark 4 or higher CIE LAB for the same

colour and as long as they are both using the same formula (either

pre or post 2000)...apart from rounding differences between the

different LAB systems AB components...I would not expect major

variation, but I have not tested this!

As far as I know the encoding of CIE LAB is the same across the board for all of these applications, including what is used for ICC profiles because it's based on either 8-bit encoding (which is what we see) or 16-bits/channel or 20-bits/channel encoding behind the scenes for conversions depending on the CMM being used. So I don't think there is a need to distinguish between them. CIE LAB uses a very different scale than how it gets encoded for graphic arts application.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Sun, 02 May 2004 11:28:39 -0000

From: Stephen Marsh

Subject: Re: PMS to RGB (was: printing CMYK to an RGB device)

Are you sure? While the on-screen preview of solids may be LAB based,

those values are not used at output time. Whether I print specifying a

laser printer or various printing presses I get the solid to process

values.

This is what I have thought based on experience printing to CMYK PostScript RIP based Xerox copiers when producing 'digital print runs'. I will go into this in more detail below***, but I could be mistaken in my conclusions. There could be some sort of special colour management applied to composite prints which contain named spot colours from Pantone, but this is not explicitly set that I know of in the front end RIP software or perhaps on the RIP hardware.

Also, in this context I'm not sure what you mean by CIE LAB vs.

ICC LAB.

Photoshop LAB can only be specified in integer values for the AB channels, such as A21. In Xpress, when one selects a Pantone solid spot library colour, then changes the colour mode of this from the default colour book to say LAB values then the result may be A21.x or perhaps 21.xx - this is the difference I am referring to. One can't match value for value the same LAB numbers from Xpress 4 or higher in Photoshop...but one can 'dumb down' the Xpress values to match the integer numbers found in Photoshop (presuming that there are no other differences in how each LAB behaves...I don't know).

We have CMYK values for Pantone solid to process, but a specific output

condition is not available in the form of an output profile. So

Pantone's numbers are ambiguous unless you can replicate their

non-standard print behavior (i.e. it's not SWOP, GRACoL, or ISO 12647

based.)

Agreed...which is why the old method of forcing Photoshop to recalculate new CMYK numbers by retyping the LAB numbers again in the colour picker is such a great technique, if using v6 or earlier. In v7 or higher, one can now use a LAB based colour book or still do things the

old way (both should give the same results...but I have not checked!)

It's worse than this. They think that if they use the CMYK values they

will get the process version in the solid to process guide on *any*

device they print it to. Really. They don't get that these colors can

be out of gamut for the press condition or output device they are

using, let alone that the numeric values will work in a completely

different way on something other than a press per Pantone's

expectations.

Yes, this is why using LAB to communicate colour is so valuable, in this context RGB and CMYK values do not mean anything by themselves - where as LAB does.

***Chris, to answer your previous question in more detail - I will need to double check things, so I will get back to you.

I do recall a recent short run full colour digital copier print job where composite colour was affected by QXP using LAB based source definitions for the named spot colour...

A client sent in a new updated look logo, raster format in RGB and asked us to update their old stationery with this new logo. I pulled the data off archive and replaced the old vector EPS file with a CMYK TIFF of the new supplied logo. In Illustrator, I noted the CMYK source values for the old spot colour definition and made sure that when I separated the RGB to CMYK, that the same values were in the logo. I can't recall the exact PMS, but it was probably Reflex Blue.

When the first test print was made and compared to the old prints - the new logo was a very different blue...and the blue in the new raster logo was very different to the old blue used in other imported vector elements and native layout elements using the named colour in QXP.

This confused me at first, I had synced the CMYK values - which is how the colour is defined in Illustrator...I do not use CM at the layout or print level and the new file was a CMYK file so there should have been no issue there. Colour should have been the same.

In QXP, this Reflex Blue spot colour was defined using the default library for Pantone Solid - no numbers are associated with this colour swatch, only a name. One can then choose to change the mode/model of the colour to LAB or CMYK or RGB or HSB etc...so when I then changed the colour definition from the default library build to a CMYK model and then matched the values to the new CMYK raster logo which I had separated...all the page elements colour was synced and now matched...but this was not the same colour as the original default library, composite prints do not look the same, the colour is totally wrong using CMYK values.

Due to deadlines, the fix was simple but perhaps not ideal.

I found new suitable CMYK values to redefine the spot colour ink in QXP from the default (presumed LAB based) to the new mix which equated to the same visual result as the original print run. This meant altering the CMYK mix of the new raster logo in Photoshop and in any other imported vector elements.

So then all the page elements had the same composite colour appearance and it matched the original print run.

I came to the conclusion that at print time, the default spot colour definition was being interpreted as something other than the CMYK mix which is stated in Adobe software as the build for this ink...QXP was the part of the equation which was affecting the composite colour.

If I had saved the raster logo as EPS DCS 2 with a spot colour plate for the new logo, with the same LAB definition as QXP would seem to indicate is in use - then perhaps the print stream would have made this new object the same colour as the vector EPS and QXP elements.

Who knows? Who has the time to test this stuff, one just finds a solution

and moves on with the intent of proving/solving the issue at a later date

when work slows down a bit...

I hope this makes sense, I will post back with sample images of test prints which illustrate my point with the steps taken etc.

Stephen Marsh.

___________________________________________________________________________

Date: Sun, 2 May 2004 10:09:31 -0400

From: John Castronovo

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

From: "Stephen Marsh"

Who knows? Who has the time to test this stuff, one just finds a solution

and moves on with the intent of proving/solving the issue at a later date

when work slows down a bit...

Our best (and simple) solution to date is to use CompassProXT for Quark. When we print, it parses the Quark document looking for spot colors, then it converts from the spot LAB values to the destination color space when it creates the postscript file. It can also convert tiffs and EPS files to the printer's space. The results are both consistent and the best match that can be had using the device profile that we're printing to.

john c.

___________________________________________________________________________

Date: Sun, 2 May 2004 13:45:50 -0600

From: Chris Murphy

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

On May 2, 2004, at 5:28 AM, Stephen Marsh wrote:

This is what I have thought based on experience printing to CMYK

PostScript RIP based Xerox copiers when producing 'digital print

runs'. I will go into this in more detail below***, but I could be

mistaken in my conclusions. There could be some sort of special

colour management applied to composite prints which contain named

spot colours from Pantone, but this is not explicitly set that I know

of in the front end RIP software or perhaps on the RIP hardware.

Actually that is the most likely explanation. Quite a few RIPs these days have full Pantone libraries in them, and use their own CMYK equivalents when encountering Pantone colors by name, instead of using the CMYK alternates provided by the application.

Photoshop LAB can only be specified in integer values for the AB

channels, such as A21. In Xpress, when one selects a Pantone solid

spot library colour, then changes the colour mode of this from the

default colour book to say LAB values then the result may be A21.x or

perhaps 21.xx - this is the difference I am referring to. One can't

match value for value the same LAB numbers from Xpress 4 or higher in

Photoshop...but one can 'dumb down' the Xpress values to match the

integer numbers found in Photoshop (presuming that there are no other

differences in how each LAB behaves...I don't know).

This is a user interface difference. The flavor of LAB is identical in both cases. For example, even though a CMYK file has 256 levels just like an RGB image, Photoshop only presents a 0-100% scale. You can only directly control 100 levels even though behind the scenes it translates to 256. Same with 16-bit/channel where you have 65,000+ levels but you still are interacting with 256.

All ICC-based conversions, including LAB ones, are converted through 16-bits per channel with the Apple CMM. And 20-bits/channel with ACE in Adobe applications, which is over 1 million levels in each channel.

Unfortunately there is apparently no LAB->CMYK conversion possible for Pantone solids, either for composite printing or separations printing in QXP. At least not in version 6.1.

Agreed...which is why the old method of forcing Photoshop to

recalculate new CMYK numbers by retyping the LAB numbers again in the

colour picker is such a great technique, if using v6 or earlier. In v7

or higher, one can now use a LAB based colour book or still do things the

old way (both should give the same results...but I have not checked!)

The old way was CMYK->LAB->CMYK. You would never get closer to the actual Pantone color because the LAB values weren't available until Photoshop 7. In version 7, they're built in by design in any non-solid to process library. No need for a LAB based color book (not that I know of any).

I do recall a recent short run full colour digital copier print job

where composite colour was affected by QXP using LAB based source

definitions for the named spot colour...

I don't think you can use LAB in QXP and no get a conversion to CMYK at output time, even if color management is off, unless you're using QXP 3.x or QuarkXPress 6.x which has "As Is" color output.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Mon, 03 May 2004 14:31:19 -0400

From: Lee Clawson

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

Chris and all,

I'm not surprised about some of what's being discussed. We use the solid to Process guides as a reasonable approximation of the color. But expecting the color to look the same with various paper stock, dot gains and plate sequence (Pantone uses KCMY with 175 line screen in their books) is not something I expect.

We have the Pantone Tint guides and I use them a lot. I don't expect tints to stay the same hue as they get lighter. And the variable opacity from color to color is something I always seem miss.

Pantone's FAQ section makes the following statements about LAB:

"Pantone does not publish L*a*b* data for its colors. If you are attempting to use this data as a standard for color matching, we would recommend that you perform your own measurements on a fresh printing of the PANTONE formula guide to determine your data. This data would be most meaningful to you as it represents your instrumentation, production environment and viewing environment.

If you have a spectrophotometer manufactured by Gretag or X-Rite, these companies are licensed by Pantone to incorporate data tables within their instruments. Contact Gretag (http: //www.gretag.com) or X-Rite (http://www.xrite.com) directly for more information. Further, Adobe Photoshop supports L*a*b* color space and can provide conversions from PANTONE Colors to L*a*b*. Keep in mind, however, that this data is based on the algorithms in Adobe Photoshop and may differ from actual measurement data."

Lee

___________________________________________________________________________

Date: Mon, 03 May 2004 20:06:10 -0700

From: Jono Moore

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

Stephen Marsh wrote:

This is what I have thought based on experience printing to CMYK PostScript RIP based Xerox copiers when producing 'digital print

runs'. I will go into this in more detail below***, but I could be

mistaken in my conclusions. There could be some sort of special

colour management applied to composite prints which contain named

spot colours from Pantone, but this is not explicitly set that I know

of in the front end RIP software or perhaps on the RIP hardware.

Most RIPs have LUTs for PMS colours, etc. One must usually explicitly set this off in the RIP. When it is turned off, the RIP will use the process build sent by Quark (or any layout software). If you don't want the RIP to use its LUT on the spot colour, and you don't control the RIP, rename the colour (they work by name).

Whether you want to use the LUT or not depends on the RIP and how the colour looks. Some do a good job and some are awful.

With composite RIPs for digital you also want to make sure that any GCR is turned off in the RIP, it will destroy your CMYK values. GCR set on seems to be the default. Also, check for a setting along the lines of "print grey/black using just black" or words to that effect, it will make all your black/greyscale artwork not print with four colours (including black type).\

I can't speak for trying to send LAB data to these beasties, I've never tried.

As I believe someone mentioned, you may have run into differing Pantone colour definitions, as well.

Some things I've observed using various high-end laser printers/RIPs:

- they aren't that accurate unless someone spends a lot of time calibrating and most print shops don't. And most of the calibration is linearization, so they're not really calibrated to a dot value.

- they need to be calibrated many times a day if you are at all worried about colour.

- they are designed to print good looking RGB data. The toner pigments are tweaked to expand the gamut. I've started to stop converting digital jobs to CMYK because I get better results sending RGB data.

- it really really really depends on the RIP. :) There are large differences in colour rendering between Fiery, Splash, Creo, etc.

- the colour also really depends on the paper you are printing on. Some laser stocks have quite a blue tint to them to make the colours pop more.

...Jono

___________________________________________________________________________

Date: Mon, 03 May 2004 20:09:40 -0700

From: Jono Moore

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

Stephen Marsh wrote:

If I had saved the raster logo as EPS DCS 2 with a spot colour plate

for the new logo, with the same LAB definition as QXP would seem to

indicate is in use - then perhaps the print stream would have made this

new object the same colour as the vector EPS and QXP elements.

See my other post about DCS files with composite RIPs.

One way it will work though, is if you run separations from Quark and use the RIPs "combine separations" function if it has one (quite a few seem to now).

...Jono

___________________________________________________________________________

Date: Mon, 03 May 2004 23:55:49 -0400

From: Jim Rich

Subject: Re: Re: PMS to RGB (was: printing CMYK to an RGB device)

It seems after looking at a number of RIPs, that when using any brand of RIP for color matching Pantone colors, each vendor has engineered their own technology and secret sauce for this process.

For example one common method that a lot of RIP vendors use is to take the LAB values from the Pantone color library and then take One-Shot at mapping the LAB color to the output color space. Obviously this is the One-Shot method.In that process if the LAB color is out-of gamut then the color is clipped.

Other (less used) methods in RIPs that happen to be more accurate is to take Multiple-Shots at the LAB color to try and bring out-of-gamut colors into gamut so they have the best possible visual match. Each vendor calls this something different.

To find out what type method that is used for PMS colors, you have to usually ask the RIP vendor how they handle Pantone color matching.

Jim Rich

___________________________________________________________________________

Date: Tue, 04 May 2004 08:56:25 -0000

From: Stephen Marsh

Subject: Re: PMS to RGB (was: printing CMYK to an RGB device)

Chris Murphy wrote:

Actually that is the most likely explanation. Quite a few RIPs these

days have full Pantone libraries in them, and use their own CMYK

equivalents when encountering Pantone colors by name, instead of using

the CMYK alternates provided by the application.

It does seem this way from your post Chris, cheers (also recent posts from others seems to repeat this message too).

The copier/s are driven via a software RIP on the PC (commandworkstation) and with a Fiery hardware box on the RIP which was there before the PC software was placed in front...so it is a bit of a mess.

I still have to find time to look deeper at this but it does sound like my initial conclusion was wrong. Back to tests when I find time...

Thanks for the continuing education Chris!

Stephen Marsh.

___________________________________________________________________________

Date: Tue, 04 May 2004 09:05:07 -0000

From: Stephen Marsh

Subject: Re: PMS to RGB (was: printing CMYK to an RGB device)

Jono Moore wrote:

See my other post about DCS files with composite RIPs.

Good point Jono, when I wrote this I was just thinking about where/why the colour was being altered and how to sync it again - even if I had done this then the colour may have been right...but the graphic would have been low res.

One way it will work though, is if you run separations from Quark and

use the RIPs "combine separations" function if it has one (quite a few

seem to now).

Yes, this is a nice feature if you have it - I can remember a 3M Rainbow dyesub printer that I used back in the early `90's could combine CMYK seps that were sent to it to provide 'true' proofing of layout elements as opposed to the more traditional composite print.

Stephen Marsh.

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

Contact request form

Receive Schedule
and Pricing updates.

If you let us know how to contact you, we will enter you into our monthly drawing for a free 2-day class (A $895 value).

Get free video training
Get free tips, tricks and shortcuts
Get special sale pricing and free seminar invitations

Logo_small

Teach for us

Sterling Ledet & Associates, Inc. 4100 Perimeter Park South Atlanta, GA 30341

work sales@ledet.com work administration@ledet.com work webmaster@ledet.com

P work 770.414.5007 P work 877.819.2665 F fax 312.896.9094

Authorized Training Provider

Receive Schedule and Pricing updates.

Receive Schedule
and Pricing updates.