Deliver in LAB | Photoshop Training with Dan Margulis

Dan Margulis Applied Color Theory

Delivering Files in LAB?

Date: Tue, 22 Jul 2003 12:55:04 -0700

From: Dennis Dunbar

Subject: Delivering Files in LAB?

On another list there was some recent discussion about photographers delivering their files in LAB in an effort to avoid any problems with printers and prepress shops that are not using icc profiles.

What do the prepress and printers on this list think of this idea? Would that make life easier for you, or create more problems? Any other landmines to be careful of with this kind of workflow?

Dennis Dunbar

________________________________________________________________________

Date: Tue, 22 Jul 2003 23:52:39 EDT

From: Dan Margulis

Subject: Re: Delivering Files in LAB?

Dennis writes,

On another list there was some recent discussion about photographers

delivering their files in LAB in an effort to avoid any problems with

printers and prepress shops that are not using icc profiles.

What do the prepress and printers on this list think of this idea? Would

that make life easier for you, or create more problems? Any other

landmines to be careful of with this kind of workflow?

This seems like the only logical way to avoid being victimized in the way that prompted the recent lengthy "Who's to Blame" thread, where a printer who didn't know what a profile was ignored one with disastrous results.

If you must give an RGB file to an unknown provider, it should be an sRGB file. That's where the industry is headed. This is way better than handing off an Adobe RGB file, which few people know what to do with. But even with sRGB there's still more room for an accidental misinterpretation than one would like.

Photoshop's LAB can't be misinterpreted--the service provider has to convert it into his own RGB or CMYK. The only downside is that you may get a call in the middle of the night from somebody on the third shift who says your file must be corrupt because he can't figure out what format it's in. And when you stop to think of it, that isn't a downside. If he can't figure out what to do with an LAB file, it's highly unlikely that he knows what to do with an embedded profile.

Dan Margulis

________________________________________________________________________

Date: Wed, 23 Jul 2003 14:06:24 +0200

From: Julien Michel Palmas

Subject: Re: Delivering Files in LAB?

If he can't figure out what to do

with an LAB file, it's highly unlikely that he knows what to do with an embedded

profile.

Dan Margulis

I believe the contrary is also true. If a printer or a pre-press guy doesn't have a clue about icc profiles, he surely doesn't know much about Lab. Colorimetry is very well known by photographs but not yet by pre-press. give a Lab file and you will spend much time explaining your client what he has to do with. Or, he will certainly convert it to CMYK without even wondering about color space. as denis said it in his first post, this topic is beeing discused on this forum :

http: //www.robgalbraith.com/ubbthreads/postlist.php?Cat=&Board=UBB3

julien palmas

________________________________________________________________________

Date: Wed, 23 Jul 2003 09:45:20 -0700

From: "Raymond E. McKinley"

Subject: Delivering files in LAB

Julien writes

He will certainly convert it to CMYK without even wondering about color spaces

This seems to be the biggest plus as far as delivering files in LAB. My understanding of CM is that when each profile tells the Color Management module what the LAB values of the file are, then the CMM converts to other spaces, and displays colors on your monitor based on these values, (which are LAB numbers) If the embedded file is discarded their is no frame of reference for the CMM to use when making conversions, so who knows what your file will end up as. If you use LAB then the color values cannot be misinterpreted the way they can when the profile is trashed. So even if some off the wall CMYK or RGB is used to make the conversion, your original intent should be preserved, since the CMM will be making the conversion based on LAB, the same way it would if a profile were being used.

Raymond

________________________________________________________________________

Date: Wed, 23 Jul 2003 09:36:33 -0500

From: Lori Sabo

Subject: Re: Delivering Files in LAB?

The native RIP on our Roland printer prints differently given a LAB file than an RGB file with the right profile embedded and selected. The colors seem more exaggerated printing in LAB. Don't know what goes on there.

________________________________________________________________________

Date: Wed, 23 Jul 2003 17:00:02 +0200

From: Julien Michel Palmas

Subject: Re: Delivering files in LAB

You are right saying that having Lab values would avoid the problem of embedded profile.

But when converting to CMYK, you must use another profile. The one that describes your printer for example. If you do this conversion without worrying about the destination profile, you will transform the good Lab data into something bad.

And this is likely to happen, because if the pre-press doesn't know how to handle icc embedded profiles, why would they care about a destination profile ?

i don't think Lab delivery would make a big change, because without color and color management knowledge in both photographs and printers sides, you can't achieve good results. And you need to know color to understand Lab.

julien

________________________________________________________________________

Date: Wed, 23 Jul 2003 12:27:21 -0400

From: Terry Wyse

Subject: Re: Delivering files in LAB

on 7/23/03 11:00 AM, Julien Michel Palmas wrote:

But when converting to CMYK, you must use another profile. The one that

describes your printer for example. If you do this conversion without

worrying about the destination profile, you will transform the good Lab

data into something bad.

And this is likely to happen, because if the pre-press doesn't know how to

handle icc embedded profiles, why would they care about a destination profile?

Of course that's correct but if given the choice between a bad assumption on what the RGB source profile should be going to a "bad" CMYK destination profile vs. a Lab file going to the same bad CMYK destination, I'd take the latter. Better to have ONE potentially incorrect conversion vs. two!

As clueless as we MIGHT assume the prepress shop is as far as handling RGB files with embedded profiles, I'd say that there's a better than even chance that they have a decent CMYK working space profile chosen in their color settings which makes the point for supplying Lab and assuming the prepress folks know a little something about what their CMYK destination should be.

Dan said:

If you must give an RGB file to an unknown provider, it should be an sRGB

file. That's where the industry is headed. This is way better than handing off

an Adobe RGB file, which few people know what to do with. But even with sRGB

there's still more room for an accidental misinterpretation than one would

like.

I'd say it's closer to a 50/50 chance between sRGB and AdobeRGB, at least among most commercial offset printers. IOW, at least half of them have half a clue (does that make it a quarter of a clue??).

As far as "that's where the industry is headed", I'd have to disagree. I and others I suspect are working hard to change this and getting printers of all sorts into a more "color managed" workflow. People can say what they want but clearly the "old" way of working DOESN'T work given that prepress in-house scanning is going away as we see a growing majority of imagery supplied as digital camera captures or customer scans. At any rate, I don't see an INCREASED push towards sRGB as an industry standard. Having said that, I'd much prefer a situation where all images where PROPERLY tagged with sRGB as opposed to the current state of not tagging images at all.

Personally, when I'm given the opportunity to 'fix' or improve a prepress/printer's workflow, I first look at fixing the pressroom. For me, instead of simply profiling their presses where they're currently at, that means bringing their presses to some sort of SWOP or GRACoL standard as far as dot gain, gray balance and SID. Usually this entails coming up with plate or film curves to bring them closer. It's at THAT point that you can consider profiling the presses but it's not altogether necessary since by definition you've got them to a point where the majority of CMYK separations will probably just work. If a press profile is created, it's generally in an effort to bring their inkjet proofing system in line with the press. As a bonus, we can use this same profile in Photoshop as a CMYK working space. Those steps above will probably fix 70-80% of their color workflow issues. Profiling the scanners, monitors, etc. is important but it's more like icing on the cake in my opinion. In fact, I might even argue that getting their monitors calibrated/profiled is more important than the scanner itself. As I already mentioned, their in-house scanning is likely to DECREASE while their reliance on a good calibrated/profiled display will become an even MORE critical point in their workflow. Try making an accurate assessment on what profile should be assigned to an untagged image without an accurate display and you're shooting in the dark as far as I'm concerned.

Well, I can see that I've rambled again....

Cheers,

Terry

__________________________________

WyseConsul

Color Management Consulting

v 704.843.0858

__________________________________

________________________________________________________________________

Date: Wed, 23 Jul 2003 11:39:56 -0600

From: Chris Murphy

Subject: Re: Delivering files in LAB

On Wednesday, July 23, 2003, at 09:00 AM, Julien Michel Palmas wrote:

But when converting to CMYK, you must use another profile. The one that

describes your printer for example. If you do this conversion without

worrying about the destination profile, you will transform the good Lab

data into something bad.

This is a valid concern. I regularly see not only improper settings, but different settings. And the assumption by large numbers of people in the service bureau and printing industry is that Photoshop simply doesn't make good separations. They set it to something close enough, and then mess around in CMYK to fix the file. It is possible to get good separations from Photoshop, but they'd rather dink around manually in CMYK. As long as the customer isn't paying for such unnecessary service, then it may not matter, but in some cases the separations are bad enough that only the very skilled color corrector could fix them, in which case such a skilled person would probably have made the effort to get decent separations to begin with because it will make their life easier if they do have to make adjustments in CMYK.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

________________________________________________________________________

Date: Wed, 23 Jul 2003 11:44:27 -0600

From: Chris Murphy

Subject: Re: Delivering files in LAB

On Wednesday, July 23, 2003, at 10:27 AM, Terry Wyse wrote:

Of course that's correct but if given the choice between a bad assumption on

what the RGB source profile should be going to a "bad" CMYK destination

profile vs. a Lab file going to the same bad CMYK destination, I'd take the

latter. Better to have ONE potentially incorrect conversion vs. two!

In a number of situations I've seen CMYK setup set to compensate for a whacked display profile being used as the working space. Seriously. So the two were a requirement for getting a half-way decent separation. If you'd give a LAB file to these organizations it would have been a disaster.

As clueless as we MIGHT assume the prepress shop is as far as handling RGB

files with embedded profiles, I'd say that there's a better than even chance

that they have a decent CMYK working space profile chosen in their color

settings which makes the point for supplying Lab and assuming the prepress

folks know a little something about what their CMYK destination should be.

The above example is rather rare. But I wouldn't assume that anyone has decent CMYK settings because I've seen too much of the wrong thing. Huge numbers of people separate using Photoshop defaults even though they aren't printing on anything resembling a publication.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

________________________________________________________________________

Date: Wed, 23 Jul 2003 07:31:58 -0600

From: Andrew Rodney

Subject: Re: Delivering Files in LAB?

on 7/22/03 9:52 PM, Dan Margulis wrote:

This seems like the only logical way to avoid being victimized in the way

that prompted the recent lengthy "Who's to Blame" thread, where a printer who

didn't know what a profile was ignored one with disastrous results.

Every capture device on this plant produces RGB in all kinds of flavors. So to propose we spend the time and energy (plus the data loss) to go RGB to LAB to RGB or CMYK is just silly. If someone is too dumb to know how to covert the LAB file to an output space, what hope do we have that they will be able to do this with LAB? If someone is too dumb to embed the right profile in the original data, what hope do we have they will do a correct RGB to LAB conversion? It1s just a lame excuse for not practicing the right way to deal with the file in the first place.

If you must give an RGB file to an unknown provider, it should be an sRGB

file. That's where the industry is headed.

That1s complete nonsense. So now we should ignore stupid users who can1t embed the right profile in the first place and convert into a tiny space that is smaller than the CMYK gamut?

This is way better than handing off an

Adobe RGB file, which few people know what to do with. But even with sRGB

there's still more room for an accidental misinterpretation than one would

like.

On a uncalibrated display, an untagged sRGB file isn1t necessarily going to look worse or better than Adobe RGB; it1s a crap shoot.

This discussion is really insane. We have techniques in place THAT WORK and people are tying to invent techniques to make them so idiot proof that now there are far more ways to hose a file. What1s so damn difficult about embedded the correct profile? Oh, it involved those nasty profiles.

Photoshop's LAB can't be misinterpreted--the service provider has to convert

it into his own RGB or CMYK. The only downside is that you may get a call in

the middle of the night from somebody on the third shift who says your file

must be corrupt because he can't figure out what format it's in.

First, there are still plenty of dinosaur users (those that say they1ve turned off color management in Photoshop) that have older versions of LinoColor who1s description of LAB isn1t the same as Photoshop so it1s still possible to hose this LAB process. Modern copies got fixed but I1m sure all those Photoshop 4/LinoColor users don1t know this.

Second, how is having someone call in the middle of the night clueless any better than simply doing the work correct the first time (embed the correct profile)?

And when you

stop to think of it, that isn't a downside. If he can't figure out what to do

with an LAB file, it's highly unlikely that he knows what to do with an

embedded

profile.

So much for inventing idiot proof workflows. How about instead of us trying to come up with every conceivable kludge for people who may not understand what an embedded profile is (after 6 years or so of Photoshop), how about we EDUCATE them Danno? You teach, why not tell them the CORRECT way to handle files. God forbid you actually recommend people do the quick, simply thing which is just embed the right profile. It1s not at all hard to do and it1s easy to teach (unless of course you have a profile phobia).

Or should we have some idiot proof kludge fix for people who sample down their files to 1mb files and save as JPEG with a super low quality factor since it1s possible that some clueless user might hose their file that way. Oh, what about the user who over sharpens their file so high you can see halo1s a mile away?

For a list that1s supposed to cover color theory, how about teaching the correct theory/technique instead of making up excuses for dumb users who will despite anyone1s best effort hose a file?

Andrew Rodney

http://www.imagingrevue.com/

________________________________________________________________________

Date: Wed, 23 Jul 2003 11:36:29 -0600

From: Chris Murphy

Subject: Re: Re: Delivering Files in LAB?

On Wednesday, July 23, 2003, at 08:36 AM, Lori Sabo wrote:

The native RIP on our Roland printer prints differently given a LAB file

than an RGB file with the right profile embedded and selected. The

colors seem more exaggerated printing in LAB. Don't know what goes on

there.

Chances are it doesn't know what an embedded profile is either, but these days it's hard to say as there are increasing numbers of RIPs that do know. If you are printing from a page layout application however, they strip embedded profiles when the PostScript print stream is generated in all file types except for EPS.

What's happening is the built-in profile for RGB is not the same as what you're using on the desktop. If it were the same, your RGB image would be "converted" into the equivalent of the LAB file and would print largely the same as a LAB file (accounting for out of gamut colors).

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

________________________________________________________________________

Date: Thu, 24 Jul 2003 18:15:00 -0700

From: Mac Townsend

Subject: embed profiles so what?

I've watched the various threads on this and I'm more than a little confused.

I daily handle anything from PowerPoint to Word to MS Pub to Quark, you name it. Need film or a 36x48 poster from that cute picture your 18 month old made in Kid Pix? Can Do! (sometimes<G>)

All but a few of my customers are 2-color press printers. Neither they nor their customers, for the most part, hardly know which end of a mouse to hold. Scans/digipix come in with and without profiles embedded, sometimes 5 different scans will each have a different profile embedded.

If they are RGB, I'll usually let my Harlequin handle it (light GCR, 310 TIC, 75% max K, pretty much the same settings I use in Pshop). I have no idea if the Hqn reads and reacts to any embedded profiles...I do not have their special addons. If the files are in CMYK, I'll usually let the app separate them with CM turned off....assuming that what is 40% in the file will turn out to be pretty near 40% on the film.

What am I doing wrong?

Yesterday I got a file in XP/Mac. My main B&W G3 macbox was having hissyfits over something, so I configured my backup (a 7600 w/G4 card) and loaded the files. Wham! XP 5 informed me I didn't have the needed profiles installed. After thinking about it, I quit, found the Quark CM XT, and disabled it. Reloaded, sans error messages, printed seps, ran them thru Harlequin to make composite cmyk tiff, fed that to my Best "rip" to make proofs on my BJC8500. The proofs came out pretty darn close to the previously printed example.

What am I doing wrong here?

________________________________________________________________________

Date: Fri, 25 Jul 2003 06:45:41 -0400

From: John Castronovo

Subject: Re: embed profiles so what?

From: Mac Townsend

What am I doing wrong?

Your approach assumes first, that all of your incoming files will be very much alike, and/or second, your customers are not all that critical about repeatable results.

As Lindbergh proved, you don't need a global positioning system to fly East from New York to reach Europe. When we get a file without an embedded profile, it's like being dropped in mid-air somewhere in the Atlantic. Even though we might have a compass and we know we need to go East, we can't really be sure of the latitude or where we came from. We might hit London or Lisbon depending on our assumptions. If that's good enough, fine. The mother with the KidPix file isn't going to sue you because your output doesn't match her monitor. If you need more control, however, then you need a GPS or color management.

john castronovo

tech photo & imaging

________________________________________________________________________

Date: Fri, 25 Jul 2003 07:36:14 EDT

From: Dan Margulis

Subject: Re: Delivering files in LAB

Chris Murphy writes,

I wouldn't assume that anyone has decent CMYK settings because I've seen

too much of the wrong thing. Huge numbers of people separate using Photoshop

defaults even though they aren't printing on anything resembling a publication.

That's certainly true, which is why I think giving a print shop a CMYK file in the first place is the best solution for those who feel comfortable doing so. However, in my experience, more print shops have reasonably accurate CMYK settings than even know what an embedded RGB profile is, for obvious reasons. They have no interest in embedded profiles because their clients don't. They have a considerable interest in good CMYK settings because they contribute to having screen proofs accurate enough to avoid unnecessary proofing runs, thereby putting money directly in their pockets.

But, this is all beside the point. Having somebody sep the file with Photoshop defaults is undesirable, but it's scarcely a disaster unless you were planning to print the job waterless or flexo. Neither is it a disaster if your file is ColorMatch RGB but somebody thinks its sRGB.

There's only one real disaster in all this conversion stuff, only one mistake that will almost certainly result in a ruined job, and that is if your file is Adobe RGB (or something even wider-gamut) and somebody else isn't on the same page. But regardless of what flavor of RGB you use there's no point in taking needless chances granted how few people know how to handle embedded profiles.

You simply have to ask yourself whether you'd prefer to give the job its best chance of coming out right, in which case you give the printer the file in LAB or CMYK; or whether you'd prefer to, like Andrew Rodney, hee about how stupid they were to accept your invitation to hose your job, and haw about how other people should educate users.

Dan Margulis

________________________________________________________________________

Date: Fri, 25 Jul 2003 07:24:37 -0500

From: Henry Segalini

Subject: embed profiles so what?

To: Mac Townsend

One definition of quality is, "meeting or exceeding customer expectations". Apparently you are doing so for your existing customer base, so you are doing nothing "wrong". However, if your customer base changes and the expectations change, you may have different challenges.

We (sheetfed/web six-color printer) have some clients like yours. However, we have plenty where "pretty darn close" would cause us to eat the job, and at six figures for one job, it is a prospect to which we do not look forward.

We have Customers who don't want to pay for a proof---we run to densities, and they get what comes off the press (we charge and they pay accordingly).

We have other Customers where we make custom profiles exclusively for that customer (we charge and they pay accordingly).

So, for us, it is a question of learning and understanding the customer's expectations.

Henry Segalini

St. Louis MO USA

________________________________________________________________________

Date: Fri, 25 Jul 2003 10:11:53 -0700

From: Mac Townsend

Subject: Re: embed profiles so what?

I think my approach recognises that the files I get are overwhelmingly NOT prepared by professionals. Maybe 1 in 20 is, and that 1 is from someone who wouldn't know a profile from a blueberry scone--after 5 years I still can't get her to not use the default Photoshop heavy black generation when she converts to cmyk (because, she says, it looks better on her Color Laserjet).

In 90% of the cases I have no contact with the creator of the files I get. Most of the time I can't even find out what application and platform the files were created on. (When the printer asks, the person delivering the files doesn't know and nobody thinks it important enough to find out.) When I do have contact with the generator, they don't even want to hear about the difference between rgb and cmyk let alone different flavors of each. And they don't care.

Most do not have or use Photoshop, scanning with whatever came with their scanner or simply dropping the digicam files onto disc. I'm not even able to get them to record their photos at "super high quality" which means many pics are low res. One I have now has a bunch of 72 dpi pix that are cropped and enlarged 300 % and will run at 150LPI. Look like crap, but they're used to it I guess.

All of which means the files have no profile at all, or else some camera profile.

What should be done in that case? This ain't high end work, folks. It's run "by eye," as most things were 20 years ago, on 2 color presses with no pressroom densitometer etc, etc. One guy has an old half-size Heidleberg 4c (how long since they made 20x28? I think it's been awhile). Again, run by eye.

Should I accept the files and assign an rgb profile to them (which one?) before converting to cmyk? SHould that cmyk profile be embedded? And of what use is an embedded cmyk profile anyway when the thing is going to be ripped to linear film?

All this at film prices that have not changed since 1995<G(that's my fault, I know)

Mac Townsend

Adcom Graphics, Digital Imaging

Fairfield, California

www.adcomgraphics.com

________________________________________________________________________

Date: Fri, 25 Jul 2003 15:43:47 EDT

From: Stephen Ray

Subject: Re: Re: Delivering files in LAB

I have seen approx 30 LAB files in year 2002 and less than 10 LAB files this year submitted for output to various CMYK and RGB imaging devices. In every case, there was no advantage what-so-ever to my shop or my customers.

The vast majority of the files had a so-called Match Print which, you've guessed it, didn't match the file. The match prints were iterations of the file made by a print vendor somewhere in the job stream and not by the scan house. A creative, an executive, (who knows?), made the decision that the color would now would be that of the match print and not the file for ever more.

Also, the vast majority of the files which had a so-called Match Print were submitted without the Match Print upon the first work order. Although the first image products that were produced matched the file, they were rejected and the interation Match Prints accompanied the job for the second round. The customer paid twice, but was now inadvertently unhappy with the scan house who promissed an easy, color-accurate work flow.

The whole idea of color management via ICC profiles is ridiculously complicated. All the software is still stupid and perplexing. Dialog boxes, options, tools, etc., change with every new version which prooves the developers don't have it figured out. (But who else does?) Is sRGB really so small? What color in our natural world is beyond reach of sRGB?

Do I believe in CM by profiles? Absolutely, but an analogy is I operate the software as if I'm at Laguna Seca and I'm very interested in the vehicle. 99 percent of users just "commute" with the software and crash all the time and believe it's normal.

-Stephen Ray

________________________________________________________________________

Date: Fri, 25 Jul 2003 21:31:16 -0400

From: John Castronovo

Subject: Re: embed profiles so what?

From: Mac Townsend

Should I accept the files and assign an rgb profile to them (which one?)

before converting to cmyk? SHould that cmyk profile be embedded? And of what

use is an embedded cmyk profile anyway when the thing is going to be ripped

to linear film?

Yes, that's what we do in these cases. Try assigning a few of the more common profiles and choose the one that looks best on your profiled monitor. Then convert to your CMYK space of choice.

Actually, this is no different than when a custom photo lab prints a negative. The color gets adjusted printed and reprinted at no charge until it looks reasonably neutral. Afterwards, the customer shows up waving a sample print he had previously made at the drug store and he's asking why it looks different from yours. Pros put a gray scale in the shot so the lab can tell when the color and density are correct. A profile is a kind of electronic gray scale. Properly used, it can only help.

All this at film prices that have not changed since 1995<G(that's my

fault, I know)

No it's not. We're all guilty of attempting to do this kind work for just slightly more than it would cost the customer to do it himself.

john castronovo

tech photo & imaging

________________________________________________________________________

Date: Fri, 25 Jul 2003 23:55:14 -0700

From: Dennis Dunbar

Subject: Re: Delivering files in LAB

In an earlier post I referred to another list that is comprised mostly of photographers where the idea of delivering files in LAB came up. That list is the APA Digital list. You can find out about it at the APA's main website: apanational.org. (APA stands for Advertising Photographers of America)

In a later post by Dan he said:

"But regardless of what flavor of RGB you use there's no point in taking needless

chances granted how few people know how to handle embedded profiles.

You simply have to ask yourself whether you'd prefer to give the job its best chance of coming out right, in which case you give the printer the file in

LAB or CMYK; or whether you'd prefer to, like Andrew Rodney, hee about how

stupid they were to accept your invitation to hose your job, and haw about how

other people should educate users."

I want to be sure I'm getting this straight. Dan, is your position then that it is better to be safe than to risk potential disaster by thinking you are dealing with an educated professional? I recognize that assumptions are the cause of most of our disasters, and that assuming the "other side" knows their stuff is the worst of all these assumptions. But if there is no pressure for the "other side" to learn about new developments where does that leave us?

I'm not trying to bait you here. It's just that I got to thinking, (yes, I know it's a mistake ;-) ), doesn't the position of making sure you do the job in strictly the safest way possible mean that we have to dumb it all down so much that we give up on what can be really great new tools for making everyone's job easier? I know lots of shops abhor embedded profiles. I know lots of users mess up their images by embedding the wrong profiles. But I also know lots of professionals who know how to work with them, and produce superior results because of this.

Color management isn't going away. It's getting more embedded, (pardon the pun), and it's getting easier to use. But most of all when you set it up properly it works. So how do we start to deal with this? How do we begin to build bridges that facilitate communication so we can get past this endless debate and get on to producing great work?

Dennis Dunbar

________________________________________________________________________

From: Ron Bean

Date: Sat, 26 Jul 2003 08:29:20 -0500

Subject: [colortheory] Re: Delivering files in LAB

Dennis Dunbar writes:

But if there is no pressure for the "other side" to learn

about new developments where does that leave us?

The pressure comes from voting with your dollars-- as Chris says, "be a consumer" and check them out before you give them the job. If they're not capable, then give the work to someone who is. Once you've submitted the job its too late, bitching about it just gets you labeled a "difficult customer". But if they're losing jobs because of it, they'll take notice.

If you're an employee and don't have any influence over who gets the work, then you have to swallow your pride and do whatever it takes to get the result to come out right. If that means tagging the files, then you do it; if it means not tagging them, then you don't. If they're picking a printer based on price and then bitching about the service, you might suggest a better approach...

Unfortunately there are times when you're not allowed to communicate for some reason. In those cases I'd question whether the various parties actually care what the result looks like (some do, some don't).

Dan's approach seems to assume that everyone is an idiot (not that they are, but he's not taking the chance). He recently devoted two of his columns to explaining this logic.

Andrew's approach seems to assume that Murphy's Law has been repealed.

Neither assumption seems necessary to me, but a lot depends on

who you work for.

Ron Bean

________________________________________________________________________

Date: Sat, 26 Jul 2003 23:03:33 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Dennis Dunbar writes,

I want to be sure I'm getting this straight. Dan, is your position then

that it is better to be safe than to risk potential disaster by thinking

you are dealing with an educated professional?

No. My position is that if there is a cheap and convenient way to avoid risking disaster while retaining quality, then I prefer to do so, rather than assuming that the job is going to be handled by others in exactly the way that I expect. There is nothing new about this philosophy; it applies to many, many print situations, and it explains why those experienced with print production have far fewer problems than those who do not.

For example:

1) When two unlike colors butt one another in a graphic, experienced people put in a trap so that a white line can't occur if the job prints out of register.

2) If a picture's primary focus is something neutral, like silver jewelry, experienced people use heavier amounts of black ink and lighter CMY than normal, so that if the press's gray balance is off on the day the job prints there won't be a color shift.

3) If an Illustrator graphic placed in a page layout app contains fonts other than those found in the rest of the document, the experienced person converts them to outlines first because he dislikes seeing Courier in the final job.

4) At the printer's, links to photographs often come undone and the printer has to relink them, and now and then the wrong link is chosen, particularly when there are (as is sometimes necessary) earlier versions of a given image on the same CD or whatever the client provided. This doesn't happen to experienced users, who either don't supply the extra images at all, or make sure that the only images in a printable format such as TIFF are the live ones.

Dennis, all of these moves are quite routine, even though if they weren't done and the job came out wrong, it would be easy to blame the printer. And all of them take more time than the simple step of converting RGB files to LAB, and some of them have minor risks associated with them that converting RGB files to LAB doesn't.

Why do these things? Because clients aren't very good at figuring out who's to blame for print disasters, and because printers *are* very good at persuading clients that it isn't them.

I recognize that assumptions are the cause of most of our disasters, and

that assuming the "other side" knows their stuff is the worst of all these

assumptions. But if there is no pressure for the "other side" to learn

about new developments where does that leave us?

There's plenty of pressure for the "other side" to learn useful new things, and history shows that it's quite agile in responding to it. The concept of embedded profiles being honored by strangers has had five and a half years to prove its worth and is no farther along now than it was then. Meanwhile, closely related things, like the use of profiles to create cheaper and more accurate proofs, *have* been adopted in the last five and a half years, as have the PDF workflow and a host of other things.

I'm not trying to bait you here. It's just that I got to thinking, (yes,

I know it's a mistake ;-) ), doesn't the position of making sure you do

the job in strictly the safest way possible mean that we have to dumb it

all down so much that we give up on what can be really great new tools

for making everyone's job easier? I know lots of shops abhor embedded

profiles. I know lots of users mess up their images by embedding the

wrong profiles. But I also know lots of professionals who know how to

work with them, and produce superior results because of this.

Nobody is stopping them from doing so. All I suggest is that we realize that we are part of what I once called "the small minority of disciplined users" who can benefit from the workflow, and not pretend that what we're doing is in any way mainstream. There's no "dumbing down" involved. All it takes is one simple, painless mode change at the end of the process. All of the benefits, none of the risk.

Color management isn't going away. It's getting more embedded, (pardon

the pun), and it's getting easier to use. But most of all when you set

it up properly it works. So how do we start to deal with this? How do we

begin to build bridges that facilitate communication so we can get past

this endless debate and get on to producing great work?

For the umpteenth time in this thread: this is not about "color management", it's about common sense. It's about a very cheap insurance policy against a major error that happens time and again. The question of whether you can seriously expect, now or at any time in the future, a stranger to honor an embedded profile, isn't *going* away--it's GONE away, and it was gone by the end of the century, when at least most service providers were aware there was some kind of issue. Nowadays, the whole topic is obsolete; it's quite likely that if you mention "embedded profiles" they won't even know what you're talking about.

As for the "endless debate", there is no one more disgusted than I am about the continuing waste of bandwidth in this group by those who can't bear to admit

that any part of their cause is lost.

Dan Margulis

________________________________________________________________________

Date: Sun, 27 Jul 2003 10:39:25 -0400

From: John Romano

Subject: Re: Re: Delivering files in LAB

Dan

First off I feel that we are further along with people using embedded profiles than 5 years ago.

I have customers and designers that are asking or supplying profiles, there seems to be more people getting into it everyday.

And just one thing to add here, but how about sending your files without the profile embedded, but supply the profile on the disk!

That way if you know how to use them your all set and if you dont no harm done.

No accidental conversions but just if you need to convert you have a good source profile to start with.

John

________________________________________________________________________

Date: Mon, 28 Jul 2003 07:36:39 -0400

From: Jonathan Clymer

Subject: Re: Delivering files in LAB

First off I feel that we are further along with people using embedded

profiles than 5 years ago.

I have customers and designers that are asking or supplying profiles,

there seems to be more people getting into it everyday.

The customers and designers who are asking for profiles, are they strangers? I think that one of the reasons this thread won't die is that people are just not carefully reading previous posts.

Jonathan Clymer

________________________________________________________________________

Date: Sun, 27 Jul 2003 20:01:01 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

John Romano writes,

First off I feel that we are further along with people using embedded

profiles than 5 years ago. I have customers and designers that are asking or

supplying profiles, there seems to be more people getting into it

everyday.

My experience is in some respects the opposite and in some respects not. In my classes, I find that fewer people even know what a profile is than was the case five years ago. However, photographers (who make up about 1/4 to 1/3 of my students) seem as a group to be *more* knowledgeable about the subject than they were then. Of the few non-photographers who know anything about the subject, most seem rather hostile, that is, they take an embedded profile to show lack of sophistication, and they have their settings set to ignore all profiles. And, in the third day of class, where the class members bring in their specific questions and concerns, the topic was never particularly popular but five years ago it would come up every now and then. Now, if I get such a question twice a year I'd be surprised.

And just one thing to add here, but how about sending your files without

the profile embedded, but supply the profile on the disk!

That way if you know how to use them your all set and if you dont no harm

done.

That makes sense for CMYK, but not IMHO for RGB. Tagging an RGB file is, unless you object to the modest amounts of extra file space, harmless. If you must pass an RGB file off to a stranger, it *should* be tagged, because you want the tag to be acted on. In CMYK it's a different story.

Dan Margulis

________________________________________________________________________

Date: Mon, 28 Jul 2003 08:01:09 -0400

From: John Romano

Subject: Re: Re: Delivering files in LAB

Jonathan

I would say its both new customers and some of our regulars, I have seen more interest in the subject over the past 2 to 3 years. From what I see the Bigger operations are adopting this technology faster than the little shops. Photographers sending Digital files asking for our CMYK profile or what our RGB workspace is, are we in an ICC workflow ? I get asked about it atleast once a week from sales or outside sources.

I was talking about CMYK tags being supplied on disk and I totally agree on RGBs having the profile embedded.

John

________________________________________________________________________

Date: Mon, 28 Jul 2003 14:57:31 +0100

From: Martin Orpen

Subject: Re: Delivering files in LAB

On Sat, 26 Jul 2003 23:03:33 EDT, Dan Margulis wrote:

The question of whether you can

seriously expect, now or at any time in the future, a stranger to honor an embedded

profile, isn't *going* away--it's GONE away, and it was gone by the end of the

century, when at least most service providers were aware there was some kind

of issue. Nowadays, the whole topic is obsolete; it's quite likely that if you

mention "embedded profiles" they won't even know what you're talking about.

Perhaps the UK market is totally different to the US then?

Here *embedding profiles* is more popular than it was last century - and far from obsolete.

In fact, some organisations are so misguided that they are refusing to accept CMYK or RGB without embedded profiles.

This text is from the current Association Of Photographers guidelines:

CMYK Files

? The CMYK files are to be separated using an ICC press specific profile

that is to be available from the AOP website, or can be sent to you on CD on

request.

RGB Files

? Must be supplied as digital RGB uncompressed TIFF files on a separate CD

with Adobe RGB (1998) colour space embedded.

For those who are interested in this *dead* subject, the AOP Digital Group Code of Practice can be downloaded as a PDF from here:

http://www.the-aop.org/pdfs/dig/DIGcode.pdf

The AOP's *misguidedness* in endorsing the *dead* topic of colour management also runs to a new web site at:

http://www.pro-file.org/

AOP members should be asking why the foremost organisation dedicated to protecting the rights of photographers is wasting time and money on this *dead* approach?

Maybe it actually works - or maybe I just can't admit that "my cause is lost"?

Martin Orpen

Idea Digital Imaging Ltd -- The Image Specialists

http://www.idea-digital.com/

________________________________________________________________________

Date: Mon, 28 Jul 2003 10:24:17 -0400

From: John Castronovo

Subject: Re: Re: Delivering files in LAB

From: Dan Margulis

That makes sense for CMYK, but not IMHO for RGB. Tagging an RGB file is,

unless you object to the modest amounts of extra file space, harmless. If you must

pass an RGB file off to a stranger, it *should* be tagged, because you want

the tag to be acted on. In CMYK it's a different story.

Why is that, Dan? I would think that it would be just as important to tag CMYK as RGB files. Can we safely assume that the intent of every CMYK sep is the same - the same press, same paper, even the same printing process? We're generally not given files that were made just for us, and it would be safer and a help to know if the sep were even made for offset printing or not let alone the specific flavor.

john castronovo

tech photo & imaging

________________________________________________________________________

Date: Mon, 28 Jul 2003 10:49:24 -0400

From: "Preston Earle"

Subject: Re: Re: Delivering files in LAB

Every time I think I'm getting my mind around using profiles in the real world, someone says something that confuses me. Dan Margulis wrote:

That (including a profile as a separate file) makes sense for CMYK, but not IMHO for RGB. Tagging an RGB file is, unless you object to the modest amounts of extra file space, harmless. If you must pass an RGB file off to a stranger, it *should* be tagged, because you want the tag to be acted on. In CMYK it's a different story." This makes sense to me.

Then "Martin Orpen" added:

"This text is from the current Association Of Photographers guidelines:

CMYK Files:

? The CMYK files are to be separated using an ICC press specific profile that

is to be available from the AOP website, or can be sent to you on CD on

request."

Now I'm confused. How can there be a "generic" CMYK profile (available for download from a website) when these profiles are press-specific (or at least print-condition-specific)? I was thinking that an untagged CMYK file gave color values for each pixel ready-to-print (or at least ready-to-plate). The ICC profile gave a way to tell what print conditions (dot gains, total ink, etc.) were assumed when that CMYK conversion was made, such that if a subsequent user needed to change for different print conditions, he/she would have a good idea of the starting point. Does this downloaded ICC profile become the assumed CMYK print conditions when the CMYK conversion is made, and if so, how is this any different from using any other defined profile and including that with the file? IOW, for folks who are really into profiles, the end user is going to have his/her press profiled and will convert incoming CMYK files to match those print conditions. Does it then matter what the original separation conditions were, as long as the final printer know what they were via the included profile? If the end-user is not profile aware, they will either strip the profile and end up with a file separated for whatever the original print conditions were, or they will honor the profile and end up with a file separated for the furnisher's assumption of print conditions. Either way, the file becomes the famous "mystery meat".

I'm thinking that the best procedure is to tag RGB files, as Dan suggests, but not to assume what a CMYK file looks like until I see the printer's "contract" proof of that file.

Preston Earle

________________________________________________________________________

Date: Mon, 28 Jul 2003 11:06:44 -0400

From: John Romano

Subject: Re: Re: Delivering files in LAB

Preston

You wouldnt want a generic profile that did not decribe the way the file was separated. I thought Martin was pointing us to links on specifications from the AOP web site.

You would want the profile that created the separation in order to get a good conversion to your conditions. Without a good source profile you are assuming the look of the image, with embedding or supplying the source you will help the next person who recieves this file if they need to convert to thier conditions.

Martin do you really feel colormanagement is a dead issue or did I mis read that ? I know many Photographers that have seen the benefits of profiling and would never go without again. I dont feel that its the end all be all but it certainly has its advantages.

John

________________________________________________________________________

Date: Mon, 28 Jul 2003 10:21:19 -0500

From: Bob Smith

Subject: Re: Re: Delivering files in LAB

On Monday, July 28, 2003, at 09:24 AM, john c. wrote:

Why is that, Dan? I would think that it would be just as important to tag

CMYK as RGB files.

Because you can very easily have numerous different profiles that describe the same CMYK conditions. All of them are valid. A conversion between them WILL alter the file possibly in ways the image creator/editor didn't intend. This same type of scenario doesn't happen in RGB. Even if you have two RGB profiles with different names describing identical conditions, an RGB to RGB conversion between them should result in no change to the file. Only one combination of R+B+G yields a specific color. There are likely several combos C+Y+M+K that can yield the same color. In SOME situations this causes different risks when embedding profiles. CMYK embedding has to be considered a bit differently than RGB where its pretty much harmless and very helpful.

Bob Smith

________________________________________________________________________

Date: Mon, 28 Jul 2003 10:50:24 -0700

From: David Barr

Subject: Re: Delivering Files in LAB?

A question for the experts:

LAB values depend on some chosen white point. The Photoshop manual does not make it clear which white point is used. As long as everyone uses Photoshop (and presuming that Adobe hasn't/won't change the white point), then LAB values cannot be misinterpreted. However, this info is critical when some other color engine is used. Can anybody tell me which white point Photoshop uses for LAB values? (and how you know this).

Many Thanks.

-Dave

________________________________________________________________________

Date: Mon, 28 Jul 2003 14:24:05 EDT

From: Dan Margulis

Subject: Re: Delivering Files in LAB

David Barr writes,

LAB values depend on some chosen white point. The Photoshop

manual does not make it clear which white point is used. As

long as everyone uses Photoshop (and presuming that Adobe

hasn't/won't change the white point), then LAB values cannot

be misinterpreted. However, this info is critical when some

other color engine is used. Can anybody tell me which white

point Photoshop uses for LAB values? (and how you know

this).

It's D50. Adobe documented it a couple of years ago but I don't know specifically where you would find the information.

Dan Margulis

________________________________________________________________________

Date: Mon, 28 Jul 2003 23:10:15 -0600

From: Chris Murphy

Subject: Re: Re: Delivering Files in LAB?

On Monday, July 28, 2003, at 11:50 AM, David Barr wrote:

However, this info is critical when some other color engine is used.

Can anybody tell me which white point Photoshop uses for LAB values?

All CMMs assume D50 LAB unless otherwise defined with a color space profile. Somewhere around here I have a LAB LH profile which was based on Linotype-Hell's proprietary version of LAB using a different scale as well as white point (D65) so you could convert native scans from their scanners for use in Photoshop.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

________________________________________________________________________

Date: Mon, 28 Jul 2003 23:12:02 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Martin Orpen writes,

In fact, some organisations are so misguided that they are refusing to

accept CMYK or RGB without embedded profiles.

It would be nearly impossible to find anything stronger in support of my position than the excerpts you posted.

First:

"CMYK Files. The CMYK files are to be separated using an ICC press specific

profile that is to be available from the AOP website, or can be sent to you

on CD on request."

This has nothing whatever to do with *embedded* profiles, the topic of this thread. Trying to use an appropriate separation method has been standard practice in the industry for nearly 20 years.

Second:

"RGB Files. Must be supplied as digital RGB uncompressed TIFF files on a

separate CD with Adobe RGB (1998) colour space embedded."

and the similar Adobe RGB-only requirement posted some time ago by Dennis Dunbar's analogous U.S. group:

"We do not accept sRGB or CMYK, leave all color management to the prepress

professional since they do this job best."

Both of these requirements defeat the entire purpose of embedding the profile, which is to allow the user maximum flexibility in the choice of workspaces while assuring accurate conversions down the line. They are about as anti-ICC workflow a stance as you can get.

The printer that you have been lambasting in recent weeks said, in essence, "We are either incapable of managing embedded profiles or disinterested in going to the effort, or both. You MUST, therefore, on pain of getting the job rejected or wrecked, give it to us in our own preferred RGB, which is (presumably) sRGB or something very like it."

This differentiates it sharply from the group you seem to approve of, which says, in essence, "We are either incapable of managing embedded profiles or disinterested in going to the effort, or both. You MUST, therefore, on pain of getting the job rejected or wrecked, give it to us in our own preferred RGB, which is Adobe RGB."

For anyone serious about this workflow, the RGB definition doesn't matter: the embedded profile will compensate. Similarly, if you insist on only accepting Adobe RGB files or only sRGB files, then the embedded profile is irrelevant.

The two groups cited above include many professionals who take color quality seriously, and are looking for ways to deal with real problems in the real world. Everybody in the industry owes them thanks for the work they do. Yet, more than five years since the introduction of this workflow, groups of such sophistication find dealing with embedded profiles so cumbersome that even *they* won't accept properly tagged RGB files from others. Anyone who thinks there's the slightest chance that mom-and-pop print shops will ever start doing so is only fooling themselves.

Dan Margulis

________________________________________________________________________

Date: Mon, 28 Jul 2003 23:12:46 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

John Castronovo writes,

Why is that, Dan? I would think that it would be just as important to tag

CMYK as RGB files.

This has been answered many times in the list, most recently at some length weeks ago by Stephen Marsh, and again today by Bob Smith. The basic reasons are:

*Assuming that we embed an accurate RGB profile, we would ordinarily want it to be honored; but assuming that we embed an accurate CMYK profile, we would ordinarily *not* want it honored;

*Converting RGB>RGB very rarely causes a significant quality loss, but converting CMYK>CMYK often does;

*There are no reports AFAIK of any bugginess or lack of reliability in RGB>RGB conversions, but there have been plenty of such reports about CMYK>CMYK conversions.

For these reasons, John Romano's suggestion makes sense.

Dan Margulis

________________________________________________________________________

Date: Tue, 29 Jul 2003 07:55:34 -0400

From: John Castronovo

Subject: Re: Re: Delivering files in LAB

Thanks for the reply, Dan. Our needs are outside of the norm, so indulge me if you will with another question.

A lot of our output is RGB, so we convert CMYK>RGB all the time. Don't we need to know a little more about the source settings in order to interpret the image? Are you saying that I can simply open any CMYK file in PhotoShop and have it display correctly, then hit the convert to RGB button to get the correct color?

These files can originate anywhere on the planet, and they pass through many hands. We can't always assume that they were separated for SWOP coated standards or even for a press. They arrive without a proof, and our client (usually an agency art director type) simply expects us to know how it looks. A profile helps us to do that.

How would you suggest that I handle the problem? What assumptions should we make about the nature of ALL these CMYK files before we convert them to RGB?

john castronovo

________________________________________________________________________

Date: Tue, 29 Jul 2003 09:00:16 -0400

From: Lee Clawson

Subject: Re: Re: Delivering files in LAB

Dan,

I don't think it's a waste of bandwidth. This stuff gets more rather then less complex. Many of the people I work with feel like Stephen Ray's last paragraph.

Lee

Dan Margulis writes...

As for the "endless debate", there is no one more disgusted than I am about

the continuing waste of bandwidth in this group by those who can't bear to

admit that any part of their cause is lost.

Stephen Ray writes...

The whole idea of color management via ICC profiles is ridiculously

complicated. All the software is still stupid and perplexing. Dialog

boxes, options, tools, etc., change with every new version which proves the

developers don't have it figured out. (But who else does?) Is sRGB really so

small? What color in our natural world is beyond reach of sRGB?

________________________________________________________________________

Date: Tue, 29 Jul 2003 10:20:06 -0400

From: "Dave King"

Subject: Re: Delivering files in LAB

I was at a party the other day where I heard a photo editor for a major magazine say, "when shooting digital you HAVE to deliver a proof or we have no idea of color". I always deliver proofs, but it was interesting to note he apparently had no idea calibrated monitors and profiles even exist. I politely informed him of the Sony Artisan and tagged AdobeRGB.

Universal standards and calibration, why again is this evil? Aren't we going toward a point where presses are not color managed on the fly? These dialogue boxes aren't THAT complex really, are they?

Dave King

________________________________________________________________________

Date: Tue, 29 Jul 2003 15:06:28 -0000

From: Stephen Marsh

Subject: Re: Delivering files in LAB

A lot of our output is RGB, so we convert CMYK>RGB all the time. Don't we

need to know a little more about the source settings in order to interpret

the image? Are you saying that I can simply open any CMYK file in PhotoShop

and have it display correctly, then hit the convert to RGB button to get the

correct color?

John, I can't speak for Dan, but I would say that no is the answer here. <g>

One needs to know the inkset/stock/dot gain to convert out as the original separation intended.

There has to be some source for the conversion, be it active or passive (assumed).

But it then depends on whether the image had post separation edits applied, and if so did these use a profile as reference (was it the sep profile or another profile aim-point) - or were the aim-points something other than an ICC profile, which can then make the choice of profile to assign/presume even harder.

These files can originate anywhere on the planet, and they pass through many

hands. We can't always assume that they were separated for SWOP coated

standards or even for a press. They arrive without a proof, and our client

(usually an agency art director type) simply expects us to know how it

looks. A profile helps us to do that.

How would you suggest that I handle the problem? What assumptions should we

make about the nature of ALL these CMYK files before we convert them to RGB?

This is not the debate, but as you say you would like to introduce a new point for consideration.

Dan was commenting on tagging CMYK, where some of us dinosaurs still want our specified values to be honoured - and do not want a further conversion down the line changing those values.

If CMYK was supplied for conditions that it was not originally separated for, then having a profile supplied with the file (tagged or separate) would be invaluable - I for one do not argue that point.

The point I do argue - is if/when a further conversion from final supplied CMYK is reqd/wanted for film/plate data.

As has been noted, there are different work-flows out there - so where one user may hardly ever convert CMYK data, in another setting this may not be taboo and it is a good thing.

Stephen Marsh.

________________________________________________________________________

Date: Tue, 29 Jul 2003 09:34:33 -0600

From: Chris Murphy

Subject: Re: Re: Delivering files in LAB

On Monday, July 28, 2003, at 09:12 PM, Dan Margulis wrote:

*Assuming that we embed an accurate RGB profile, we would ordinarily want it

to be honored; but assuming that we embed an accurate CMYK profile, we would

ordinarily *not* want it honored;

The problem isn't with the honoring of the profile. The problem is with automatic conversions of the file without understanding the consequences of such conversion. That is more of a workflow problem than it is a color management problem. That Adobe has seen it fit to call such behavior a "color management policy" directs one to blame color management, but it's really an implementation problem where they've given users automation tools without enough background on how much such automation can hurt.

*Converting RGB>RGB very rarely causes a significant quality loss, but

converting CMYK>CMYK often does;

It depends on how they are converted, and the destination. Yes with regular output device profiles this is a problem if the to be converted content has specific/custom channel behavior (in any of the channels) since little of this is preserved during the conversion.

DeviceLinks offer a workaround (preserve color appearance, but also preserve channel integrity as well) but thus far that too is considered an automation solution for the time being. Frankly what's needed is smarter color management.

Non-press destinations are so completely different in their behavior that the conversion of a CMYK file destined for press but will actually be printed on a large format ink jet will work a lot better being converted to preserve color appearance even sacrificing channel integrity.

*There are no reports AFAIK of any bugginess or lack of reliability in

RGB>RGB conversions, but there have been plenty of such reports about

CMYK>CMYK conversions.

Such as?

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

________________________________________________________________________

Date: Tue, 29 Jul 2003 19:30:42 +0100

From: Martin Orpen

Subject: Re: Delivering files in LAB

on Mon, 28 Jul 2003 23:12:02 EDT, Dan Margulis wrote:

It would be nearly impossible to find anything stronger in support of my

position than the excerpts you posted.

Only if you didn't read their documentation.

Their guidelines state specifically that both RGB and CMYK images must be delivered "with their profiles". I guess you could argue that they might have meant on a separate disk - but I doubt it.

Both of these requirements defeat the entire purpose of embedding the

profile, which is to allow the user maximum flexibility in the choice of

workspaces while assuring accurate conversions down the line.

They are about as anti-ICC

workflow a stance as you can get.

So that's why the AOP have called their web site www.pro-file.org - because they are anti-ICC profiles!

The printer that you have been lambasting in recent weeks said, in essence,

"We are either incapable of managing embedded profiles or disinterested in

going to the effort, or both. You MUST, therefore, on pain of getting the job

rejected or wrecked, give it to us in our own preferred RGB, which is (presumably)

sRGB or something very like it."

Come off it Dan. The printer I lambasted took an RGB PSD file from a damaged system, made a crap separation from it and printed it without getting a proof approved by the client.

He made no declaration about his preferred colour policies - you've just made that bit up.

The fact that I said that he deserved a greater proportion of the blame than the photographer seems to have gotten you riled up.

This differentiates it sharply from the group you seem to approve of, which

says, in essence, "We are either incapable of managing embedded profiles or

disinterested in going to the effort, or both. You MUST, therefore, on pain of

getting the job rejected or wrecked, give it to us in our own preferred RGB,

which is Adobe RGB."

Err, the group that I approve of is the one that uses transparent colour management - all images correctly TAGGED with the appropriate profiles. For I am your calibrationist nemesis :-)

I never leave the house without a freshly calibrated DTP41 in my back pocket and never tire of showing photographers how great their untagged sRGB images look when I accidentally assign the Kodak Interchange RGB profile - so much more colourful...

For anyone serious about this workflow, the RGB definition doesn't matter:

the embedded profile will compensate. Similarly, if you insist on only accepting

Adobe RGB files or only sRGB files, then the embedded profile is irrelevant.

I disagree. How am I to know if the client has messed up and sent me some untagged ColorMatch or WideGamut RGB data? I'm not interested in getting involved in arguments, or making money from needless rounds of proofing - I just want to get the best reproduction from the supplied RGB and get the job through our system.

The situation seems simple to me:

The values in an RGB image have no real meaning unless they are given context in the form of a profile - or an operator chooses to interpret them in a certain way.

The client has a choice; supply a profile to give the data meaning or pay an operator 200 quid an hour (plus proofing) to do their interpretation.

With a small number of images per day and a limited number of devices and working spaces then the second option is OK... for a while. But as the number of images and/or devices multiplies then this method of working (and it's closed-loop alternative) are a complete waste of everyone's time and money.

Why spend ten minutes correcting a scan when a profile can correct a couple of hundred colour points in a second?

More important than that is the temptation that people have to screw their images to make them look good on their own uncalibrated proofer. Not only do they waste hours getting the colour right - they destroy the image as well!

A simple RGB profile would save time and prevent a disaster. Colour correct

in around a second and the original image undamaged.

The two groups cited above include many professionals who take color quality

seriously, and are looking for ways to deal with real problems in the

real world. Everybody in the industry owes them thanks for the work they do.

Yet, more than five years since the introduction of this workflow, groups of such

sophistication find dealing with embedded profiles so cumbersome that even

*they* won't accept properly tagged RGB files from others. Anyone who thinks

there's the slightest chance that mom-and-pop print shops will ever start

doing so is only fooling themselves.

You've extrapolated too far. My offer of meeting you at Drupa so that you can introduce me to all of these industry professionals who reject ICC workflows is still open. I personally haven't met *one* manufacturer of scanners, RIPs, proofers or presses that shares your point of view.

Martin Orpen

Idea Digital Imaging Ltd -- The Image Specialists

http://www.idea-digital.com

________________________________________________________________________

Date: Tue, 29 Jul 2003 16:31:06 -0700

From: John Denniston

Subject: Re: Re: Delivering files in LAB

At the risk of extending this debate even further I offer the following observation.

The newspaper I recently retired from had close to a 100 people using photoshop spread over 5 floors and 8 departments. It was impossible to get all of them using the same color space and ink limits.

The advertising department often reverted to a default 300% ink limit on Srgb and the scanning department switched from Colormatch to Adobe RGB to Srgb from one day to the next with no explanation. Another group preferred PS3 using old monitors calibrated every 6 months or so with Adobe Gamma and a veteran artist sitting not 20 feet from me insisted on making her own separations with PS6 set up for Web colors on an uncalibrated monitor.

Our pref's were set after thousands of dollars in press tests but most of the people involved in prepress were determined to ignore them.

In my department I set up an action to semi automatically process each picture from RGB to CMYK. The first thing the action did was set the color pref's and the ink limits. Without this, at least one of the pref's on one of the computers would be changed during the day.

Despite this lack of management we got 200 or so pictures in the paper every day and most of them looked pretty good.

I would like profiles to work because I think it is an elegant solution to a difficult problem but if it is almost impossible to get a color management system to work within a large organization where there is some leverage over the staff I don't see how it will ever be possible to make it work in the real world.

Regards, John

John Denniston

www.dennistonphoto.com

________________________________________________________________________

Date: Wed, 30 Jul 2003 07:28:50 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

John Castronovo writes,

A lot of our output is RGB, so we convert CMYK>RGB all the time.

For what purpose? To hand out an RGB file to somebody, or to print to some device that requires RGB input (and therefore is reconverting it right back to CMY+)? And if it's to some output device, is the purpose to be a proof, or to look as good as possible?

Don't we need to know a little more about the source settings in order

to interpret the image?

No. CMYK doesn't have the potential that RGB does. If somebody gives us an RGB file and tells us they want to match it in CMYK, our job is basically to hide the damage as best as possible and not let him realize that the inevitable reduction in contrast and color gamut has occurred. There isn't any one best way of doing that. Having a profile attached to the RGB file is occasionally helpful in the process and I have always recommended that people who must pass RGB files to others attach tags.

CMYK to RGB is a different story. There, we are *not* trying to match the CMYK--we're trying to make it look *better* than the CMYK.

Are you saying that I can simply open any CMYK file in PhotoShop

and have it display correctly, then hit the convert to RGB button to get

the correct color?

No.

These files can originate anywhere on the planet, and they pass through

many hands. We can't always assume that they were separated for SWOP coated standards or even for a press. They arrive without a proof, and our client

(usually an agency art director type) simply expects us to know how it

looks. A profile helps us to do that.

If it's passed through many hands the chances of any profile having any validity at all are negligible. Even if it's valid, somebody may be wanting you not to match its appearance, but the way it looked when it printed on a press in Hong Kong that didn't match any proof. Further, if you look in the list's archives, you'll find a thread where a printer used an embedded CMYK profile for such a conversion, it turned out the profile was incorrect (it was for a laser printer as I recall) and the job ended up as a disaster. The list consensus, with which I concur, is that the printer had to eat the cost of the job, as the use of a CMYK profile requires a specific reconfirmation from the client.

So, the client has to give you something: a proof, a verbal description, an instruction to use a particular setting, or just "do the best you can". In any of these scenarios an embedded profile is not useful.

How would you suggest that I handle the problem? What assumptions should

we make about the nature of ALL these CMYK files before we convert them to

RGB?

You assume exactly what color personnel have assumed for the last 15 years: unless stated otherwise, it's SWOP. You assign an appropriate profile to it; if your people are good at color correction you convert it to RGB without black point compensation; otherwise you turn it on.

You assume that once you get to RGB purer blues and greens will leave a lot to be desired, pastel colors will be nonexistent, and shadow detail will suck, because all these defects are characteristic of CMYK files and no method of conversion corrects for them. So, if you want credible RGBs, you assume that a modest amount of intervention is necessary. Those who have done a lot of these conversions generally have actions involving the use of LAB, which can attack many of these issues in an automated way.

Dan Margulis

________________________________________________________________________

Date: Wed, 30 Jul 2003 07:45:20 -0400

From: John Romano

Subject: Re: Re: Delivering files in LAB

John Denniston:

Its called Managment, you would have needed to set up everyones machines on the same Versions and enforce it through the Managment team. Our prepress is around 35 people over a range of different shifts, when we started with profiles we set every machine up with the same stuff. In Photoshop you can save your color settings, we had a different set up for web and sheetfed.

All jobs are marked for what press so when an operator goes to work on them they load the right colorsettings.

The real key to making this work is by setting up Photoshop to warn for profile mismatches and to "Embedd " the profile. It starts in scanning where they convert to the correct colorspace and everyone down the line will know if the right profile was used.

Also training your prepress department will help everyone understand why they need to do things using the same set ups.

John

________________________________________________________________________

Date: Wed, 30 Jul 2003 07:50:55 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Lee Clawson writes,

Dan,

I don't think it's a waste of bandwidth. This stuff gets more rather then

less complex. Many of the people I work with feel like Stephen Ray's last

paragraph.

I agree with it myself, except that where he says, "The whole idea of color management via ICC profiles is ridiculously complicated," I would say "The whole idea of color management via embedded ICC profiles is fairly simple but it was needlessly made ridiculously complicated." I certainly agree wholeheartedly with him about the stupidity of change for the sake of change and upgrades for the sake of upgrades.

The question about how best to use the tools that are provided, and how to keep pace with software changes is definitely not a waste of bandwidth and I regret any implication otherwise. What *is* not just a waste of bandwidth, but an invitation to ruined jobs, IMHO, is the repeated ridiculous assertion that we color elitists are not the tiny minority that we are, and that there is some great silent majority out there who actually has any idea what all this color management stuff is about.

As to Stephen's question about sRGB, no, it isn't missing any colors that are common in the real world.

Dan Margulis

________________________________________________________________________

Date: Wed, 30 Jul 2003 09:13:20 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Chris Murphy writes,

The problem isn't with the honoring of the profile. The problem is with

automatic conversions of the file without understanding the

consequences of such conversion. That is more of a workflow problem

than it is a color management problem. That Adobe has seen it fit to

call such behavior a "color management policy" directs one to blame

color management, but it's really an implementation problem where

they've given users automation tools without enough background on how

much such automation can hurt.

Agreed on all counts, particularly that it is an invitation to the user to blame "color management", which is not conducive to future improvements. This is *not* a color management problem, any more than the factual question as to whether many printers ignore profiles is a color management problem. It is a problem of color management being inappropriately applied or inappropriately withheld.

*There are no reports AFAIK of any bugginess or lack of reliability in

RGB>RGB conversions, but there have been plenty of such reports about

CMYK>CMYK conversions.

Such as?

There have been at least two such reports on this list from other people (i.e. CMYK>CMYK produces insane results) and I've seen it myself several times, always involving third-party profiles.

Even if you limit yourself to Apple- and Adobe-supplied CMYK profiles and going from a smaller to a larger space, there are problems. At random, I just opened a normal skintone-neutral background image in Generic CMYK, converted to US Sheetfed Coated, and back to Generic CMYK. There was a pronounced blue shift. As you know, if you go RGB>LAB>RGB, or even sRGB>Adobe RGB>sRGB, there's no visible difference.

Dan Margulis

________________________________________________________________________

Date: Wed, 30 Jul 2003 10:43:13 -0400

From: Ric Cohn

Subject: Re: Re: Delivering files in LAB

On Tuesday, July 29, 2003, at 10:20 AM, Dave King wrote:

I was at a party the other day where I heard a photo editor for a major

magazine say, "when shooting digital you HAVE to deliver a proof or we

have no idea of color".

I was also feeling that this whole "embedded profiles" issue was wasted bandwidth, but finally I think I've gotten to my personal crux of the problem and am grateful to those on the list who keep at it. However, the answer I've come to is not the answer I expected.

I think the above anecdote is a most eloquent explanation of why Embedded Profiles are such a problem. Setting up and understanding a color calibrated workflow is rather complicated. Photographers and some pre-press people may need to learn it (I know I do), but the people that pay the bills can't be trusted to use it. Frankly, for a busy art director or editor or art buyer, etc. this is such a miniscule part of their job that if it takes more than one minute to explain and understand they are not going to take the time. And frankly (sorry) rightly so. I believe in "idiot proofing" for my clients. If I make them look bad I lose a client. Then, once the "Color Management Chain" is broken by anyone you have a potential disaster!

Maybe Color Management can be made so easy and transparent that everyone in the chain will use it correctly because it is impossible to mess up. Until that time I'd prefer to either A. Deliver my files in a foolproof format, B. Be told what format they want the files in or, C. Have extensive discussions with a trusted vendor or client regarding what is being supplied.

Ric Cohn

http://www.riccohn.com

________________________________________________________________________

Date: Wed, 30 Jul 2003 15:25:27 -0000

From: John Luke

Subject: Re: Delivering files in LAB

I was at a party the other day where I heard a photo editor for a major

magazine say, "when shooting digital you HAVE to deliver a proof

or we have no idea of color".

Perhaps he's never heard of the DISC standards being set-up by Hearst, Time Warner, Conde Nast, Quad, et al.

http://www.disc-info.org/

Setting up and understanding a

color calibrated workflow is rather complicated.

Not true. It's complicated because people do not want to learn what they must.

Photographers and some

pre-press people may need to learn it (I know I do), but the people

that pay the bills can't be trusted to use it. Frankly, for a busy art

director or editor or art buyer, etc. this is such a miniscule part of

their job that if it takes more than one minute to explain and

understand they are not going to take the time.

Then they have no business messing with files.

Then, once the "Color Management Chain"

is broken by anyone you have a potential disaster!

True. And those who brake that chain should be held liable and accountable.

Maybe Color Management can be made so easy and transparent that

everyone in the chain will use it correctly because it is impossible to

mess up. Until that time I'd prefer to either A. Deliver my files in a

foolproof format, B. Be told what format they want the files in or, C.

Have extensive discussions with a trusted vendor or client regarding

what is being supplied.

Even delivery in chrome had risks. I've seen people stuff them into envelopes without sleeves, fold them, you name it. There is no foolproof way, only educated professionals such as in example C.

John Luke

APA/ASMP

________________________________________________________________________

Date: Wed, 30 Jul 2003 15:36:59 -0000

From: John Luke

Subject: Re: Delivering files in LAB

Is sRGB really so

small? What color in our natural world is beyond reach of sRGB?

sRGB, and Adobe RGB are 2.2 gamma spaces. ColorMatchRGB is a 1.8 gamma space. If you think you've got one, and yor working in the other, watch out.

If you are working in a 2.2 space such as sRGB or AdobeRGB (and I'm not talking about your monitors individual gamma setting) and you open an untagged or discard the profile of a 1.8 gamma file, it will look too dark, amongst other things.

If you are working in a 1.8 space, such as ColormatchRGB and you open an untagged or discarde profile of a 2.2 gamma file, it will look painfully washed out, amongst other things.

John Luke

APA/ASMP

________________________________________________________________________

Date: Wed, 30 Jul 2003 11:10:12 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Martin Orpen writes,

Their guidelines state specifically that both RGB and CMYK images must be

delivered "with their profiles".

Of which, only one kind of profile is permitted!!!!

So that's why the AOP have called their web site www.pro-file.org - because

they are anti-ICC profiles!

One can only imagine how this group would fare as a car rental company.

"We support completely a profiled workflow, and the concept of device-independent color, provided you limit yourself to the single set of profiles we endorse."

Translation: "Our state of the art system permits us to rent you whatever car suits your fancy, whatever make or model, whatever color, provided that it's a red 2002 Ford Focus."

"Now that we don't accept anything other than our preset workspace, we require that you embed a profile saying that you are using our preset workspace."

Translation: "Granted that we only have red 2002 Ford Focuses available, we will not rent one to you unless you sign, in front of a notary public, a separate form requesting that you specifically get a red 2002 Ford Focus and no other brand, color, or model."

"To show our support for the concept that we have just so completely trashed, we will give our web site a pro-color management name"

Translation: "To show our support for our transatlantic allies, we offer a 10% discount for anyone who can prove they are now living in Great Britain. However, all residents of the United Kingdom have to pay a 50% surcharge."

Come off it Dan. The printer I lambasted took an RGB PSD file from a damaged

system, made a crap separation from it and printed it without getting a

proof approved by the client.

The printer and the AOP are doing exactly the same thing, in different ways. They completely weasel out of any responsibility for color management AND FOB IT ALL OFF ON THE USER.

The theory behind this workflow is that it has to be so transparent and so easy that no great sophistication on the part of the user is required. That is the reason, however fatuous, behind the Photoshop decision to embed profiles by default. Unless you make a mistake, the system will always produce aproperly tagged document, even for those who have no idea what the purpose of a tag is. If a conversion is necessary, someone like me, or John Castronovo, or John Romano, or Andrew Rodney, will take care of it for you. So goes the theory.

Both the printer and the AOP (and Dennis Dunbar's analogous group) stand this on its head. Because they themselves are afraid to learn how to do conversions, they force the user to become an expert in color management, which is the exact opposite of what real supporters of this workflow want.

Anyone who works with this particular printer has to be sophisticated enough to realize that most printers don't understand or aren't interested in this topic and therefore can't be relied upon to honor profiles without guidance. Anyone who works with the AOP and who doesn't have Adobe RGB as their workspace has to be sophisticated enough to know the difference between Image: Mode>Assign Profile and Image: Mode>Convert to Profile.

I am very confident that more people are aware that printers are hostile to embedded profiles than know how to use those two commands. I am also very confident that the AOP has many more members who do *not* use Adobe RGB than the printer has clients who show up with embedded profiles that are disastrous if ignored. Consequently, although they're clearly two peas in a pod, I believe that the AOP and Dennis's group are greater enemies of the ICC workflow than this ignorant printer is.

You are so prejudiced by the fact that you yourself find it easy to accept tagged files that you refuse to accept how atypical a practitioner you are. Yes, everybody mentioned above has no problem with tagged files, but we are all top predators. The AOP and Dennis's group may not be quite at that exalted level, but they would have to be rated as well above average in sophistication. And yet, they cannot, or will not, accept a properly tagged file.

The quaint idea that one can simply assume that a stranger would or should be able to handle a properly tagged file has been obsolete for five years. One cannot ask for a more decisive example of why this is so.

Dan Margulis

________________________________________________________________________

Date: Thu, 31 Jul 2003 03:14:50 EDT

From: Stephen Ray

Subject: Re: Re: Delivering files in LAB

If it's of any consequence, (of course it is) you may notice in Photoshop 7 when accessing the Pantone Solid Coated library via the color picker, it will display LAB values instead of CMYK values as did Photoshop 6 and earlier. Many users would access this palette to find some CMYK values or insight but now they just run away to lunch when they see LAB.

They're firmly rooted in CMYK, sort-of wrapped their heads around RGB and can feel comfortable about making files lighter or darker without a black channel, and then bammm!, start opening legacy files saved in LAB from older versions of Photoshop and notice the LAB values are very different now than then. It turns out not to be the cornerstone once thought.

It's not the end of the world. It's exactly the same as Pantone specifying new values in their new libraries and waiting for your favorite raster software to implement that value list which your favorite page layout software has already used for 3 years.

Wouldn't you suppose companies so involved with colorsync be more synchronized and timely?, and why is it that my trial download of Pagemaker 7 changed my splash screen of InDesign 2.0 to "Licensed to Pagemaker Tryout #######..."

The answere might be that PageMaker is a little too closely synced with InDesign.

-Stephen Ray

________________________________________________________________________

Date: Thu, 31 Jul 2003 03:20:29 -0400

From: John Castronovo

Subject: Re: Re: Delivering files in LAB

Dan,

I hate to continue this "waste of bandwidth" as you call it, but I felt obliged to respond to a few of your points (below) basing my replies on my own experience. There's no need to respond as I agree that we've beat this one to death this time. I think we're a little closer than a year ago, and that's good.

I'm not trying to be contentious as much as I'm trying to understand why you have so many problems with this issue. I'll be the first to admit that color management in PS5 was a disaster and confusing, but this stuff isn't rocket science any more. Compared to much of the stuff you teach, it's elementary. Yet you appear to believe that it's so difficult to implement correctly that only color scientists can be trusted to make it work - and even then.! Well I am reporting that the majority of color problems with customers' files in our shop these days originate from people who don't use color management and who don't embed profiles. This is contrary to what your experience is, and that's why you need to hear it from my perspective. You don't get into shops like mine, so I have to cut you a break, but people who follow your color management advice make my life miserable.

For what purpose? To hand out an RGB file to somebody, or to print to some

device that requires RGB input (and therefore is reconverting it right back to

CMY+)? And if it's to some output device, is the purpose to be a proof, or to

look as good as possible?

It makes no difference why I need to convert to RGB, but to answer your other question, sometimes I have the liberty to make it look as good as possible and sometimes I have to match a contract proof that I don't even have, but will certainly surface later. The problem is that I need to know what the CMYK file is supposed to look like and I can't tell without the proof but a correct profile is a great help - same as in RGB.

CMYK to RGB is a different story. There, we are *not* trying to match the

CMYK--we're trying to make it look *better* than the CMYK.

Not always, and even if you were, how can you do that if you don't even know what the subject is? Sometimes it's very abstract - blue people on a red background or the tan box. My idea of better also probably isn't the art director's. If the job were high budget, sure I'd have him over for coffee and we'd go over it together with changes and proofs. I'm sorry to report that those days are mostly over in today's economy. Now we have him confirm over the phone that it looks decent with SWOP coated v.2 so we'll assign that, convert it, tweak it a little, a little nip and tuck and then go for the final.

If it's passed through many hands the chances of any profile having any

validity at all are negligible.

Why is that? It seems to me that the reverse is true. If there's a chance that the profile is correct, I'll take it and be the judge of whether or not we use it. Without the profile, the thing has just as much chance to be corrupt with fewer ways to tell.

Even if it's valid, somebody may be wanting you not

to match its appearance, but the way it looked when it printed on a press in

Hong Kong that didn't match any proof.

If the guy in Hong Kong attached his profile, it would be close. Besides, without a profile you're no better off here.

Further, if you look in the list's

archives, you'll find a thread where a printer used an embedded CMYK profile for

such a conversion, it turned out the profile was incorrect (it was for a laser

printer as I recall) and the job ended up as a disaster.

This proves my point. If the numbers in the file were meant for a laser printer, the correct profile would've yielded the correct interpretation. The problem here was that the laser printer profile wasn't embedded when the sep was made and some idiot assigned the wrong profile to it. If it had a profile, this wouldn't have happened. The same disaster would've happened if the file arrived without a profile and someone assumed that it was SWOP. If the picture were an abstract, no one would know until the client screamed.

You assume exactly what color personnel have assumed for the last 15 years:

unless stated otherwise, it's SWOP. You assign an appropriate profile to it . . .

Again, how can you tell what's appropriate? Which flavor of SWOP? If I knew that you were preparing my files, little of this would be a question, but the reality is that the world is shrinking and people aren't getting any smarter.

We just got a CMYK file from France that came over the T1, and thank GOD it had an embedded profile. It was unique, and we never would've guessed that the photo was the color it was by assigning anything out of PhotoShop! We checked a few just to make sure that nothing looked better. Any flavor of SWOP was a mile off. There was no proof and even our client didn't know what it was supposed to look like. Even if we had a proof, this was so far off base that taking it from SWOP to what it was supposed to be would've taken an hour of corrections. Using their profile, as it turned out, it was right on. How else can you do that?

john castronovo

________________________________________________________________________

Date: Thu, 31 Jul 2003 00:56:04 -0700

From: Dennis Dunbar

Subject: Re: Delivering files in LAB

This debate has been interesting. One of the entertaining aspects has been watching several posters twist words and meanings around to fit their own ideas. A few seem genuinely interested in making a legitimate point, but others just seem to only listen to their own words.

The first thing I'd like to say is that again this all uinderlines the need for communication. The pros and cons of this discussion all change when the parties involved actually talk with each other. Without communication we just don't know what the other person did, or what they want.

This thread started because I asked if delivering files in LAB seemed a safer way to deliver files when you cannot communicate with the others down the workflow. It seems as if the answer is no, but there is no safe way at all. Let's see, if I don't know the press conditions I cannot accurately do a CMYK conversion. If I choose one CMYK space and embed the profile I used so the others will know what space I used I stand the risk of derision and am assured of disaster due to unwanted conversions. If I supply RGB in anything other than sRGB or ColorMatch again I risk derision and disaster. But if I deliver in RGB at all I still risk disaster.

So bottom line seems to be no matter what I do, if I cannot speak with the others in the workflow I'm risking disaster and derision. Sounds like a good workflow to me, but then at times so does getting hit with a hammer, ;-).

Isn't there some way to ensure our intents are understood when we don't know who else is going to work on this image? Is it that tough to figure out how to develop some lines of communication?

On another point, it seems that Dan, and others misunderstood the intents of the guidelines posted on www.disc-info.org. These are guidelines, not rules to get hung by. If a photographer submits a file in sRGB and embeds the profile I really doubt his editor at the magazine is going to reject the job. Likewise if some other colorspace is used. The guidelines are meant to create some commonality, not enforce a one size fits all regulation. What the pubs were faced with was files coming in with and without profiles, in RGB and CMYK of every flavor. And the biggest problem was that with thousands of files per week per pub all too often if it was CMYK the seps were bad and the color needed correction. Or if it was RGB the wrong profile would be embedded, or none at all leaving them to guess what it was supposed to be.

This group is hardly anti profile. And to say their guidelines are proof that they are anti ICC profile is to narrowly interpret things to fit your own view point.

We're not gonna further the debate, and the state of the industry by not listening or communicating. There are many good points being made in this thread, but I fear they will be lost in the static.

Dennis Dunbar

________________________________________________________________________

Date: Thu, 31 Jul 2003 08:42:26 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Ric writes,

Maybe Color Management can be made so easy and transparent that

everyone in the chain will use it correctly because it is impossible to

mess up. Until that time I'd prefer to either A. Deliver my files in a

foolproof format, B. Be told what format they want the files in or, C.

Have extensive discussions with a trusted vendor or client regarding

what is being supplied.

Great God and little fishes! Has common sense finally prevailed in this group?

Dan Margulis

________________________________________________________________________

Date: Thu, 31 Jul 2003 09:59:12 -0500

From: Gary Roushkolb

Subject: Re: Re: Delivering files in LAB

Dan What is your recommendation for format for a Printer to ask an agency for? We will be having a meeting with one of our major clients in the near future to solve just such a problem. I'm leaning to LAB

Thanks gary Roushkolb Donlevy Litho

________________________________________________________________________

Date: Thu, 31 Jul 2003 23:32:50 +0100

From: Martin Orpen

Subject: Re: Delivering files in LAB

On Wed, 30 Jul 2003 11:10:12 EDT, Dan Margulis wrote:

"We support completely a profiled workflow, and the concept of

device-independent color, provided you limit yourself to the single set of

profiles we endorse."

Translation: "Our state of the art system permits us to rent you whatever

car suits your fancy, whatever make or model, whatever color, provided that

it's a red 2002 Ford Focus."

This hyperbole isn't really getting you anywhere and is confusing two issues:

1. The AOP are actively investigating colour management and actively producing a set of guidelines that will hopefully be as helpful to their members as the other professional guidelines that they have produced on copyright etc.

2. The AOP are producing a catalogue for their members and have asked that files be supplied in Adobe(1998) if RGB or separated with a custom profile that they have made available on their web site.

They are NOT insisting that ALL work is supplied in one of two colour spaces - just the stuff for their own catalogue.

The printer and the AOP are doing exactly the same thing, in different ways.

They completely weasel out of any responsibility for color management AND

FOB IT ALL OFF ON THE USER.

You are wrong again. The AOP appear to be educating themselves and their members on an increasingly big problem for photographers. They are running courses to train members and non-members about colour management. They appear to me to be taking on some responsibility here.

The printer - whom you must be related to to offer such unmitigated support - was completely irresponsible. However, he can rely on jaded industry professionals to support his stance of "I own the final device, so you accept what you're given" and the ignorance of customers who are too ignorant to argue the case.

The theory behind this workflow is that it has to be so transparent and so

easy that no great sophistication on the part of the user is required. That is

the reason, however fatuous, behind the Photoshop decision to embed profiles

by default. Unless you make a mistake, the system will always produce a properly

tagged document, even for those who have no idea what the purpose of a tag

is. If a conversion is necessary, someone like me, or John Castronovo, or John

Romano, or Andrew Rodney, will take care of it for you. So goes the theory.

Both the printer and the AOP (and Dennis Dunbar's analogous group) stand this

on its head. Because they themselves are afraid to learn how to do

conversions, they force the user to become an expert in color management,

which is the exact opposite of what real supporters of this workflow want.

You're putting up more straw men. Who is putting forward the theory that colour management is *easy* or that it can be done with *no great sophistication*? Certainly nobody in this forum.

And if the photographers are afraid to take this stuff on board, I don't blame them - why should they? The problem they have is that there is nobody else to do this stuff for them.

Their client loves the situation - commission a photographer, a copywriter with a copy of XPress and a printer. That's all you need now for a brochure. Tell the photographer that he has to supply digital files (because it's a tough market and they'll do it for free) and get the printer to run the job without wasting money one expensive proofs.

If the job looks crap it's pretty easy to start an argument between the printer and the photographer and then walk a way with an even fatter discount on the project.

Anyone who works with this particular printer has to be sophisticated enough

to realize that most printers don't understand or aren't interested in this

topic and therefore can't be relied upon to honor profiles without guidance.

Anyone who works with the AOP and who doesn't have Adobe RGB as their

workspace has to be sophisticated enough to know the difference between Image:

Mode>Assign Profile and Image: Mode>Convert to Profile.

I am very confident that more people are aware that printers are hostile to

embedded profiles than know how to use those two commands. I am also very

confident that the AOP has many more members who do *not* use Adobe RGB than

the printer has clients who show up with embedded profiles that are disastrous if

ignored. Consequently, although they're clearly two peas in a pod, I believe

that the AOP and Dennis's group are greater enemies of the ICC workflow than

this ignorant printer is.

*Interesting* logic. I'm afraid I cannot follow it.

Transparent workflows require changes to people's working practices.

Photographers are being compelled to change and are embracing new working methods - despite some obvious reluctance. Their involvement will help improve the technology for all of us, so I see it as beneficial.

The printer, on the other hand, need do nothing. That's the primary benefit of owning the destination device. If your stuff looks bad then "screw you it must be your problem".

You are so prejudiced by the fact that you yourself find it easy to accept

tagged files that you refuse to accept how atypical a practitioner you are.

Yes, everybody mentioned above has no problem with tagged files, but we are all

top predators. The AOP and Dennis's group may not be quite at that exalted

level, but they would have to be rated as well above average in sophistication. And

yet, they cannot, or will not, accept a properly tagged file.

The quaint idea that one can simply assume that a stranger would or should be

able to handle a properly tagged file has been obsolete for five years. One

cannot ask for a more decisive example of why this is so.

I get a call from a client today. "I've got a big problem with some work that you did last month, we've got some proofs back from the US and the images are horrible".

Now, it's news to me that the images had been printed in the US, so I ask if the UK printer had any problems. "No, the stuff looked great" he replies. I get him to send some samples over. UK stuff looks good, US stuff looks very dark and colour shifted.

He sends me an email from the US printer. His position is that it "can't be his problem" because he "just output the supplied files".

This guy has taken CMYK data that was destined for a high quality UK press with single digit gain and "just output the supplied files" on a press with treble the amount of gain and using inks that aren't the same colour.

The file *was* tagged, but what does that matter? These guys don't give a toss - unless they can use the tag as a reason for the job printing badly. If this was the *mom & pop shop* that you mentioned in your previous post then I'd cut them some slack. But these guys are big players. The job was an album sleeve for a big artist on the world's largest record label.

Their scam - doing as little as possible, making a fuss, wasting materials while making more money - is OK by me if they can get away with it. But today it sowed a seed of doubt with our client that our work wasn't up to scratch and wasted half an hour of my time checking crap proofs and writing an email to explain the differences between European and US printing.

It's no shock to anybody with at least one functioning brain cell that you can't "just output the supplied files" when they were clearly produced for an incompatible device. But what's the point in even trying to argue the case? These guys get paid more for printing crap than they get for printing the job right first time.

They are the biggest threat to colour management and photographers don't deserve to be described as "peas in the same pod".

Martin Orpen

Idea Digital Imaging Ltd -- The Image Specialists

http://www.idea-digital.com

________________________________________________________________________

Date: Fri, 1 Aug 2003 07:29:30 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Dennis writes,

The first thing I'd like to say is that again this all uinderlines the

need for communication. The pros and cons of this discussion all change

when the parties involved actually talk with each other. Without

communication we just don't know what the other person did, or what they

want.

That's certainly so, which is the total antithesis of what embedded profiling was supposed to accomplish. Far more communication is now necessary than before the revolution took place.

This thread started because I asked if delivering files in LAB seemed a

safer way to deliver files when you cannot communicate with the others

down the workflow. It seems as if the answer is no, but there is no safe

way at all. Let's see, if I don't know the press conditions I cannot

accurately do a CMYK conversion. If I choose one CMYK space and embed

the profile I used so the others will know what space I used I stand the

risk of derision and am assured of disaster due to unwanted conversions.

If I supply RGB in anything other than sRGB or ColorMatch again I risk

derision and disaster. But if I deliver in RGB at all I still risk

disaster.

This is somewhat exaggerated. To go over each one of these:

*AFAIK nobody here has suggested that handing off LAB is unsafe.

*The idea that if you don't know the press conditions you can't do a good conversion is nonsense peddled by people who can't even spell CMYK.

*Embedding a CMYK profile may well brand you as an unsophisticated user but it's one of those things that's needlessly risky and therefore best avoided. Actual disasters are rare, but minor quality losses are likely.

*If you supply Adobe RGB or some wide-gamut boutique RGB nobody AFAIK would laugh at it. However, the potential for disaster is very real if somebody misinterprets them.

*If you supply a more standard RGB undesirable things may occur but "disaster" is probably too strong a word.

The only one that really is a guaranteed disaster is if you use Adobe RGB and somebody misinterprets it. The others pale by comparison. The response is obvious. If you wish to use Adobe RGB, by all means do so, but you have to be aware of the potential for serious problems if it gets into the wrong hands. So, you have to drive defensively. Is that such a hard concept?

Isn't there some way to ensure our intents are understood when we don't

know who else is going to work on this image? Is it that tough to figure

out how to develop some lines of communication?

One wouldn't think so, but evidently it is. We're five and a half years into

this noble experiment, and the situation is still chaotic.

The market is slowly responding to this by returning to the pre-1998 status quo. At that time, there was one loose conception of RGB (Apple RGB and variants) and one loose conception of CMYK ("SWOP"). People could use other things if they liked, but the burden was clearly on them to take charge of production and insure that the next person wasn't baffled.

The advent of multiple RGBs has, to put is as mildly as possible, not been well received. Your own group, just as hostile to the any-RGB-goes concept as the printers are, tries to steer everybody into Adobe RGB. The printers, without knowing that they're doing so, are steering everybody toward sRGB, the lowest common denominator. They will win, in many ways they already have won. There *is* a place for other RGB definitions. It's just that the burden will be on us to make sure they are applied throughout the production process, because the service providers, with rare exceptions like John Castronovo, John Romano, and Martin, aren't going to do it for us.

This debate has been interesting. One of the entertaining aspects has

been watching several posters twist words and meanings around to fit

their own ideas. A few seem genuinely interested in making a legitimate

point, but others just seem to only listen to their own words...

it seems that Dan, and others misunderstood the

intents of the guidelines posted on www.disc-info.org. These are

guidelines, not rules to get hung by. If a photographer submits a file

in sRGB and embeds the profile I really doubt his editor at the magazine

is going to reject the job. Likewise if some other colorspace is used.

Ah. That does clarify things. I am sorry to have misunderstood the section of the guidelines that states, "We do not accept sRGB." I will sorrowfully admit that, in order to fit my own ideas, I twisted the meaning of this phrase to suggest that if someone gave this group sRGB, they would not accept it. I wish to apologize to you, to the affected group, and to the list as a whole for not realizing what "We do not accept sRGB" meant. Perhaps it was a typographical error--they meant to type "We do now accept sRGB", and a "t" appeared where the "w" was supposed to?

Furthermore, now that I've reformed, I'd like to condemn that varlet,Andrew Rodney, for his own treachery in this matter. It was certainly stupid and self-serving of Andrew to twist the phrase "We do not accept sRGB" into the preposterous assumption that the group wouldn't accept sRGB. I imagine neither of us will try anything so reprehensible again.

Dan Margulis

________________________________________________________________________

Date: Fri, 01 Aug 2003 14:06:32 -0000

From: John Luke

Subject: Re: Delivering files in LAB

If I supply RGB in anything other than sRGB or ColorMatch again Irisk

derision and disaster. But if I deliver in RGB at all I still risk disaster.

This doesn't make sense. sRGB is a 2.2 gamma space and ColorMatch is a 1.8 gamma space, meaning if you open a file in a gamma contrary to the gamma of your working space, and disregard the embedded profile, the image is guaranteed to render about as awful as you could get.

There is less risk of this if we were adopting the PhotoShop US prepress defaults, which selects AdobeRGB as the working space. AdobeRGB is a 2.2 gamma space, so if your files are comming in in sRGB, or AdobeRGB, and you are already working in one of these 2.2 gamma spaces, viewing an image in the wrong profile doesn't look quite so awful as in the previous example.

Things were great when ColorMatchRGB(AppleRGB) was prevalent, but with all the digital cameras on the market, they are all either sRGB, or AdobeRGB, both 2.2 gamma spaces. Most photographers are not delivering in ColorMatchRGB anymore.

John Luke

________________________________________________________________________

Date: Fri, 1 Aug 2003 07:31:15 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

John Castronovo writes,

I hate to continue this "waste of bandwidth" as you call it...

The "waste of bandwidth" remark referred back to the earlier "Who's to Blame" thread. If you are implying that this current one has a lot more meat to it, I agree.

I'm not trying to be contentious as much as I'm trying to understand why

you have so many problems with this issue.

There *is* no issue, because you and Martin and John continually try to turn a simple factual question into a referendum on color management.

Consider these three questions:

1) Who was the best-qualified presidential candidate in 2000?

2) Who really won the presidential election of 2000?

3) Who is currently the President of the United States?

#1 and #2 can be debated endlessly. #3 is a simple factual question on which nobody disagrees, and furthermore, one's answer to #3 implies absolutely nothing about his position on #1 and #2.

Here, the factual question is just as simple and the answer just as obvious. It is: do a substantial number of printers ignore embedded profiles? And considering that you yourself have repeatedly told the group what a great competitive advantage you have over those shops who are ignoring color management, it would be extremely difficult for you to argue anything else; plus even if you did we could have Martin set you straight, since he apparently found out the answer the hard way yesterday.

Since the answer, though irrefutable and undeniable, isn't to some people's liking, they resort to answering a totally different question. So we get to hear what *your* workflow is, and we get to hear how the printers are stupid, and how this is the wave of the future, and how it's all a matter of educating users, and how we've finally turned the corner and are starting to see real growth--in short, exactly the same pap we've been being fed every year since 1991.

What we *don't* hear is your position on the topic at hand, which is, do you think a lot of printers today, in 2003, ignore embedded profiles? Because if you don't, you can be a lot more sympathetic to people like Martin who get to grieve over ruined jobs, but if you do, you wonder who is actually being stupid by not taking obvious precautions.

I'll be the first to admit that color management in PS5 was a disaster and

confusing

You're scarcely the first to admit that. Even those who, at the time of its release, called it "brilliant" and "a work of genius" now realize what a catastrophe it was for the cause of color management.

But if you *had* been the first, and had been subjected to all the mindless criticism from Adobe and its shills that the first person was, why would you have stuck to your guns? Presumably, because you realized that there's nothing more harmful than forcing a lot of unsophisticated people to misuse a technology that's only useful to "a small minority of disciplined users," or some such phrase. Now, all you have to do is realize that while what you do is useful, you're still a member of that small minority of disciplined users.

Yet you appear to believe that it's so difficult to implement correctly that

only color scientists can be trusted to make it work - and even then.'

Here we go again. I tell you that Bush is president, you tell me I appear to believe that he is the best qualified person for the job. I point out that currently only the top elite is using this, you tell me I appear to believe that only the top elite is *capable* of using it.

No, it isn't particularly difficult. But that isn't the issue. The issue is not whether it's a good workflow or a bad one, but whether there's some great silent majority out there that supports it. Obviously, there is not, as Martin just found out.

Well I am reporting that the majority of color problems with customers'

files in our shop these days originate from people who don't use color

management and who don't embed profiles. This is contrary to what your experience is, and

that's why you need to hear it from my perspective.

No, it's exactly what my experience is and what I would expect.

You don't get into shops like mine, so I have to cut you a break, but

people who follow your color management advice make my life miserable.

I am very hard-pressed to understand how. Let's go over my advice, and you can explain.

1) I advise anyone who passes out RGB files to anyone else under any circumstances to embed a profile. Does this embedded profile make your life miserable?

2) I advise anyone considering giving it to someone like you, to first call you up and find out if you know what to do when you encounter a profile-bearing RGB file. Do you have a problem receiving and answering such a call?

3) If it is not possible to reach you, or to establish that you're competent, I advise people to send an LAB file rather than tagged RGB. Does receiving an LAB file create problems for your company?

4) For those who feel confident enough to give CMYK when others might give RGB, I advise them to tell the recipient, "You are absolutely, positively, unconditionally and without exception, forbidden to convert this file without my express consent." Is this instruction unclear, and do you have any problem accepting such an instruction from a knowledgeable client?

5) I advise people who issue such instructions that a CMYK profile can only do harm and that it should be omitted. Granted that you are prohibited from acting on the CMYK profile, does it make your life miserable that it isn't there at all?

Dan Margulis

________________________________________________________________________

Date: Fri, 01 Aug 2003 08:04:49 -0600

From: Andrew Rodney

Subject: Re: Re: Delivering files in LAB

on 8/1/03 5:29 AM, Dan Margulis wrote:

That's certainly so, which is the total antithesis of what embedded profiling

was supposed to accomplish. Far more communication is now necessary than

before the revolution took place.

You keep saying that but I don1t see how and you can say this until you1re 6 feet under and that doesn1t make it so.

Digital files are just a set of numbers. With a profile, the numbers have meaning. Without it1s mystery meat. I don1t see how not having a description of the numbers in any way makes it less communicative; just the opposite.

Yes you can tag the file incorrectly if you1re a real bonehead or you have a reason to hose a file. But not having a profile is simply worse. Photoshop has no idea how to preview or convert the file. It1s as simple as that.

I1ve stayed on the sidelines as I find the discussion getting decidedly more religious but Dan1s lack of logic or explanation how numbers with no meaning can be any better than numbers with meaning is getting to bbe ridiculous.

*AFAIK nobody here has suggested that handing off LAB is unsafe.

It can be just as unsafe if given to someone that is dumb enough to embed a wrong profile or go out of his way to hose a file. It1s no safer when given to dangerous users. I will not even go into how useless yet another conversion is for both image quality let alone the time it takes in production.

*The idea that if you don't know the press conditions you can't do a

good conversion is nonsense peddled by people who can't even spell CMYK.

Why don1t you put your money where your mouth is. I'll supply you CMYK mystery meat and you produce a proof. It1s up to me to supply the CMYK data as I see fit (san1s profile of course). You also tell me how LONG it takes you to get that file ready for output. I'll output the file using my tagged profile method and tell you and the readers how long it took me.

*Embedding a CMYK profile may well brand you as an unsophisticated user

but it's one of those things that's needlessly risky and therefore best

avoided. Actual disasters are rare, but minor quality losses are likely.

Profiles don1t alter the numbers, only describe. I still see no way in which simply embedded a file into CMYK in anyway causes someone that knows what they are doing harmful.

*If you supply Adobe RGB or some wide-gamut boutique RGB nobody AFAIK

would laugh at it. However, the potential for disaster is very real if somebody

misinterprets them.

IF the profile isn1t embedded, how do they know to laugh? If the profile is embedded, they can convert with no problems at all. The profile doesn1t affect the numbers get it?

*If you supply a more standard RGB undesirable things may occur but

"disaster" is probably too strong a word.

There1s no such thing as standard RGB just like there1s no such thing as standard CMYK. I1m so tired of hearing people say they conform to SWOP only to find they are a mile off and supplying a file in SWOP (a standard) with or without a profile produces crap output.

The only one that really is a guaranteed disaster is if you use Adobe RGB and

somebody misinterprets it...

How would that be? It1s a file IN Adobe RGB and tagged as such. You mean some dinosaur with an 3OFF2 color setting ignores the tag and makes an assumption? You know what they say about assumptions. Tagged Adobe RGB is Adobe RGB for anyone willing to OPEN THEIR EYES to see!

The others pale by comparison. The response is

obvious.

It1s obvious to you and nonsense to many of us. If you1d care to go step by step and EXPLAIN how a tagged file that a user has a brain cell to recognize is dangerous and said user handles the file as they should, I1m all ears.

If you wish to use Adobe RGB, by all means do so, but you have to be

aware of the potential for serious problems if it gets into the wrong hands.

That statement could be used for any file in any colorspace in any condition. Why you seem to be gravitating to a situation with profiles only is beyond me.

So, you have to drive defensively. Is that such a hard concept?

You also need to educate which you1d think some on this list would concentrate doing rather than spending so much bandwidth telling those that will listen that the sky is falling.

One wouldn't think so, but evidently it is. We're five and a half years into

this noble experiment, and the situation is still chaotic.

Only for those that embrace chaos. There have been dozen of threads from those that don1t find this to be the case (and these are post from others besides myself and Mr. Murphy). What1s chaotic is a group of people who seem to keep saying the sky is falling!

The market is slowly responding to this by returning to the pre-1998 status

quo.

I1m really getting tired of your stat1s of the market with nothing to back it up other than a feeling on the back of your neck.

At that time, there was one loose conception of RGB (Apple RGB and

variants) and one loose conception of CMYK ("SWOP"). People could use other

things if they liked, but the burden was clearly on them to take charge of production

and insure that the next person wasn't baffled.

That1s nonsense.

The advent of multiple RGBs has, to put is as mildly as possible, not been

well received.

From the second an input device came on the scene to produced a digital file, there were multiple RGBs. From the second you could plug in an Apple 132 color display, there were multiple RGBs.

Your own group, just as hostile to the any-RGB-goes concept as

the printers are, tries to steer everybody into Adobe RGB. The printers, without

knowing that they're doing so, are steering everybody toward sRGB, the lowest

common denominator. They will win, in many ways they already have won. There

*is* a place for other RGB definitions.

And how do we define these RGB definitions? Profiles god forbid.

Ah. That does clarify things. I am sorry to have misunderstood the section of

the guidelines that states, "We do not accept sRGB." I will sorrowfully admit

that, in order to fit my own ideas, I twisted the meaning of this phrase to

suggest that if someone gave this group sRGB, they would not accept it.

IMHO, that and a lot more! Like the pulse of 3the industry2.

Furthermore, now that I've reformed, I'd like to condemn that varlet, Andrew

Rodney, for his own treachery in this matter. It was certainly stupid and

self-serving of Andrew to twist the phrase "We do not accept sRGB" into the

preposterous assumption that the group wouldn't accept sRGB. I imagine neither

of us will try anything so reprehensible again.

Sure Dan, it was me who twisted your mind. Please find a post where I said this! I never said a thing about this group and it1s acceptance or denial of sRGB. But if you need a scapegoat, why not. It1s consistent with the rest of your case which doesn1t hold water (as usual).

Andrew Rodney

http://www.imagingrevue.com

________________________________________________________________________

Date: Fri, 1 Aug 2003 13:41:04 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Gary writes,

Dan What is your recommendation for format for a Printer to ask an agency

for? We will be having a meeting with one of our major clients in the near

future to solve just such a problem. I'm leaning to LAB

That's not necessarily right. I was recommending LAB to those who have full control of their own files and are trying to reduce the possibility of error later. In this case, you're dealing with an agency, which often is a completely uncontrolled setting, and transferring it to somebody who's unlikely to mishandle it.

If you ask for LAB, you may get LAB from somebody whose monitor is whacked and thinks the image looks great on it, or you may get LAB from somebody who picked up somebody else's RGB and ignored its profile and converted on his own machine with different settings. The important thing is not what colorspace they give it to you in but making sure that whatever they give you is consistent so that you can return to them what they're expecting.

A lot of agencies have one or two super-users who are the only ones who are theoretically permitted to OK files for distribution elsewhere. There's something to be said for having them save in LAB when they're done, because oftentimes agencies dump 50 pictures on you when only one is being used, leaving you to sort it out. If only one of them is in LAB that makes it easier. Or not. It depends on who you work with.

But I was recommending LAB transfer to those who aren't sure of the competence of the printing firm. I don't think that's the case here. As long as they stay in control of their production, you should be able to cope with whatever output you agree with them to accept.

Dan Margulis

________________________________________________________________________

Date: Fri, 1 Aug 2003 11:04:54 -0700

From: Mac Townsend

Subject: Re: Re: Delivering files in LAB

Yes you can tag the file incorrectly if you1re a real bonehead or you have

a reason to hose a file

It doesn't take that.

It takes just an average user.

I'll bet that not one of my customers knows what a profile is or is even aware that they are/are not embedding it.

Photographers are a small minority in the overall Pshop user universe.

Mac Townsend,

Adcom Graphics, Fairfield, California:

Electronic Prepress & Large Format Imaging

www.adcomgraphics.com

________________________________________________________________________

Date: Fri, 01 Aug 2003 12:33:24 -0600

From: Andrew Rodney

Subject: Re: Re: Delivering files in LAB

on 8/1/03 12:04 PM, Mac Townsend wrote:

It takes just an average user.

I1m not sure what an 3average2 user is. Is this anything like1s Dan1s pulse on 3the industry2?

I'll bet that not one of my customers knows what a profile is or is even

aware that they are/are not embedding it.

If the file comes with an embedded profile, it1s not going anywhere. You have to do something really silly like turn the color policies to off. The question then becomes, where did the file originally come from and was a profile embedded. Not rocket science. So your customers don1t have to know if the profile is embedded or not. It1s there and it1s being used. Or it1s not there and you have RGB/CMYK mystery meat which serves no benefit.

Photographers are a small minority in the overall Pshop user universe.

Again, I don1t know where such stat1s are coming from. But let1s say it1s true. So a minority of users actually use the tool correctly, fine. Considering these people are producing a great deal of images from the get-go and embedding the profiles only tells me that photographers are the folks that should be handling this aspect of color (and if they wish to produce good CMYK conversions to keep their visions intact from inception to print, so much the better).

Andrew Rodney

http://www.imagingrevue.com/

________________________________________________________________________

Date: Fri, 1 Aug 2003 14:08:58 EDT

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Martin writes,

And if the photographers are afraid to take this stuff on board, I don't

blame them - why should they? The problem they have is that there is nobody

else to do this stuff for them. Their client loves the situation -

commission a photographer, a copywriter with a copy of XPress and a printer. That's all

you need now for a brochure. Tell the photographer that he has to supply

digital files (because it's a tough market and they'll do it for free) and

get the printer to run the job without wasting money one expensive proofs.

If the job looks crap it's pretty easy to start an argument between the printer and the photographer and then walk a way with an even fatter discount on the project.

A most cogent summary of the situation. The photographer may not like the bitter truth of your analysis, but that's how it goes--he has to find a way to live in the real world. The client may not like the fact that most printers ignore color management, either. But that's also the way it goes. You find a way to cope.

To stay competitive in this market, the photographer needs to find a way to ensure that his images look good in print. Accomplishing this in a fantasy world where all printers are sympathetic to color management is insufficient--it has to be done in the world as it exists. This is what I teach, and it's what this list nominally focuses on.

I get a call from a client today. "I've got a big problem with some work

that you did last month, we've got some proofs back from the US and the

images are horrible"...He sends me an email from the US printer. His position is

that it "can't be his problem" because he "just output the supplied files". This

guy has taken CMYK data that was destined for a high quality UK press with

single digit gain and "just output the supplied files" on a press with treble the

amount of gain and using inks that aren't the same colour. The file *was*

tagged, but what does that matter? These guys don't give a toss - unless

they can use the tag as a reason for the job printing badly.

I am shocked--shocked! to hear that printers ignore embedded profiles.

But why did your client send these files to the printer, after you made them sign the acknowledgement form before releasing the digital images, to the effect that the images were prepared for an unusual printing condition and would likely print unacceptably dark under more normal conditions? And why did they ignore the orange warning label on the CD saying the same thing?

As for the printer, I don't know what his contractual responsibility was so Idon't know that he was even supposed to open the files. But I would ask him, "Didn't you notice anything peculiar about the suffixes of these files? Don't they usually say .tif? But all these say .waterless_s/f_only. Does this ring any bell?"

Their scam - doing as little as possible, making a fuss, wasting materials

while making more money - is OK by me if they can get away with it. But

today it sowed a seed of doubt with our client that our work wasn't up to

scratch and wasted half an hour of my time

Those seeds of doubt can be extremely expensive. When a job goes wrong, it's very hard to convince the client that it isn't your fault.

Therefore, one has to bend over backwards to try to avoid problems, no matter whose fault the problems theoretically are. If you believe in the fantasy that all printers always honor embedded profiles, then you don't have certain of the problems the rest of us do. At least, not until the job blows up in your face, as this one just did.

The job that you sent out is just like the one of the user who gave a printer Adobe RGB. Both of you had a nonstandard color setting and were betting the entire success of the job that somebody else would know what it was. And both of you lost.

Unlike the other user, you had no choice in the matter. You *had* to use that CMYK for the live job. However, when we put such files into your client's hands, we have to be aware that we are handing him a catastrophe waiting to happen. Hence, the mandatory meeting and release form, hence the mandatory sticker on the CD. I don't know what color you use; my company used to use red stickers because that was our corporate color. I think orange is best on the whole.

Taking precautions when dealing with wildly nonstandard files is cheap. Wrecked jobs are very expensive and dissatisfied clients even more so. Given your commitment to educating users, I'm quite confident you did have that meeting with them when the job closed and that you did make them sign that form and put that warning sticker on the CD. In the U.S., that has always in my experience prevented the kind of later error you're reporting, but things may be different across the pond.

Dan Margulis

________________________________________________________________________

Date: Sat, 02 Aug 2003 08:50:58 +0100

From: Martin Orpen

Subject: Re: Delivering files in LAB

on Fri, 1 Aug 2003 14:08:58 EDT, Dan Margulis wrote:

I am shocked--shocked! to hear that printers ignore embedded profiles.

C'mon Dan, the bad printing had nothing to do with the embedded profile. They just printed the file without making any assessment and took no action on the profile.

This is no big deal to me. I didn't supply the profile because it was necessary for reproduction purposes on its intended press. It was supplied to show our *intent* for those who are interested in such matters.

If the printer employed a repro guy who'd read one of your books they could have had the file corrected for their press in a couple of seconds. Without the profile it would have taken them longer - perhaps much longer.

But why did your client send these files to the printer, after you made them

sign the acknowledgement form before releasing the digital images, to the

effect that the images were prepared for an unusual printing condition and would

likely print unacceptably dark under more normal conditions? And why did they

ignore the orange warning label on the CD saying the same thing?

Our commission was to retouch and separate supplied RGB data for reproduction on a high quality litho press in the UK - not to supply data for any other purpose.

Adding stickers and disclaimers to try and cover all possible eventualities never been called for - and I've certainly never received a CD with this information on it in the 15 years that I've been doing this kind of thing.

It seem peculiarly American actually. You probably already have to add stickers stating that the CD must not be eaten etc for fear of future litigation :-)

I will give it some serious consideration however, because we have some obvious holes to plug in the client's view of what our files are capable of...

As for the printer, I don't know what his contractual responsibility was so I

don't know that he was even supposed to open the files. But I would ask him,

"Didn't you notice anything peculiar about the suffixes of these files? Don't

they usually say .tif? But all these say .waterless_s/f_only. Does this ring

any bell?"

Since my last post I found out that the printer wasn't supplied any contract proofs - he was given colour lasers of the job! Our digital proofs were considered to expensive by the record company. Obviously not expensive as the bunch of films and matchprints that were produced in the US, but that comes out of somebody else's budget so it's not their problem.

Therefore, one has to bend over backwards to try to avoid problems, no matter

whose fault the problems theoretically are. If you believe in the fantasy

that all printers always honor embedded profiles, then you don't have certain of

the problems the rest of us do. At least, not until the job blows up in your

face, as this one just did.

Aaaaghh, stop mentioning the embedded profile! It was not the cause of the problem. We did not embed it for this purpose. We have no need to. We can produce good CMYK data for the US and digitally proof it using US press simulations.

If the printer was clued up on colour management the profile could have helped resolve the issue quickly. (Although how he would know the colour didn't match, and why he would care given that he was supplied colour copies as proofs, I don't know).

The job that you sent out is just like the one of the user who gave a printer

Adobe RGB. Both of you had a nonstandard color setting and were betting

the entire success of the job that somebody else would know what it was.

And both of you lost.

Our separations were no more non-standard than SWOP - they were standard for UK litho use.

We get data from the US and Japan all the time. We know that you can't just run the files and expect the colour to look right in a UK magazine. None of the stuff has embedded profiles so we have to spend some time and a few proofs to get the colours just right.

A profile could probably halve this work and save our clients a load of cash. It seems sensible to me, but others seem to view the idea as completely mad.

Taking precautions when dealing with wildly nonstandard files is cheap.

Wrecked jobs are very expensive and dissatisfied clients even more so. Given

your commitment to educating users, I'm quite confident you did have that meeting

with them when the job closed and that you did make them sign that form and

put that warning sticker on the CD. In the U.S., that has always in my experience

prevented the kind of later error you're reporting, but things may be

different across the pond.

Well, as we haven't produced "wildly non-standard files" I don't really see the necessity of all the paperwork. But I'll agree that we need to make some information available on our web site that defines the limitations of what you can and can't do with RGB and CMYK data.

I'll think about it while I'm making some adjustments to my personal colour balance. I'm just about to leave for a 3 week holiday in France :-) I'll still be getting the list posts, but might be a bit more relaxed about replying.

Regards

Martin Orpen

Idea Digital Imaging Ltd -- The Image Specialists

http://www.idea-digital.com

________________________________________________________________________

Date: Sat, 2 Aug 2003 10:16:01 -0400

From: Loring Palleske

Subject: Re: Re: Delivering files in LAB

I would think most photographers are very aware of profiles. I sure as h*(& am!

No offense meant to the printing industry but you are the people we pay to get our images right.

If you want to ignore my profiles - all the power to you. Just make sure the final product comes out the way I want it. If you have to use Voodoo or Black Magic - I couldn't care. If you try to charge me extra because it takes you 3 proofs and 10 hrs of prepress work to get it right, then I am looking for a new printer.

Regards,

Loring Palleske

Creative Imaging

905.441.2661

________________________________________________________________________

Date: Sat, 02 Aug 2003 15:17:33 -0000

From: John Luke

Subject: In my market, digital delivery

I am a commercial photographer new to the group. I risk being booted off this group, but I must speak my mind. I've been a commercial photographer for over 20 years, have been involved in digital imaging for 10 years, digital delivery for 4 years, and recently digital capture. I have attended numerous seminars by many international consultants such as Andrew, participate in several of on-line forums and have been successfuly using profiles since 2000. There is no other way, period. I cannot fathom why anybody could think they are not needed.

I also find the need for continuing education among the prepress industry is lagging. I spend countless hours a year keeping up and asking question, not because I know it all or am clinging to outdated standards, but because in order to stay in business, I need to stay current. I do not find much of this ethic in the prepress industry unfortunately.

Yes, there are many good cutting edge shop out there, and I applaud those who have taken the initiative and are leading the pack. Unfortunately, they are in the minority and it is upsetting to me to find such resistance to progress.

Transparencies aren't comming back. Photo labs are tossing E-6 processors in dumpsters. Digital delivery is standard and the only way systems can talk the same color language is through the proper use of profiles, period. Enter the ICC compliant workflow. "Live ICC Compliant or Die" should be the mantra of the new digital age. ("Live Free or Die" just doesn't do it any more.)

If a mere photographer can figure it out, than anybody can.

John Luke

APA/ASMP

________________________________________________________________________

Date: Sat, 02 Aug 2003 12:06:35 -0400

From: Jim Rich

Subject: Re: Re: Delivering files in LAB

On 8/2/03 10:16 AM, "Loring Palleske" wrote:

No offense meant to the printing industry but you are the people we pay

to get our images right.

If you want to ignore my profiles - all the power to you. Just make

sure the final product comes out the way I want it. If you have to use

Voodoo or Black Magic - I couldn't care. If you try to charge me extra

because it takes you 3 proofs and 10 hrs of prepress work to get it

right, then I am looking for a new printer.

Loring,

You just hit the nail on its head-HARD!

Working smart and efficiently using profiles or working hard with ignoring them and then having expensive cost overruns in 2003 is the choice of using profiles or not using them.

The imaging process (pre-press, print-for-pay or photography) will work with without profiles (it always has). In my view, one part of this argument boils down to how much are you willing to pay in time and money. While their is an upfront expense: for profiling gear, training to learn how to use profiles and integration of them into a workflow. Using profiles has proven to save money for clients as well as service providers. Profiles are not perfect, but these days, a lot of folks experience (on and off this list) shows us that using profiles is a logical choice for a lot of workflows.

Jim Rich

________________________________________________________________________

Date: Sat, 2 Aug 2003 11:58:36 -0400

From: John Romano

Subject: Re: In my market, digital delivery

John

I like your "Live ICC Compliant or Die " attitude you must be from New Hampshire. Printers are coming around to the ICC way but there is still a need for communication. I would rather get digital files that are Tagged anyday of the week, I have been watching that drum spin for too many years. But hey if people dont want to tag thier files because they are afraid of the big " what if " well so be it. In the meantime I will go along assigning and converting till my hearts content and embedding on the way out, sooner or later everyone will catch on.

John

________________________________________________________________________

Date: Sat, 2 Aug 2003 13:14:14 -0400

From: John Castronovo

Subject: Re: Re: Delivering files in LAB

From: Dan Margulis

What we *don't* hear is your position on the topic at hand, which is, do you

think a lot of printers today, in 2003, ignore embedded profiles?

The very best print shops in my area all respect color management and appear to be the most profitiable (I'm sure there's no connection) in spite of it. Your position as I understand it is that problems come when dealing with the less knowledgeable in the business, and your advice is to protect ourselves from these otherwise capable printers by supplying them with files that they're less likely to destroy. Should I not cross the street because people run red lights?

If the automobile is to blame for the hazards of equestrian travel on the highway, what should we do about it? And while I'm on the car analogy: for years after they perfected the electric starter, auto manufacturers continued to provide hand cranks on cars until people couldn't crank a big engine any more.

1) I advise anyone who passes out RGB files to anyone else under any

circumstances to embed a profile. Does this embedded profile make your

life miserable?

Not at all.

2) I advise anyone considering giving it to someone like you, to first call

you up and find out if you know what to do when you encounter a profile-bearing

RGB file. Do you have a problem receiving and answering such a call?

Never. I encourage it.

3) If it is not possible to reach you, or to establish that you're competent,

I advise people to send an LAB file rather than tagged RGB. Does receiving an

LAB file create problems for your company?

Nope. It hasn't been so far, but it's pretty rare.

4) For those who feel confident enough to give CMYK when others might give

RGB, I advise them to tell the recipient, "You are absolutely, positively,

unconditionally and without exception, forbidden to convert this file without my

express consent." Is this instruction unclear, and do you have any problem

accepting such an instruction from a knowledgeable client?

Of course, because the first thing I have to do is convert this mystery set of numbers to RGB. When I call such a person for permission or information, I'm invariably told that I don't know what I'm doing - yet the "professional" on the other end of the phone has never had a clue about how to address the problem of interpreting his mess. I've stop calling people who don't want to embed profiles. I tell my people to take their best guess - if it's wrong - then we can always blame the lack of a profile or proof when we add time charges or have to do the job over.

5) I advise people who issue such instructions that a CMYK profile can only

do harm and that it should be omitted. Granted that you are prohibited from

acting on the CMYK profile, does it make your life miserable that it isn't there

at all?

Miserable is too strong a word, I admit, but having to guess at what I'm looking at unnecessarily sucks. It's time to stop cranking the engine by hand.

john castronovo

________________________________________________________________________

Date: Sat, 2 Aug 2003 12:55:26 -0500

From: N9VJG

Subject: Re: n my market, digital delivery

Greetings to John Luke and the group:

In my opinion, your case for ICC profiles is good. If you don't think it would reveal sensitive information, could you reveal how it works within your studio, lab and/or clients? How does it work for you? Do you use custom profiles or default. This would help cut through the hostility that you mention (being booted off the group).

I believe that human beings generally resist things that are unknown to them. Once they are introduced without meaningless hostility and arrogance, understanding will develop. Subsequently, fear is removed. However, when either party--for or against ICC--resorts to name-calling and virtual tantrums, truth leaves the room.

Eric Curtis M. Basir (Bond)

Photo Grafix

http://www.abetterreality.net

(847) 673-7043

________________________________________________________________________

Date: Sat, 02 Aug 2003 18:27:20 -0000

From: John Luke

Subject: Re: In my market, digital delivery

If you don't think

it would reveal sensitive information, could you reveal how it works

within your studio, lab and/or clients?

I find that about one in ten are profile savvy, and then it makes everybody happy. I am happy to talk with the technicians on the phone, but I can tell when I'm talking with those who are not profile savvy, that there is a point where I lose them. Unfortunatley, (no disrespect intended) it's usually right away when I ask to know what their default working space is, and if they honor or discard profiles. Or they merely tell me to deliver in "CMYK". I guess they assume I'm supposed to know if it's a sheetfed or web job, but I don't. If there is no profile available, it seems the closest way is to get some custom settings rather than rely on the PS defaults.

John Luke

APA/ASMP

________________________________________________________________________

Date: Sat, 2 Aug 2003 18:29:03 -0400

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

Jim Rich writes,

You just hit the nail on its head-HARD!

Working smart and efficiently using profiles or working hard with ignoring

them and then having expensive cost overruns in 2003 is the choice of

using profiles or not using them.

This thread is like something out of the Twilight Zone.

I say, "My neighbor owns a Chevy." The color management coterie responds, "How dare you demean Japanese automakers! Japanese autos are great! They have fine quality control! They are the wave of the future! Those who have bought them are extremely satisfied! You are a dinosaur!"

"Profiles" are not the issue here. Everyone uses them. The issue is EMBEDDED profiles and whether STRANGERS honor them.

"Working smart" is not the issue here. I have always recommended that all service providers understand this technology and make intelligent choices about whether and how to use the EMBEDDED profiles they find in a file. The issue is whether a STRANGER can be trusted to do this.

Using profiles internally (which I think your second paragraph was referring to) is not the issue here. Many printers have indeed found that this is an attractive feature of the technology--including many who have set up; their systems to ignore EMBEDDED profiles that come in from STRANGERS.

The one and only issue is, and I'll ask you to comment as to your expectation on it:

You have an important job. You don't know anything about the printer, or the printer has not been chosen yet and you have no control over who it is going to be. As currently set up, your job absolutely depends on that printer being able to interpret your embedded profiles accurately.

The question is *not* whether he should do so; everybody agrees that he should. The question is: what do you think the chances are that he *will?* John Luke, in another post, seemed to indicate around one in ten. I concur. What do *you* think the odds are?

Dan Margulis

P.S. I apologize for the profusion of capital letters, but since so many people are refusing to stick to the thread topic, and instead attempting to make it a referendum on "color management", there's not much choice any more.

________________________________________________________________________

Date: Sat, 2 Aug 2003 20:21:30 -0400

From: Dan Margulis

Subject: Re: Re: Delivering files in LAB

John Castronovo writes,

Your position as I understand it is that problems come when dealing with

the less knowledgeable in the business, and your advice is to protect ourselves

from these otherwise capable printers by supplying them with files that

they're less likely to destroy.

That, for a change, is a very accurate picture of where I stand. Yes, I prefer to deal with someone like yourself who is sophisticated about the technology and who knows how to handle profiled RGB documents. Unfortunately, we don't always get to pick and choose who we deal with, and a lot of the time we don't even know who it will be. So, yes, granted that there's no quality loss, I recommend giving them files that they're less likely to destroy.

Should I not cross the street because people run red lights?

That is an excellent analogy. No, you should not be afraid to cross the street. However, I strongly recommend that each time you do so, even when you have the green light, you look in both directions to see whether there's anybody coming who isn't slowing down.

The advice you would get from others in this thread is, put a pair of blinders on and a posture collar to hold your neck straight, and walk briskly into the intersection as soon as you see you have the green light. If you get run over, then the rest of us can deluge the list with acid posts blaming the driver (who most likely was a printer) and pointing out the virtues of safe driving.

Returning to the topic at hand, I'd say the percentage of printers who ignore embedded profiles is higher than that of drivers who ignore red lights, with the possible exception of Rome, Italy, and certain parts of my home state of New Jersey.

[With respect to my comment on recommending sending untagged CMYK files]

Of course, because the first thing I have to do is convert this mystery

set of numbers to RGB. When I call such a person for permission or information,

I'm invariably told that I don't know what I'm doing - yet the

"professional" on the other end of the phone has never had a clue about how

to address the problem of interpreting his mess.

If you need an RGB file, I would never recommend that anybody send you CMYK of any flavor. I recommend untagged CMYK for those who want their files output directly in CMYK, without any changes.

Dan Margulis ________________________________________________________________________

Date: Sat, 02 Aug 2003 18:13:56 -0700

From: Mac Townsend

Subject: Re: Re: Delivering files in LAB

OK. So, because I just print the files, I'm basically no good and evil. And I am comforted to know that nobody on this list would ever send me a file for output.

But I would like to know what I am supposed to do.

What should I do when i get someone's Quark or whatever file, in which they have placed a dozen color pictures (none professionally taken), some of which may have a profile embedded, and the others will each have a different one--some cmyk, some rgb. Pick one of each of 8 different possible profiles.

My job is to make x pieces of film. To be plated for and run on a 2-color Hamada 248 where the pressman eyeballs the color. and does a pretty good job most of the time. No such thing as a press profile. I'm not even sure one's possible.

Right now I just print the thing. If i need to output composite, i have my rip set to light black generation and 310% total ink to handle rgb>cmyk conversion. AFAIK i do not have any harlequin plugins that read and act upon embedded profiles.

What should I do about the profiles embedded/not embedded in the jpgs and tiffs placed in the document? Must I open each one and change the profile to (what?) What about the ones that are CMYK web Swop and the ones with cmyk sheetfed and even the one I told them to use for RGB conversion (based on Dan's general suggestion) or 16% gain 300 TIC. (they don't always remember, or they get the file from someone else in cmyk, or someone else has been using their computer, etc...)

I do not have calibrated monitors (tried that 5-6 years ago and found that my $4,000 Pressview after calibration wasn't displaying as accurately as my 5 year old Viewsonic on Win95). Most of the files I work with are Windows files.

What should I do?

Mac Townsend

Adcom Graphics, Digital Imaging

Fairfield, California

www.adcomgraphics.com

________________________________________________________________________

Date: Sat, 02 Aug 2003 21:44:10 -0500

From: Bob Johnson

Subject: Re: Re: Delivering files in LAB

Here's another tack on this issue.(Disclaimer: I work at a pre-press house)

Another pre-press/art house prepares a job, creates a "proof", which becomes the "expected result" the "end user" approves. We receive files, untagged cmyk images, Illustrator art and a Quark file.

Because the "proof" is created by another agency, who has no idea where, what method, or even if the job will actually be produced with cmyk inks; it is our practice to proof it under our (know at this point) press conditions. Because of the high quality and detail specifications of this work, (and the high cost of a poor press run) the customer demands film based proofs (350 line screens), in our case Cromalin. (Customer won't accept digital proofs, even from our hi-end DuPont AQ-4, because they claim the 600dpi res is "too low for fine text and details in the image")

We would image the file, straight up, make Cromalins and they looked NOTHING AT ALL like the supplied proof we had to match. Several rounds of color corrections and submits ensued until we arrived at the "expected result". After losing our shirts on a few of these "ready to print" we figured out the agency had been using a profile to print the "proof" and then sending us the raw file. Often these "proofs" were little more than color prints. We couldn't figure out why we were moving the raw files nearly 30% to match their "proof".

To make the story short; after gathering press data, investigating the supplied files and proofs and our corrections; we were able to "reverse-engineer" a profile of our own which we can apply and usually match their "proof" on the first or second try.

In another example, we received an untagged cymk file which had to print in orange, green, purple and brown and still match the "proof" which was a cmyk matchprint.

We used a spectrophotometer to get ink values from a press test run, and build a custom space. The results still needed a bit of hand work, but the job was approved on the third submit. I can't imagine how many times we would have worked that job the old way.

Granted, these are big budget, high profile jobs; and we threw a lot of time, effort and money at them, but it can work. After 30+ years in the trade, something new comes along and it works. This is like going from tray developing to machine processing!

Bob Johnson

________________________________________________________________________

Date: Sat, 2 Aug 2003 22:17:58 -0400

From: John Castronovo

Subject: Re: Re: Delivering files in LAB

Well then.

We appear to be in complete agreement with the exception of embedding CMYK profiles. The problem is that I do get CMYK files all the time even though I tell people when I need RGB. What sweat would it be off of anyone's nose to simply clue me in to the CMYK profile used for display on his RGB monitor? It was there and in use whether he knows it or not, so why not embed it? It could be discarded by someone who didn't want it, but I and many others find it a great help.

From: "Dan Margulis"

If you need an RGB file, I would never recommend that anybody send you CMYK

of any flavor. I recommend untagged CMYK for those who want their files

output directly in CMYK, without any changes.

How is not providing a profile preventing changes? Honestly, I don't hang out in pressrooms so I don't know what can happen there, but I have to change CMYK files all the time whether they have profiles embedded or not. It's just harder to get it right without one because we have to assume so much.

john castronovo

________________________________________________________________________

Date: Sun, 3 Aug 2003 07:44:02 EDT

From: Richard Lynch

Subject: Re: Re: Delivering files in LAB

It's just harder to get it right without one because we have to assume so much.

Can you assume the profile that is being used (and in your hope, embedded) is correct?

Richard Lynch

http://hiddenelements.com

________________________________________________________________________

Date: Sun, 03 Aug 2003 14:17:07 -0000

From: John Luke

Subject: Re: Delivering files in LAB

I recommend untagged CMYK for those who want their files

output directly in CMYK, without any changes.

This makes no sense. This is a guarantee of failure.

John Luke

APA/ASMP

________________________________________________________________________

Date: Sun, 03 Aug 2003 14:28:31 -0000

From: John Luke

Subject: Re: Delivering files in LAB

If you prefer to do your own CMYK to your own specs, adopt the DISC standards and "require" all client submitted photo files to be embedded with AdobeRGB. That way, they are at least all the same.

It needs to be in your contract so the client knows if they send in junk, they will have to pay for every dime to get thing straight.

How's this for a draconian practice-Modern Postcard contract assumes no liability and charge for every bloody test you may want to see, and if it looks bad, they make no changes. They send the file back to the client to fix.

John Luke

APA/ASMP

________________________________________________________________________

Date: Sun, 03 Aug 2003 07:55:13 -0600

From: Andrew Rodney

Subject: Re: Re: Re: Delivering files in LAB

on 8/3/03 5:44 AM, Richard Lynch wrote:

Can you assume the profile that is being used (and in your hope, embedded) is

correct?

Why wouldn1t it be? You can open and view the data with the profile and get a real good idea if it1s wrong (it should look pretty bad).

It1s dog gone hard to have the wrong profile in a file in PHOTOSHOP 6 or 7. Someone has to go out of their way to incorrectly tag a file. It1s not impossible but it1s also not likely and it1s pretty easy to check. It1s far more likely there are things in the file that might hose some RIPS (Alpha Channels), be in the wrong format (PSD with layers), be the wrong resolution (too small), have been JPEGed dozens of times (producing artifacts), flipped or rotated incorrectly, Inverted, or otherwise just god awful. User error is user error.

Andrew Rodney

http://www.imagingrevue.com/

________________________________________________________________________

Date: Sun, 3 Aug 2003 11:18:30 -0400

From: John Castronovo

Subject: Re: Delivering files in LAB

From: Richard Lynch

Can you assume the profile that is being used (and in your hope, embedded) is

correct?

No, of course not.

One can never be sure that people have done what they were supposed to do. Could you be sure that, with or without a profile, the numbers are correct for your needs? No. Is the presence of a profile more or less information to go on? Yes.

Could it be misleading? Possibly, and this is the problem that those who oppose profiling concentrate on. It's a lot like turn signals on cars. They too can give the wrong direction due to operator error. The result can be a horrible accident, but we've all learned to trust them anyway.

john castronovo

________________________________________________________________________

Date: Sun, 3 Aug 2003 14:46:15 -0400

From: Dan Margulis

Subject: Re: Delivering files in LAB

John Castronovo writes,

We appear to be in complete agreement with the exception of embedding

CMYK profiles. The problem is that I do get CMYK files all the time even though

I tell people when I need RGB. What sweat would it be off of anyone's nose to

simply clue me in to the CMYK profile used for display on his RGB

monitor?

No, we're in agreement there too. If you say "I prefer an RGB file" anybody who gives you CMYK is asking for trouble, in much the same way that people ask for trouble by giving profiled stuff to strangers.

In today's world, I think people need to be fluent in both RGB and CMYK. There are several members of this list who I know have such fluency. But it's rare. Most people learn one way and are extremely uncomfortable learning the other, and are often in fact very insulting about the other.

The problem that started this very long thread (that a printer ignored an RGB profile) is a subset of a bigger problem, which is that many printers aren't that comfortable with RGB files, period. So much so, that you're way ahead of the game just giving them CMYK, even though you'd give RGB to somebody you were confident knows what they're doing. This is why so many photographers have now decided to become CMYK-literate, so that they can take charge of the print process and be in a position to defend themselves if a job gets messed up and the printer starts to spout printerspeak about how it's all the fault of the photography.

Similarly, most photographers, with some happy exceptions, aren't at all comfortable with CMYK, don't understand its quirks, and have crazy preconceptions about CMYK workflows.

It's true that a number of progressive individuals and companies can handle either RGB or CMYK, but they're in the minority. So, if somebody tells you "I want RGB" or "I want CMYK" it's a brave person who gives them the other without first finding out something about their actual abilities.

How is not providing a profile preventing changes? Honestly, I don't hang

out in pressrooms so I don't know what can happen there, but I have to

change CMYK files all the time whether they have profiles embedded or

not.

Entirely too many people have "Convert on Open" set up in Photoshop, or have their RIPs set up in some way where a profile can trigger a conversion. If there's no profile embedded in the CMYK file, these automated methods have nothing to convert *from*, so they have to leave the file alone.

A more common human error: say your shop creates conventional Matchprints (CMYK file required) and also has some cheaper, but well calibrated, process that requires an RGB file. I need some of each kind of proof. I give you CMYK files only. You send those directly to film to get the Matchprint, but need to convert them to RGB to go to the cheap proofer. In doing so, you need to be using *your* CMYK definition, not mine, as your proofer is calibrated to your own CMYK. If I send a tagged file under these circumstances, I'm making the very bold assumption that your operator both notices the embedded tag and knows enough to do Image: Mode>Assign Profile>Don't Color Manage before converting to RGB. If there's no tag, and he simply converts to RGB, he's getting what he should.

Dan Margulis

________________________________________________________________________

Date: Sun, 3 Aug 2003 19:31:42 EDT

From: Stephen Ray

Subject: Re: Re: Delivering files in LAB

In a message dated 8/3/03 12:08:37 PM, Dan Margulis writes:

A more common human error: say your shop creates conventional Matchprints

(CMYK file required) and also has some cheaper, but well calibrated,

process that requires an RGB file. I need some of each kind of proof. I

give you CMYK files only. You send those directly to film to get the

Matchprint, but need to convert them to RGB to go to the cheap proofer. In

doing so, you need to be using *your* CMYK definition, not mine, as your

proofer is calibrated to your own CMYK. If I send a tagged file under these

circumstances, I'm making the very bold assumption that your operator both

notices the embedded tag and knows enough to do Image: Mode>Assign

Profile>Don't Color Manage before converting to RGB. If there's no tag, and

he simply converts to RGB, he's getting what he should.

I need to get to a Working Space so I can properly convert to each imaging device.

My operators would notice your assigned profile and convert accordingly.

If there is no profile, upon opening your file, it will be changed to my Photoshop's CMYK working space, possibly very different than yours. It's RGB and LAB values will be different than yours and you would get a proof that is possibly very different than what you expected. Although the CMYK values read the same in my info pallet as they read in yours, the LAB numbers are different and now your file has been reinterpreted and actually changed by Photoshop as I had no choice in the matter. I really need your file to be properly tagged by you.

It is possible for me to over-ride my standard RIP settings and send your original CMYK settings thru to my various imaging devices but this surely would result in mismatched products as your CMYK values meant different colors to different devices.

As far as I am concerned, there is no such thing as a CMYK working space although I realize people need to work on CMYK files. I don't even agree that CMYK should be an option in the Color Settings Work Space at all until some more fundamental R&D with Colorsync and workflow is done. Colorsync, ICC profiles, and their associated settings are just too accident-prone for the typical user. How many times have you seen a monitor start up and change color two or three times because users have more than one monitor calibrator running? LAB would be great as work space but that's impractical so I stay with RGB. Now, I choose ColorMatch RGB because it works for everything in my shop and it's much more safe to hand off than other wide-gammut files that I have given in the past only to get a phone call about later.

I use CMYK and RGB imaging devices, some are wide-gammut, with various ICC profile capable RIPs and I have found ColorMatchRGB and ColorMatch 3.01 for CMYK to be the most reliable and realistic gamma and color across the lot thanks to the recommendation by the folks who build the Colorburst RIP.

-Stephen Ray

________________________________________________________________________

Date: Sun, 3 Aug 2003 19:10:54 -0400

From: John Castronovo

Subject: Re: Re: Delivering files in LAB

From: "Dan Margulis"

Entirely too many people have "Convert on Open" set up in Photoshop, or

have their RIPs set up in some way where a profile can trigger a

conversion. If there's no profile embedded in the CMYK file, these

automated methods have nothing to convert *from*, so they have to leave the

file alone.

I agree that 'convert on open' is a bad policy. This attempt to make the program 'convenient' is why automation has a bad name. Not having a profile is not the correct fix for this problem, however. I see it more like two wrongs not making a right.