Adobe 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 <