Date: Sun, 07 Jul 2002 23:53:36 -0000
From: "marktuckerdotcom"
Subject: Color Management with Large Corporations?
I do quite a bit of work for a large entertainment corporation. They have a contract with a local separator to do all of their 4/C film work. So they're scanning transparencies from many different photographers, and also now starting to receive files that have been scanned, retouched, and color corrected by various photographers.This separator has a company policy of automatically discarding embedded profiles from files that they receive from outside sources. They also say that they've gone back to 5.5, because the output from PS7 is different from what they were getting from the same files, using 5.5.
They've also voiced some "concern" about the accuracy of color from CMYK tiff files that they've received from me. I normally deliver every job with a CMYK folder, and also an RGB folder of the same images, in case they want to do the CMYK conversions. If I don't get custom CMYK specs from them, I normally convert to CMYK (from Adobe98RGB) with either the canned PS "SWOP Coated web v2", or "SWOP Coated SheetFed v2".
I brought it up with my client, after finding out that the separator was dumping the embedded profiles, but then also blaming me for inaccurate color. She contacted her nationwide "production" contact, and this production coordinator told me that they had NO luck in using ColorSync worldwide, and she did not want files embedded with profiles. She was unclear whether she thought it best to deliver in RGB, or just separate using a general, canned procedure.
At this point, I'm not sure how to proceed, in continuing to deliver files to them. I brought up the whole "what happens when digital cameras arrive and the separator can't scan ANY film?" conversation, but I think they want to wait to put out that fire when that fire is burning right under their feet.
Has anyone run into this situation, where there's a giant corporation, and your measly little voice carries little or no weight? Any success stories/alternatives appreciated.
MT
(with CNN blue dot over my face)
http://marktucker.com/
Date: Sun, 7 Jul 2002 22:40:21 -0600
From: Chris Murphy
Subject: Re: Color Management with Large Corporations?
marktuckerdotcom writes:>This separator has a company policy of automatically discarding
>embedded profiles from files that they receive from outside
>sources. They also say that they've gone back to 5.5, because
>the output from PS7 is different from what they were getting from
>the same files, using 5.5.They probably have Photoshop 5.5 jury-rigged in such an insane way that the default settings in Photoshop 7 aren't working. I've seen NUMEROUS times in pre-press and printing companies the most INSANE Photoshop settings. They'll have a CMYK setup that is totally screwed up in order to get a monitor "match" on-screen for their eight year old monitor with the red gun half gone, and then they create the world's most bizarre custom RGB space in order to compensate for the terrible CMYK space they've set up. In effect, they actually end up with usable conversions, but it's like buying a donkey to cut in half and stitch to your horse because you shot its head off. People do the craziest things.
If you use the same profiles in Photoshop 5.x with the same rendering intent, you will get the same conversion, plus or minus a couple of percent (although in some cases black point compensation will work a LOT better in Photoshop 7).
>They've also voiced some "concern" about the accuracy of color
>from CMYK tiff files that they've received from me. I normally
>deliver every job with a CMYK folder, and also an RGB folder of
>the same images, in case they want to do the CMYK
>conversions. If I don't get custom CMYK specs from them, I
>normally convert to CMYK (from Adobe98RGB) with either the
>canned PS "SWOP Coated web v2", or "SWOP Coated SheetFed
>v2".Seems reasonable to me if they aren't giving you any separation information to go on.
>I brought it up with my client, after finding out that the separator
>was dumping the embedded profiles, but then also blaming me
>for inaccurate color.Dumping the embedded profile in your CMYK images is inconsequential. Dumping the embedded profile in the Adobe RGB images MIGHT be very consequential if they end up doing conversions.
If they are saying your separations are wrong, then they need to provide you with correct separation information or *THEY* are in the wrong. Period. Oh, and just because they are saying something doesn't make it true. Have they produced any kind of contract proof to show you how your separations behave?
> She contacted her nationwide "production"
>contact, and this production coordinator told me that they had NO
>luck in using ColorSync worldwide, and she did not want files
>embedded with profiles. She was unclear whether she thought it
>best to deliver in RGB, or just separate using a general, canned
>procedure.a.) Not having luck using ColorSync worldwide - I'll cut some slack because lots of people have had difficulty implementing color managed workflows with ICC profiles and desktop applications. It's not foolproof, it's not easy, it's not automatic. But what technology in prepress has every been that way except perhaps the coffee pot? But there are many thousands of other workflows worldwide that have implemented color management successfully and depend on it.
b.) Not wanting files with embedded profiles. Fine. As long as they are separated correctly for the output process in question, embedded profiles aren't needed. But unless their settings are jacked up, the embedded profile won't do anything anyway - it would just be ignored.
c.) If she can't tell you how to deliver your files, or how she wants them separated - THAT is the real answer and problem to what's going on here.
>Has anyone run into this situation, where there's a giant
>corporation, and your measly little voice carries little or no
>weight? Any success stories/alternatives appreciated.They need to provide some "evidence" or supporting material to back up their claim that your separations aren't any good. The SWOP v2 and sheetfed coated profiles are not unreasonable press behavior profiles. They aren't always going to make the ideal separation, but what you get shouldn't be attrocious unless their process control is really screwy. If they aren't going to follow some kind of generally recognized output behavior, then ALL the more reason they need to be responsible and provide you with accurate separation information.
Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
Date: Mon, 8 Jul 2002 18:51:40 +1000
From: "Stephen Marsh"
Subject: Re: Color Management with Large Corporations?
Mark writes:> I do quite a bit of work for a large entertainment corporation. They
> have a contract with a local separator to do all of their 4/C film
> work. So they're scanning transparencies from many different
> photographers, and also now starting to receive files that have
> been scanned, retouched, and color corrected by various
> photographers.Are there agreed workflow practices for supply of data to this company?
If the separator does not care about how the data is supplied - then they have no right to complain. If they do have thoughts on how data should be presented - then they should be available in writing in the form of a specification sheet etc.
> This separator has a company policy of automatically discarding
> embedded profiles from files that they receive from outside
> sources.Common attitude among many prepress people, for good or ill. Simply make presumptions about all incoming data.
> They also say that they've gone back to 5.5, because
> the output from PS7 is different from what they were getting from
> the same files, using 5.5.RGB Colour changed from 4 > 5.x, as did CMYK dot gain definitions. 5.x > 6 changed things again with a whole new ACE. 6 > 7 had ACE tweaks. There have been many minor changes over time, if going from v5.x to 7 then this would be more apparent - but hardly earth shattering.
What do they really mean? Not that this really matters to you. RGB > CMYK conversions are different? RGB files are slightly different? Do they have dither or scum dot concerns? Not that this should matter to you - unless you are using features that are not backwards compatable, but most users would be handing off a plain vanilla flat format file and not layered PSD or whatever. This may or may not be an issue.
> They've also voiced some "concern" about the accuracy of color
> from CMYK tiff files that they've received from me.This goes back to my earlier statement. If they have issues with your supplied data - are they being helpful in telling you how you can arrive at more acceptable data? If they only bitch and moan but do not offer any constructive help, then things may not be easy for you. Part of this is probably politics - but a good part of it is probably true too. In their opinion, the supplied CMYK may not be ideal - since it is not produced in a similar way as to how they would do it themself. I would say that any experienced separator would consider any supplied CMYK as 'junk' - as they did not separate it! Half of the time the data may be less than ideal, the other half of the time it may be quite acceptable, but not what the separator would have produced. This is often a case of K generation and UCR/GCR.
> I normally
> deliver every job with a CMYK folder, and also an RGB folder of
> the same images, in case they want to do the CMYK
> conversions. If I don't get custom CMYK specs from them, I
> normally convert to CMYK (from Adobe98RGB) with either the
> canned PS "SWOP Coated web v2", or "SWOP Coated SheetFed
> v2".Is this documented in text or folder names with the precise RGB or CMYK workspace info etc? Or are profiles the only method used to communicate your intent?
> I brought it up with my client, after finding out that the separator
> was dumping the embedded profiles, but then also blaming me
> for inaccurate color.For RGB this is not your fault - you are correct that by dumping your profiles that he may have a different space presumed and thus your colour is screwed.
For CMYK this would not matter - he is only concerned about how your supplied numbers look in his workspace and softproofing/contract proofing.
> She contacted her nationwide "production"
> contact, and this production coordinator told me that they had NO
> luck in using ColorSync worldwide, and she did not want files
> embedded with profiles. She was unclear whether she thought it
> best to deliver in RGB, or just separate using a general, canned
> procedure.This is not really a ColorSync issue - so I think their ignorance is showing here...but I understand what they mean. They don't care or want to know about ICC based colour management. At the same time they are not capable (savvy) of offering you a solution to fit into the separators closed loop or internal workflow.
> At this point, I'm not sure how to proceed, in continuing to deliver
> files to them.Establish firm groundrules with the separator. Is it going to be RGB or CMYK. And what EXACT specs for RGB and CMYK. You have to have some rough aimpoint. Although offering both modes is good for a one off job at an unknown source - you do not want to build a long term relationship with this dual file issue. If you convert to CMYK and you know things look bad, then perhaps give them the RGB in the separtors space so that he can do a better job (note your concerns with the basic separation so they can be addressed before any proofs are run).
Find out the RGB he uses and convert your outgoing RGB to that space.
Find out the general CMYK aimpoints for separation and supply CMYK.
The basic rule is - do not rock the boat. If you are attempting to fit into an existing established workflow, then it is best to adapt and learn how to fit in. Do not try to force things down peoples throats right away - even if you think it is 'good' for them.<g> This can wait, once you have proven yourself then your suggestions will cary more weight. At the same time, the other parties have to meet you half way and give you the basic info you need to meet their 'restrictive' workflow. It does not sound like they are meeting you halfway at this point.
Regards,
Stephen Marsh.
Date: Mon, 8 Jul 2002 10:57:23 EDT
From: DMargulis@aol.com
Subject: Re: Color Management with Large Corporations?
Mark Tucker writes:>This separator has a company policy of automatically discarding
>embedded profiles from files that they receive from outside
>sources. They also say that they've gone back to 5.5, because
>the output from PS7 is different from what they were getting from
>the same files, using 5.5.Discarding embedded profiles in incoming CMYK files is par for the course. If PS7 is configured correctly their output shouldn't vary, but separators are generally rather unhappy with PS7 so they may have abandoned it for other reasons.
>They've also voiced some "concern" about the accuracy of color
>from CMYK tiff files that they've received from me. I normally
>deliver every job with a CMYK folder, and also an RGB folder of
>the same images, in case they want to do the CMYK
>conversions. If I don't get custom CMYK specs from them, I
>normally convert to CMYK (from Adobe98RGB) with either the
>canned PS "SWOP Coated web v2", or "SWOP Coated SheetFed
>v2".These are bad profiles to use; Adobe has them backwards. The web profile delivers a darker sep than the sheetfed when it should be the reverse. Better to learn the Custom CMYK settings.
>I brought it up with my client, after finding out that the separator
>was dumping the embedded profiles, but then also blaming me
>for inaccurate color. She contacted her nationwide "production"
>contact, and this production coordinator told me that they had NO
>luck in using ColorSync worldwide, and she did not want files
>embedded with profiles.Again, par for the course. Embedded profiles are not known to cause problems with RGB files but there have been so many issues with embedded CMYK tags that basically the idea has been dead for a couple of years.
>Has anyone run into this situation, where there's a giant
>corporation, and your measly little voice carries little or no
>weight? Any success stories/alternatives appreciated.When essentially all the giant corporations are behaving in the same fashion, one has to consider the possibility that the measly little voice may be asking for the wrong thing.
This vendor's CMYK will vary from everybody else's, but not by all that much. If you deliver good CMYK to them, you'll get good results, regardless of whether you tag it. Throwing a CMYK tag in, as the world has discovered, has no upside and a not-insignificant downside.
RGB is another story. If you're supplying RGB files to them knowing that they are going to disregard the tags, then you're really risking ruined jobs. The difference between ColorMatch RGB and Adobe RGB, for example, is vastly greater than between any two commercial printers' versions of CMYK. Much better, if you want them to separate for you, to convert your RGB files to LAB before giving it to them. Their LAB is the same as yours, so as long as their CMYK conversions are good you should be in business.
Dan Margulis
Date: Mon, 8 Jul 2002 09:28:55 -0600
From: Chris Murphy
Subject: Re: Color Management with Large Corporations?
Dan Margulis writes:>These are bad profiles to use; Adobe has them backwards. The web profile
>delivers a darker sep than the sheetfed when it should be the reverse.
>Better to learn the Custom CMYK settings.I disagree. The "U.S. Web Coated (SWOP) v2" profile is a valid profile. It contains TR001 measurement data, and has good reversibility.
While it's possible there is a problem with the "U.S. Sheetfed Coated v2" profile (which by the way is *NOT* SWOP based, something I didn't catch in my initial response) compared to most sheetfed printing processes, it matches up rather well with Pantone's definition of sheetfed printing. Both Pantone and Adobe predicate their sheetfed output on CTP with lower than "normal" dot gain. Adobe had a press run done to come up with the measurement data for the sheetfed profile.
So they are only bad profiles to use if the printing process you are going to use doesn't have at least similar behavior to that assumed by these profiles. The profiles themselves are actually quite decent.
>When essentially all the giant corporations are behaving in the same fashion,
>one has to consider the possibility that the measly little voice may be
>asking for the wrong thing.Or that big dumb corporations are just very slow to accept any change unless they are facing lower profits and possible extinction. Oops - that's actually happening now.
Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
Date: Mon, 08 Jul 2002 13:11:24 -0400
From: Roger Schutte
Subject: Re: Color Management with Large Corporations?
> These are bad profiles to use; Adobe has them backwards. The web profile
> delivers a darker sep than the sheetfed when it should be the reverse. Better
> to learn the Custom CMYK settings.Dan,
I don't understand your point here. An rgb conversion to cmyk using
'sheetfed coated' returns a max ink density of 350% and 'web coated' returns
300%. Black is stronger and longer in swop indicating to me more ucr being
applied to get total ink to the lower value. What do you mean by darker?Regards,
Roger________________________________
Roger Schutte
Graphex Solutions, Inc.
http://www.GraphexSolutions.com
roger@GraphexSolutions.com
________________________________
Date: Mon, 8 Jul 2002 17:50:29 EDT
From: DMargulis@aol.com
Subject: Re: Color Management with Large Corporations?
Chris writes,>>So they are only bad profiles to use if the printing process you are going to use doesn't have at least similar behavior to that assumed by these profiles. The profiles themselves are actually quite decent.>>
You have a "sheetfed" profile that produces a much lighter sep than a "web" profile. You say that they're nevertheless OK. This is like saying that Andrew Rodney is taller than Shaquille O'Neal. This is like saying that I am older than my father. This is like saying that what Photoshop 7 does with EXIF tags benefits color management.
>>Both Pantone and Adobe predicate their sheetfed output on CTP with lower than "normal" dot gain. >>
If that were the case, then the resulting sep should be even *darker* than the one supposedly correct for web use.
>>Adobe had a press run done to come up with the measurement data for the sheetfed profile.>>
Ah. That explains it. Somebody told Chris Cox that a color copier was a sheetfed press, and forgot to say "April fool" afterwards. That "sheetfed press" profile should work pretty well for most color copiers.
The other possible explanation is that anybody who can't figure out that a sheetfed profile has to generate a darker sep than a web profile, probably can't figure out how to use a measuring device properly either.
Dan Margulis
Date: Mon, 8 Jul 2002 17:50:40 EDT
From: DMargulis@aol.com
Subject: Re: Color Management with Large Corporations?
Roger writes,<< I don't understand your point here. An rgb conversion to cmyk using
'sheetfed coated' returns a max ink density of 350% and 'web coated' returns
300%. Black is stronger and longer in swop indicating to me more ucr being
applied to get total ink to the lower value. What do you mean by darker?>>I mean *darker*. It has nothing to do with total ink in the shadows.
Make two copies of any RGB picture with some significant midtone deal. Convert one using the "web" profile and the other using the "sheetfed" profile. Now, to both of the CMYK files Image: Mode>Assign Profile>Don't Color Manage. (This is to level the playing field, so that we can compare the two files under the same viewing conditions.)
At this point, the one separated for web absolutely, positively has to be the lighter of the two. The reason is that web printing has considerably more dot gain than sheetfed, and thus the picture will darken more on press.
By "lighter" I mean visually lighter--not just lighter in the shadows.
Instead, you will observe that the *sheetfed* sep is significantly lighter. This is an absurdity. Either the profiles' names are mixed up, or they were prepared by clueless individuals. Using them as they are will result in unnecessarily muddy web printing and sheetfed printing that's too light.
Dan Margulis
Date: Mon, 8 Jul 2002 16:25:05 -0600
From: Chris Murphy
Subject: Re: Color Management with Large Corporations?
Dan Margulis writes:>You have a "sheetfed" profile that produces a much lighter sep than a "web"
>profile. You say that they're nevertheless OK. This is like saying that
>Andrew Rodney is taller than Shaquille O'Neal. This is like saying that I am
>older than my father. This is like saying that what Photoshop 7 does with
>EXIF tags benefits color management.Dan, try to exaggerate just a little more. I've already told you what I know:
a.) the SWOP profile is based on TR001 and is reversible. It is a good profile. I know a number of publications who have confirmed press and proof behavior per TR001 and they are getting excellent results with this profile.
b.) the sheetfed profile was made from measurement data collected from a press run. I don't know anything about that press run, or if it is representative at all in the market place. I do think there is some reason to be concerned about it however. If you take CMYK values from the new Pantone solid to process guide (or what's built into Photosho for that library), and use the sheetfed profile to compute LAB values - you will get LAB values very similar to that of actual Pantone simulations. Again, it was a small sample (like 6 colors). But this tells me that whatever crazy press behavior Pantone came up with, is coincidentally quite similar to the crazy press behavior Adobe came up with. For all I know they shared the same crazy press run. Heck for all I know they used tortoise shells to make those profiles.
>If that were the case, then the resulting sep should be even *darker* than
>the one supposedly correct for web use.I see what you mean. The profile is basically saying sheetfed prints heavier than web fed, therefore the resulting sheetfed seps are lighter. I wasn't paying attention to what you originally said.
>The other possible explanation is that anybody who can't figure out that a
>sheetfed profile has to generate a darker sep than a web profile, probably
>can't figure out how to use a measuring device properly either.Not necessarily. We don't have enough information about the actual paper used, what the dot gain was, what the SID was or the linescreen. If the paper were coated, but not a very high quality coated paper, and if the SID were very high, and it was NOT printed CTP, and run at 175lpi like I think it was, the press would run heavy. But would it run heavier than SWOP? I don't know, maybe.
Oh by the way - the Sheetfed Uncoated and Web Uncoated Adobe profiles are based on identical measurement data so they are interchangable even though they shouldn't be interchangable.
Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
Date: Mon, 08 Jul 2002 22:46:52 -0000
From: "marktuckerdotcom"
Subject: Re: Color Management with Large Corporations?
Stephen and Chris:Thanks for thorough responses. To be clear, I think much of this revolves around "the color neg" issue. Many photographers have begun shooting color neg in the past few years. It drives clients nuts, because they can't give it to their standard color separator/scanner guys, because they won't touch color neg. The separators insist that their clients get a color C-print pulled, and THEN they'll scan that color print on their flatbed.
This, in turn, drives ME nuts, because of the dust issues, and the quality loss, and the possibility of mediocre printmaking, and all the generational gain. But, to them, it's the only game in town.
So I've been scanning my color neg on my Imacon, and then delivering to the client a CMYK file, along with backup RGB, and a short SimpleText ReadMe file with each folder, which explains the profiles and workflow method. THIS is where it gets touchy.
I don't know if it's because the separator (also the scanner operator company) is mad over losing the scanning business, thus they tend to talk down outside scans, or, if it's because of the workflow issues. Or maybe a little of both.
I think it's good advice NOT to rock the boat, as you say. I think I DID tend to do that initially; it became a game of finger-pointing to a degree. Separator claimed "bad scan", and photographer claimed "bad separator workflow". In this approach, no one wins; everyone is just feather-ruffled.
My client then got everyone on this big conference call -- two of the biggest separators in town, me representing photographers, and then a bunch of designer/production people. And then this head-honcho worldwide director of production for the client. Let's just say the call was a bit tense. I'm not sure what really came out of it, but we did agree to try to establish a set of custom Photoshop CMYK conversion numbers, for converting from RGB to CMYK. We also agreed to do a test -- comparing a photograph made from a C-print scanner, to the same photo where the original neg was scanned.
Right now, we're still in the midst of it all. But at least we're talking and testing.
It's a bit of a relief that you guys think there shouldn't be any large ramification for them dumping the CMYK profile (SWOP Coated WebPress) that I embed. I would bet that they use my CMYK files much more than going back to the RGB and converting it themselves.
---
Thanks for your information. I'm nowhere near as advanced as many of the people on this list. I'm a photographer, not a separator or color specialist; but like it or not, I'm having to learn.
Mark Tucker
http://marktucker.com
Date: Mon, 8 Jul 2002 19:09:50 -0400
From: "Stephen Greenfield"
Subject: Color Management with Large Corporations?
> I brought it up with my client, after finding out that the separator
> was dumping the embedded profiles, but then also blaming me
> for inaccurate color. She contacted her nationwide "production"
> contact, and this production coordinator told me that they had NO
> luck in using ColorSync worldwide, and she did not want files
> embedded with profiles. She was unclear whether she thought it
> best to deliver in RGB, or just separate using a general, canned
> procedure.
Mark,
This is part of a posting to the Prodig list last week that matches your experience, but in a different industry. It speaks to the same problem.
"In an interesting turn of events, a nation trade magazine for the interior design and high-end consumer market will no longer accept digital photography. All work must now be submitted as either a medium or large format transparency.
"Too many problems with the digital photography we've received, so we are now only accepting transparencies." That was the statement from the production manager for the magazine.
I've photographed for the magazine before, several times, and have always provided trans, but now I want to submit high-rez scans of my film (which other publications use all the time). I may be allowed to do this since I have a past history of quality with this magazine, but it's going to take a call to the "publisher" to get permission.
I was taken back a bit from the conversation, but according to the production manager, several magazines in this "group" are returning to a "transparency only" policy. The three major problems with digital photography according to my source, were the poor quality of work, "color" all over the place, and uneven consistency from one photograph to the next, even from the same photographer. She said many of the digital files needed a "lot of work" on their end to make it acceptable. It was more cost effective for them to scan trans than "redo" digital files."
New comments.
In a follow-up with the magazine client, I ask more specific questions about the new policy of not accepting digital photography (when in actuality it's digital files she will not accept; there is a difference).
I was told other than just a failure of the "photograph to work ascetically", the digital files had "color" (or lack of) all over the place. It took too long for the graphic artists and production people to bring the files into "the loop". While that was a problem in itself, when the staff did make corrections to digital files, the corrections they made might be absolutely opposite to what the photographer/ clients (interior designers) photographed, so the clients of the magazine, ads, editorial) are raising hell about the colors. It's costing them at both ends. Often unions are involved, so updating employees and technique can be very expensive in a difficult market ( or any other time).
With a transparency in hand, they scan it and can see what needs to happen to match (Big Grin) what they can do on their presses.
I believe that color management is critical for acceptance of files for print, and perhaps that is the reason I think that if clients want digital files, they must be properly prepared.
But we must also be prepared to defend our files for two big reasons. First, it's a financial thing that puts money in our pockets. There are those who sense sinking ships (prepress, small shops, big shops and those unwilling and too invested to be excited about digital files) and are ready to rip out your guts to defend their past territory. NOT all shops are like that, but believe me when I say prepress and other trade shops either will change or perish, just like photographers. It will be a slow, gasping death for some while others will change with the flow, but digital is here, just still on the frontier.
In many ways, color management was the last thing considered about the digital workflow. I think a lot of assumptions were made in the commercial end of digital photography that have just not happened at the speed anticipated and championed by others. But if one is going to be a professional now and in the future, color management is a must.
The second reason is I am proud of the work I do, whether film, digital files, Polaroid prints or whatever I do as a professional and I'm not going to let print shops throw off on me. I'm going to make them tell me where I'm wrong and I'll do it in front of the client if I can.
And if I'm wrong, I get my comeuppance, but it hasn't happened (yet).
Here's why. I can deliver a Crystal print and an inkjet print that match to my client. I can show them that my files look good on the web. I'll show their images on a CD ROM. I'll tell them that if their printer can't come very close to that they need a new printer. I show them what the image can look like on a printed page.
I tell them if their printer can't match it (within reason and other variables, but we know when something's right or not) that I work with printers who CAN. And that's the magic word. The printers are told that too, (and magazines that won't accept digital files).
Depending on the client, the printer either gets off his closed-loop butt and figures out a way to get it done, the client goes elsewhere for his printing, or the client stays with his current system and gets crap for results and I'm often out-the-door or just submit transparencies.
Fortunately, I still shoot trans and do scanning and retouching in-house. But I believe this is where the future of digital file acceptance lies, in a system of standards (even that will not work 100% of the time because of Murphy's law).
On a positive note, as a younger and more color savvy group of people get those jobs in printing and graphics, I believe color management will come from within. But we need to bang on the door from the outside too.
In a way, it returns photography and imaging to the professionals, away from Uncle Bob with a digital camera, only if we make color critical to our success as professionals. It will separate the wheat from the chaff in the long haul.
Face it. Not all of our transparency submitted work turns out printed exactly "right" either. This same magazine I spoke of earlier really missed a national print ad for a client of mine and they had the original trans.
Look for either the smaller and newer guys in the trade to adapt first or the real big players who are now running a separate digital print operation. Look for allies there.
If they can do the print job for you using your files, bring them work, make referrals to your clients. I'm supporting those people who are supporting me.
I am grateful for this list and it's many opinions and the knowledge shared.
Regards,
Stephen
Stephen Greenfield Photography
423-479-8712
stephen@stephengreenfield.ws
www.stephengreenfield.ws
Architectural, Commercial, Editorial Photographic Services
Date: Mon, 08 Jul 2002 16:05:40 -0600
From: Andrew Rodney
Subject: Re: Color Management with Large Corporations?
on 7/8/02 3:50 PM, Dan Margulis wrote:> Make two copies of any RGB picture with some significant midtone deal.
> Convert one using the "web" profile and the other using the "sheetfed"
> profile. Now, to both of the CMYK files Image: Mode>Assign Profile>Don't
> Color Manage. (This is to level the playing field, so that we can compare the
> two files under the same viewing conditions.)Would not the appearance of the files have something to do with the currently selected CMYK profile in color settings???? (he asked, knowing the answer).
A profile (any method of converting RGB to CMYK) is only as good as how accurately it mimics where the data is going to be printed.
> Ah. That explains it. Somebody told Chris Cox that a color copier was a
> sheetfed press, and forgot to say "April fool" afterwards. That "sheetfed
> press" profile should work pretty well for most color copiers.Well you've proven Chris and my point. The fact that a profile was made for a color copier with that output in mind, the profile will produce a great sep to that device despite the fact it might be named "Sheetfed." Chris's point is that if a profile accurately reflects a device, you'll get a great sep. The farther the output device is from the separation goal, the worse.
The SWOP V2 profile works great for devices that it accurately fingerprinted and awful for those that don't. The same is true for the old "Classic" CMYK engine (Photoshop 4 and older) where no profiles were used. You can name such a custom CMYK conversion anything you want. It will produce good output when its been created for a specific print condition in mind. Profiles are no better or worse and producing bad output when they are used for the wrong condition they were intended for.
BTW, I've met Shaquille O'Neal a few times and I actually am quite a bit taller than he his when I dig a 5 foot trench for him to stand in.
Andrew Rodney
Date: Mon, 08 Jul 2002 22:12:18 -0500
From: Chris Brown Photography
Subject: Re: Re: Color Management with Large Corporations?
mark tucker,> My client then got everyone on this big conference call -- two of
> the biggest separators in town, me representing photographers,
> and then a bunch of designer/production people. And then this
> head-honcho worldwide director of production for the client. Let's
> just say the call was a bit tense.I suggest you take the Pro Photoshop course offered by Margulis & Ledet. You'll learn enough in a few days to ask your client, and the sep house, the right questions regarding max ink limit, UCR levels, gray points, highlight and shadow levels. Once you get your answers from the color house, you're off and running with only CMYK files, no profiles to fret about, and the ability to back up your files & facts with results.
Chris Brown
Date: Mon, 8 Jul 2002 22:17:51 -0600
From: Chris Murphy
Subject: Re: Color Management with Large Corporations?
Stephen Greenfield (sgphoto@chartertn.net) writes:>"Too many problems with the digital photography we've received, so we are
>now only accepting transparencies." That was the statement from the
>production manager for the magazine.If a lot of their customer have been going out and buying cheap digital cameras, and using them to produce artwork for print, that would be a good reason why they have made this change. Cheap digital cameras can do a remarkable job in the hands of the knowledgable, but more than adequate resolution capability does not mean the images are usable or being prepared for print properly. I'm hearing complaints about digital file submission more and more often. I'm hearing "Oh yeah I got one of those new Whatist's for only $500! Now we can use that for putting together our own brochures!" Ha! OK buddy, whatever.
>The three major problems with digital
>photography according to my source, were the poor quality of work, "color"
>all over the place, and uneven consistency from one photograph to the next, even
>from the same photographer. She said many of the digital files needed a
>"lot of work" on their end to make it acceptable. It was more cost
>effective for them to scan trans than "redo" digital files."Sounds like exactly what I'm thinking it's about. I doubt the incoming files are being prepared by professional photographers; although it's possible a photographer recently moving digital could have problems submitting RGB files properly, let alone press ready CMYK.
>I believe that color management is critical for acceptance of files for
>print, and perhaps that is the reason I think that if clients want digital
>files, they must be properly prepared.It's true. You can't just get a camera, start shooting, and send files expecting them to magically reproduce correctly. But there are a LOT of people out there who do expect that. A lot of this expectation has come from decades of technology built into the wide variety of film products and their development.
>In many ways, color management was the last thing considered about the
>digital workflow. I think a lot of assumptions were made in the commercial
>end of digital photography that have just not happened at the speed
>anticipated and championed by others. But if one is going to be a
>professional now and in the future, color management is a must.And even on that front it's still in dire need of maturation. Some of us aren't even convinced the ICC spec, as it currently exists, provides an adequate framework for characterizing digital cameras. But even with color film, this didn't happen overnight, a few years, or even one decade. ICC based color management is still young and there is room for a lot of improvement on a variety of fronts.
But totally ignoring the tools that can help make things less difficult is short sighted, and just asking for more unnecessary work. The problem is differentiating between the tools that help and those that don't. And this isn't always that easy. It's really important to be a consumer with this stuff. Poke the products, poke the manufacturer's sales staff, demo the product, get 30-day money back guarantees, and so forth. If you buy something, wait a month to try it, wait three months to call tech support because it doesn't work - then you're getting what you ask for. Be a consumer.
Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
Date: Tue, 9 Jul 2002 19:23:25 +1000
From: "Stephen Marsh"
Subject: Re: Color Management with Large Corporations?
> Thanks for thorough responses. To be clear, I think much of this
> revolves around "the color neg" issue. Many photographers have
> begun shooting color neg in the past few years. It drives clients
> nuts, because they can't give it to their standard color
> separator/scanner guys, because they won't touch color neg.
> The separators insist that their clients get a color C-print pulled,
> and THEN they'll scan that color print on their flatbed.I can understand this - I am the separator/retoucher for a magazine publisher and although negs offer me a chance to push my colour correction skills, it would be simpler (more productive and better quality) if a tranny or print was presented. Regular scans come off the drum close to being 90% correct for matching the original. It is usually just a matter of beefing up the blacks, checking that the scanners white balance has not gone wacky, adding a little contrast and perhaps curving a few key plates or selective colours. Negs are a totally different story - a conservative guestimate would be that they require less scan time, but more than double the time spent on colour correction than with a tranny or print. Our drum and perhaps the scanner op do not produce the best files for me to pull out the orange mask, there is often around half of the ideally available tones presented for me to play with. I have seen better results from flatbeds in some cases. I may get one or two negs every month, compared to around 500 tranny/prints for our magazine work. We also offer imaging services and there is nothing worse than getting a neg with no print for reference - there is just too much room for interpretation and not every neg has a reflective reference. And the truth is - if we were given the neg and the print we would probably scan the print and just say we used the neg.<g>
> This, in turn, drives ME nuts, because of the dust issues, and the
> quality loss, and the possibility of mediocre printmaking, and all
> the generational gain. But, to them, it's the only game in town.It is simple economics in many cases. But if you have a setup which likes negs, then they may be no more hassle than any other scan, but this has not been my experience.
> So I've been scanning my color neg on my Imacon, and then
> delivering to the client a CMYK file, along with backup RGB, and
> a short SimpleText ReadMe file with each folder, which explains
> the profiles and workflow method. THIS is where it gets touchy.OK, so you are doing everything possible - since you stated that you separate to specs where possible or deliver 'general aimpoints' with SWOP or flatsheet v2 Adobe profiles, as well as the RGB backup.
> I don't know if it's because the separator (also the scanner
> operator company) is mad over losing the scanning business,
> thus they tend to talk down outside scans, or, if it's because of
> the workflow issues. Or maybe a little of both.A bit of both I would say.
> I think it's good advice NOT to rock the boat, as you say. I think I
> DID tend to do that initially; it became a game of finger-pointing
> to a degree. Separator claimed "bad scan", and photographer
> claimed "bad separator workflow". In this approach, no one wins;
> everyone is just feather-ruffled.Too true. Dan has some archived list threads on similar lines:
www.ledet.com/margulis/ACT_postings/ACT-photographers-CMYK.html
www.ledet.com/margulis/ACT_postings/ACT-PS6CM.txt
http://www.ledet.com/margulis/
> Right now, we're still in the midst of it all. But at least we're
> talking and testing.When all this takes place up front before the relationship starts - there is often a feeling of working together instead of against each other. It is a shame that this is happening after the fact, but I am sure that once you are all speaking the same language that things will improve.
> It's a bit of a relief that you guys think there shouldn't be any
> large ramification for them dumping the CMYK profile (SWOP
> Coated WebPress) that I embed. I would bet that they use my
> CMYK files much more than going back to the RGB and
> converting it themselves.The supplied CMYK profile can have a use, but many times it does not.
A CMYK tag initially means nothing in my workflow - I only care how the files numbers fit into the contract proofing conditions. The first time I open a CMYK file I do not want to know about the profile, any dialog box at this point is a severe PITA.
If the supplied CMYK file does not work for our conditions - then the profile is examined (if there is one) and this may or may not be used as the source for a CMYK > CMYK conversion tailored to our proofing conditions. If it seems like the profile actually describes the source separation, then it is trusted - if not a better description is found and used.
For RGB then ideally there is an ACCURATE profile which describes the RGB numbers - but with any unknown supplied RGB file it is unwise to trust the tagged profile unless there is written verification elsewhere that says to trust the profile or you have hard copy reference to colour/tone. I prefer not to deal with RGB files, unless they are tagged with both ICC and written documentation (either on paper or a read me txt file) and supplied profile as well as tag etc.
> Thanks for your information. I'm nowhere near as advanced as
> many of the people on this list. I'm a photographer, not a
> separator or color specialist; but like it or not, I'm having to
> learn.Thanks for waking the list up.<g> Seriously though, it is adapt or find another job. I started out as a compositor (typesetter/paste up layout) - but moved into more general prepress and now I only have to worry about separating/retouching (no more chemicals, three cheers!). I wonder how long prepress will last, given the current industry climate in Sydney. Photographers are another group who have had to face some major changes, Dan has some good archives on this subject too:
http://www.ledet.com/margulis/ACT_postings/ACT-photographer.txt
http://www.ledet.com/margulis/ACT_postings/ACT-photographycolortrends.html
Sincerely,
Stephen Marsh.
Date: Tue, 9 Jul 2002 20:03:18 +1000
From: "Stephen Marsh"
Subject: Re: Color Management with Large Corporations?
It seems like a good time for me to throw in my thoughts here - since I have been doing some testing of CMYK profiles recently to get a handle on their output. This is my ongoing tests of our in-house standard for separation/proofing for our magazine work and how similar it is to other common aimpoints that are often supplied or that I have to separate to when doing commercial work for third parties.Using the dot gain calculator spreadsheet from Bruce Lindbloom's site (he has some very good stuff, thanks Bruce) I 'quickly' measured three profiles in Photoshop for key LAB values in each process colour and paper and then calculated the approximate dot gain:
Adobe SWOP V2 - 18/17/16/22
Chromix SWOP TR001 - 18/17/16/22
Adobe PS 5 Default CMYK (SWOP Coated 20%) 'Profile' - 14/12/14/20
Adobe Sheetfed Coated V2 - 23/24/24/27
The presumably independent Adobe and Chromix measurements of the SWOP TR001 specification are with in +/- 1 LAB value of each other and in many cases they match perfectly (Absolute Colorimetric readings). Both of these profiles offer the same approx dot gain and LAB measurement data - but the profiles from Chromix come with UCR and GCR variations and also break SWOP by offering different TIL (lower and higher) in addition to the 300% TIL spec.
http://www.chromix.com/profilecentral/ (register and look for the SWOP TR001 press profiles in the free download section).
As expected the LAB data for the built in custom CMYK legacy version 5 SWOP has totally different LAB values and idealised white/black points. Also as expected, the Flatsheet LAB values are not SWOP inkset or stock. As commented by Dan, the flatsheet does have more gain than web - which does not seem right. With CTP being presumed, this makes less sense. Although with a lot of average flatsheet printers, I would guess that delivering slightly lighter seps would be more ideal than heavier ones (even with CTP there is a huge range of stock that is used, even if you get to know the press).
So I agree with Chris Murphy in that the SWOP profile seems to represent the 'real thing' - and I agree with Dan Margulis in that there is no beating the custom CMYK for flexible changes to dot gain and black generation, despite it's other limitations. Having both the Adobe and the full free sets of Chromix SWOP profiles gives users a lot of choice in TIL and K plate generation if SWOP is their aimpoint. I can't believe that the Imation K generation solution was not exploited or that someone else has not filled the void - I would like this option with profiles, instead of having to have a different profile generated for every change of GCR/UCR etc.
Regards,
Stephen Marsh.
Date: Tue, 09 Jul 2002 07:42:17 -0600
From: Andrew Rodney
Subject: Re: Re: Color Management with Large Corporations?
on 7/8/02 9:12 PM, Chris Brown Photography at cb@chrisbrownphoto.com wrote:
> Once you get your answers from the color house, you're
> off and running with only CMYK files, no profiles to fret about, and the
> ability to back up your files & facts with results.This is done without profiles...HOW?
Andrew Rodney
Date: Tue, 09 Jul 2002 07:57:53 -0600
From: Andrew Rodney
Subject: Re: Re: Color Management with Large Corporations?
on 7/9/02 3:23 AM, Stephen Marsh at samarsh@ozemail.com.au wrote:> Negs are a totally different story - a conservative guestimate
> would be that they require less scan time, but more than double the time
> spent on colour correction than with a tranny or print.All depends on the scanner software. Older drum scanners are completely brain dead about inverting color negs and removing the orange mask.
> Our drum and perhaps
> the scanner op do not produce the best files for me to pull out the orange
> mask, there is often around half of the ideally available tones presented
> for me to play with.Even the old Leaf scanners (and much better, today1s Imacon line) do a fantastic job on color negs. Color negs have a far wider range of tones so scan operators don1t have to sweat getting highlight to shadow detail (we really don1t need a scanner with much more than a 3.0-3.3 dynamic range). But software is key.
LaserSoft has a version of SilverFast that does a very good job handling negs AFTER the scan. It takes in high bit (16 bit per color) files and does the inversion and orange mask removal. If you have a scanner that SilverFast doesn1t support (it doesn1t drive the scanner), this is a great solution. Also fully ICC savvy. Scan in high bit, turn off all the sharpening you can!
> I have seen better results from flatbeds in some cases.
Simply due to the software. Throw a good high end film scanner with equally good software and you'll see even better results.
You WILL need a calibrated display. The only downside to negs is there is no reference. You the scan operator (better yet the photographer doing the scans) can control the look of the image, just as it's been done for years in the darkroom.
I love when people ask for a print. If printed from a neg, SOMEONE had to decide the tone and color that was acceptable. Why go another generation and scan a print (which now blocks up all the detail in the neg) when you can scan the neg. If someone, somewhere can make an acceptable color print, someone can make a better color scan from the neg! Its about having the right tools.
> I may get one or two negs every month, compared to around 500 tranny/prints
> for our magazine work.That's changing a lot (maybe not in your shop but a LOT of photographers are shooting neg for commercial work because they scan the work). Color neg has many advantages over transparency for shooting. Try shooting a chrome in mixed lighting and then shoot the same scene with a neg. Try over exposing a chrome a half stop (into the trash). Over expose a neg 3 stops and you'll have a great scan.
> A CMYK tag initially means nothing in my workflow - I only care how the
> files numbers fit into the contract proofing conditions. The first time I
> open a CMYK file I do not want to know about the profile, any dialog box at
> this point is a severe PITA.You can turn it off. But better, the tag shows you what THOSE numbers will look like on YOUR output device which is useful. You can do a soft proof to see what the numbers represent to any output device. And god forbid, if you need to do a CMYK to CMYK conversions, you'll need that profile. But I agree that if ones aim is to simply open the file and print it out, with no regard to how it looks, you do not need a tag.
> If the supplied CMYK file does not work for our conditions - then the
> profile is examined (if there is one) and this may or may not be used as the
> source for a CMYK > CMYK conversion tailored to our proofing conditions. If
> it seems like the profile actually describes the source separation, then it
> is trusted - if not a better description is found and used.That's the way to work.
> I prefer
> not to deal with RGB files, unless they are tagged with both ICC and written
> documentation (either on paper or a read me txt file) and supplied profile
> as well as tag etc.If the tagged RGB file looks good, that1s all that matters. But if something in writing makes you feel better...
Andrew Rodney
Date: Tue, 09 Jul 2002 10:36:31 -0300
From: Fernando Bergamaschi
Subject: Color Management with Large Corporations?
The problem is that there is no visual color reference to start. As any basic Kodac book teaches, we "pro photographers" should include in one of the photos (same light) a Kodak Gray Scale and Color Control Patches as a reference for the photo lab use. Try to estimate a color without this is like to use crystal ball. The truth is that most photographers and many people in separating houses have no clear idea of what is really to make a separating. We have access to tolls like Photoshop and have the false idea that we can make color corrections and make a separation without any idea of what inks, paper, phase of the moon and comet will pass by our photos. Any photographer that have made regular color prints with acetate filters and had to change a color paper box with a different filter pack in the middle of a job can have an idea of the difficulties involved.The problem is that many people that work with separations have no knowledge about photography and image making. As Ansel Adams use to say (and Dan Margulis too) The negative is just a means of interpretation. The basic concepts of photography are still valid. Just the tools changed. People want something that never existed in photography. Instant great photos. Photography is not only numbers. There is enough technical problems to keep anybody crazy. Both sides should comunicate more.
Separating people should give to photographer a Photoshop setup and photographer should send photos with targets. Like Kodak and MacBeth. I use this at many years and work.
Regards
--
Fernando Bergamaschi - PhotoIndustrial
Date: Tue, 09 Jul 2002 16:50:58 +0000
From: Michael O'Connor
Subject: Sheetfed vs. Web profiles
This is my first posting here, and maybe I'm missing the point. I'll admit up front that I do miss the point of color management overall, since it just seems to introduce murk into the process. Personally, I don't want images to change their display on my monitor based on how they appeared on someone else's monitor, while I can see the benefit there for online deliverables, I see nothing but added confusion for print. That contributors and photographers believe they are managing color, and form expectations on that belief, seems the worst thing that could have happened to printers and color prep houses, since those expectations are largely unfoundedBut that's another issue. What I really intended to question here is the appparent stupidity of Adobe profiles for web and sheetfed printing. It would seem, and I'm not a technician, that the "fault" may be in Adobe trying too hard to get real world data. Yes, a general web press should have more gain than a a general sheetfed press. But if you field test for normal workflow, the sheetfed presses are probably running at higher ink densities and finer screens, and I wouldn't be surprised if the average age of sheetfed presses in use is a bit older than the average age of webs (though this last point is definitely idle speculation). All of these factors should mean that the average reproduction on a general sheetfed press would appear to be darker, and exhibit numerically greater gain, than the average reproduction on a web press. And I don't see what Adobe could do about that. If they wrote their profile assuming sheetfed to run at the same densities and screen rulings as web they would be wrong. If they wrote their profile to match averaged field tested results, the results, such as they are, could seem counterintuitive, and would no doubt be even more wrong in some situations.
Maybe you've taken all this into account in your measurements, I don't know, but it seems to me there's a possible explanation here.
Date: Tue, 9 Jul 2002 18:19:38 -0400
From: "Russell Proulx"
Subject: Re: Sheetfed vs. Web profiles
On 9 Jul 2002 at 16:50, Michael O'Connor wrote:> Personally, I don't want images to change their display on my monitor based
> on how they appeared on someone else's monitor, while I can see the benefit
> there for online deliverables, I see nothing but added confusion for print.Hi Michael.
I assume you're referring to RGB here (if not then...never mind)
If we now accept to work in device independent monitor colour spaces (AdobeRGB, ColormatchRGB, etc..) that we must view images in the colourspace they were created in or convert them to our working colourspace (if it's not the same). There's nothing in an RGB working space that has anything to do with anyone else's monitor but your own. If your monitor is a decent quality and has been calibrated correctly then you should see the same thing as everyone does. If we then adjust our output to match what's on our monitors then there shouldn't be any confusion.
A CMYK file will also look the same on all these systems as long as our separation settings are the same. That's been the case as long as Photoshop's been around.
Russell Proulx
Montreal
Date: Tue, 9 Jul 2002 16:37:26 -0600
From: Chris Murphy\
Subject: Re: Sheetfed vs. Web profiles
Michael O'Connor (omichael@optonline.net) writes:>This is my first posting here, and maybe I'm missing the point. I'll
>admit up front that I do miss the point of color management overall,
>since it just seems to introduce murk into the process.The point overall is to compensate for the fact that different devices have different behavior. If there were no point at all to color management, people would still use grayscale displays. Fact is, people overwhelmingly want predictability and stability of color from all of their input, display and output devices.
> Personally, I
>don't want images to change their display on my monitor based on how
>they appeared on someone else's monitor, while I can se the benefit
>there for online deliverables, I see nothing but added confusion for
>print.If that someone else has an expecation to get approximately in print what they saw on their monitor, and they have reasonable settings and expectations for doing so - then it should be your concern if you're going to handle that image and give the customer what they expect. Otherwise you're going to give them something YOU think looks right, not necessarily what they want.
> That contributors and photographers believe they are managing
>color, and form expectations on that belief, seems the worst thing that
>could have happened to printers and color prep houses, since those
>expectations are largely unfoundedThe primary problem is with implementation. The industry has flat out dropped the ball when it comes to assisting people with implementing workflow, and the primary reason for this is money. It's not profitable to do huge amounts of workflow research and come up with workflow implementation that people buy in a box. Besides it usually needs to be customized for existing workflows. The real mucking up occurs when making major surgery to otherwise healthy workflows just to get color management squeezed into it.
>But if you field test
>for normal workflow, the sheetfed presses are probably running at higher
>ink densities and finer screens, and I wouldn't be surprised if the
>average age of sheetfed presses in use is a bit older than the average
>age of websYes, this is along the lines of my suggestion when this came up a month or two (or three) ago, and again yesterday. These profiles definitely expect sheetfed to print heavier than web.
>Maybe you've taken all this into account in your measurements, I don't
>know, but it seems to me there's a possibile explanation here.The explanation is there IS variation among sheetfed presses for one reason or another. And among other things, color management properly applied can compensate for such variations. If the process control ensures press behavior being maintained per a profile's expectation, what it can do despite its limitations is pretty remarkable compare to going through the more typical process of multiple iterations to get approval on color.
Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
Date: Tue, 09 Jul 2002 18:01:30 -0600
From: Andrew Rodney
Subject: Re: Sheetfed vs. Web profiles
on 7/9/02 10:50 AM, Michael O'Connor wrote:> Personally, I
> don't want images to change their display on my monitor based on how
> they appeared on someone else's monitor, while I can se the benefit
> there for online deliverables, I see nothing but added confusion for
> print.That's what happens when you DON'T use color management. Everyone's display is vastly different. Without profiles that describe the meaning of the numbers in a file AND a profile that describes how your individual display really behaves, everyone sees a different preview and in most cases, none are correct. With profiles, everyone sees the same thing.
> All of these factors should mean that the average reproduction on a general
> sheetfed press would appear to be darker, and exhibit numerically
> greater gain, than the average reproduction on a web press.The buzz word here is "average." I'm not sure there is such a thing. I've measured enough contract proofing devices let alone presses to know that when you compare the spectral data of a few hundred patches, the variation from device to device is pretty huge. If this wasn't the case, we could all happily live with a single CMYK output profile or sep table from Photoshop.
> And I don't see what Adobe could do about that. If they wrote their
> profile assuming sheetfed to run at the same densities and screen
> rulings as web they would be wrong. If they wrote their profile to match
> averaged field tested results, the results, such as they are, could seem
> counterintuitive, and would no doubt be even more wrong in some
> situations.And it is wrong in some situations. Hence the need for custom conversion methods (today that means custom ICC profiles).
The closer a profile (or any conversion method) is to predicting the correct output numbers, the better it will do of course. The farther it is, the worse it will be. When you expect ONE conversion method to work for lots of different uses, you have to be happy shooting for the broad side of a barn and getting what you get.
Andrew Rodney
Date: Tue, 09 Jul 2002 21:37:47 -0500
From: Chris Brown Photography
Subject: Re: Re: Color Management with Large Corporations?
Andrew Rodney,> This is done without profiles...HOW?
The same way it's been done for the last 30 years, Andrew. CMYK values don't magically shift on press to new (i.e., skewed) values just because a CMYK profile is not included. When a region of an image is, say C=35, M=25, Y=25, K=3, a pressman's job is to nail those values within the margin of dot gain. *Especially* in this day of CTP, where a hard dot on the plate is easy to achieve.
I've been through the smoke & mirrors with ICC profiles & CMYK. It's cute to see an accurate screen preview, but a calibrated proofing and printing system will reveal a poorly scanned or captured image regardless of a tuned profile.
In addition, if this business of generating CMYK profiles were such hot poop, the printers I've used for printing over 1 million copies of catalogs in the past ten years would've adapted the workflow long ago.
The only true benefit to a CMYK profile is for pretty viewing on a monitor.
Chris Brown
Date: Wed, 10 Jul 2002 17:57:35 +1000
From: "Stephen Marsh"
Subject: Re: Re: Color Management with Large Corporations?
Andrew Rodney writes:> > Negs are a totally different story - a conservative guestimate
> > would be that they require less scan time, but more than double the time
> > spent on colour correction than with a tranny or print.> All depends on the scanner software. Older drum scanners are completely
> brain dead about inverting color negs and removing the orange mask.Crosfield Celsis - the operator usually gives me an untagged CMYK file with no USM (damn those negs are sharp) and then I have to correct the file. I usually convert to RGB for this initial conversion and keep my inversion/cast removal curve layer and colour correction layers in a layered file and save out a flat file which has been converted to our press CMYK. In some cases, I have to run an action to slightly reduce the sharpness of the data, as those extremely sharp scans with no USM in scanning are amplified when the range is expanded from neg.
> > Our drum and perhaps
> > the scanner op do not produce the best files for me to pull out the orange
> > mask, there is often around half of the ideally available tones presented
> > for me to play with.> Color negs have a far wider range of tones so
> scan operators don't have to sweat getting highlight to shadow detail (we
> really don't need a scanner with much more than a 3.0-3.3 dynamic range).
> But software is key.Thats the key - having software with the good range of average neg profiles which you can pick from to get the best result before any manual correction takes place. But do not discount the hardware side of things, software is only part of the issue.
Almost anything is possible with a good reference and some curves and selective colour or whatever, but this is all a lot of extra work. So for my workflow, and perhaps others - negs are an four letter word and it becomes a curse.
> LaserSoft has a version of SilverFast that does a very good job handling > negs AFTER the scan. It takes in high bit (16 bit per color) files and does
> the inversion and orange mask removal. If you have a scanner that SilverFast
> doesn't support (it doesn't drive the scanner), this is a great solution.
> Also fully ICC savvy. Scan in high bit, turn off all the sharpening you can!Interesting, we have the acquire plug SilverFast AI for our flatbed - but I don't know if we have this stand alone post processing function for negs (we don't have the tranny option so negs may not be enabled as the hardware is not doing any trans work). Is this proprietary to the scanning software as input, or could a drum scan be converted to RGB and then be processed by SF? I did a quick check on neg scans in the SFAI manual and it only seems to have this as a prescan/scan process in our version.
> I love when people ask for a print. If printed from a neg, SOMEONE had to
> decide the tone and color that was acceptable.Yes, and I don't care who did decide that the colour and tone was acceptable - all I know is that is what the client wants you to match or to start with as a springboard for creative departures.
>Why go another generation and > scan a print (which now blocks up all the detail in the neg
> when you can scan the neg.Simple economics and productivity, in my setting anyway. In some cases it can be a quality issue too, but not if you have the right tools.
> If someone, somewhere can make an
> acceptable color print, someone can make a better color scan from the neg!
> Its about having the right tools.And often the right person wielding the tool.
But this is all hypothetical - what matters is what is available to the people who have to deal with the neg, it may not matter if someone somewhere can do this task better since the job is here and now and wanted yesterday.
> > I may get one or two negs every month, compared to around 500 tranny/prints
> > for our magazine work.> That's changing a lot (maybe not in your shop but a LOT of photographers are
> shooting neg for commercial work because they scan the work). Color neg has
> many advantages over transparency for shooting. Try shooting a chrome in
> mixed lighting and then shoot the same scene with a neg. Try over exposing a
> chrome a half stop (into the trash). Over expose a neg 3 stops and you'll
> have a great scan.And who is doing the scan? Is this scanned by the photographer and supplied as data? Do they give the neg out for scanning? What if the scanning place prefers not to handle negs? And if a neg is supplied for scanning, how are they meant to get acceptable colour and tone with no hardcopy or other reference? How many rounds of corrections must be absorbed by the service provider because there is no established aimpoint for the colour except the whim of the purchaser?
> You can turn it off. But better, the tag shows you what THOSE numbers will
> look like on YOUR output device which is useful.Sorry Andrew, you have lost me here. The tag would probably show SWOP Coated 20% or SWOP v2 etc and would not match our custom proofing device and separation aimpoints. If honouring the supplied CMYK tag then things would presumably look fine, since I would be seeing it in SWOP as incorrectly intended and not our magazine conditions. Although SWOP is not terrible for our conditions, it is not ideal either.
By ignoring any CM of CMYK files upon opening - I get to see how the supplied CMYK numbers fit into my conditions without the supplied profile interfering with things. As stated, if this then looks bad, then the file is reopended and the profile is given some consideration.
But prepress are very wary of ever changing supplied CMYK values, these are usually given more value than an tagged description of the workspace which may or may not have created the file.
> You can do a soft proof to
> see what the numbers represent to any output device.Yes, this is a very nice feature.
> And god forbid, if you
> need to do a CMYK to CMYK conversions, you'll need that profile.CMYK > CMYK, uprezing files, descreens, photocopy originals - there are many things which make me shudder which I am forced to do, CMYK > CMYK is harmless compared to many other things that are forced upon users do to the insanity known as production.
> But I agree
> that if ones aim is to simply open the file and print it out, with no regard
> to how it looks, you do not need a tag.True, but and I also agree with your deeper point - keep the original tag as it may mean something at a later point, but initially ingoring a CMYK tag and presuming your own conditions is often the best thing, since you usually want to know how the file looks in your conditions.
> If the tagged RGB file looks good, that's all that matters. But if something
> in writing makes you feel better...Andrew, there can be a wide range of what looks good to different people. There are untagged or mistagged files which some people like in sRGB and others prefer in Apple RGB...who is to say who is right?
Even though you do not like the thought - an embedded ICC tag is not usually trusted as the only definitive source of the description of a files numbers by those in the know. Too many service providers have been burned by honouring a profile which was incorrect. If a supplied image has some other method of describing the intent, as well as the tag (they have to match each other though<g>)...then I just might trust the implied colour description. Otherwise it is time to play pick the profile.
Regards,
Stephen Marsh.
Date: Wed, 10 Jul 2002 18:45:41 +1000
From: "Stephen Marsh"
Subject: Re: Epson 1270/sheetfed press settings/dark skin tones
Scott writes:> Also, I have a personal job I'm doing where I have about 85 photos from a
> wedding. All of the photos were scanned from negatives on a Nikon 4000 film
> scanner. The challenge for me is that these are photos from an interracial
> wedding. They were shot indoors by a talented amateur.Are you happy with the tones? Too light, too dark or just right?
Does noise or grain become an issue if you do adjust tonality to any moderate degree?
Are there any colour caste issues such as combos of incorrect film/lighting etc?
After correcting the endpoints and perhaps a known neutral - how do things then look?
> In the scans, the
> groom (who is white) is much too red in the flesh tones, while the bride
> (who is black) is also too red, but it doesn't seem as extreme in her case.
> Of course, a number of the photos show them together. I suspect that
> correcting the groom may fix the bride as well, but I'm not yet certain of
> this. I'm not sure of what acceptable skin tone values might be for those
> of African descent. For lack of a better, more precise term, I'd describe
> the bride's complexion as being about medium tending slightly toward light,
> in the context of the range of "black" skin. Any idea of what a good
> starting point for such skin tone values might be? All these will
> eventually be printed on the 1270. Some will be on Epson's "Matte
> Heavyweight" paper, and some will no doubt go to "Premium Glossy." Many
> will likely go on both. All files will stay either in TIFF or in Photoshop
> format.LAB aimpoints, Darker:
Lt: 55/19/27
Med: 49/23/29
Dk: 26/24/21
LAB aimpoints, Lighter:
Lt: 81/15/17
Med: 69/16/23
Dk: 36/24/23
(Random real life samples for two extremes of non caucasian skintone)
LAB GretagMacbeth ColorChecker Dark Skin Patch: 38/14/15
LAB GretagMacbeth ColorChecker Light Skin Patch: 66/15/17
In CMYK terms, which I am more familiar with...presuming SWOP v2 - on average you are looking for a higher ratio (based on caucasian) of magenta and yellow with some introduction of black. The K could range from 8 > 16 > 50%. Cyan is also run higher than caucasian too, and performs a role of similar importance to K.
> U.S. Sheetfed Coated v2, with dot gain at 15 percent. I'm using Photoshop
> 6. I seriously doubt it makes any difference, but I'm on a Mac running OS
> 9.2.1.No such beast I am afraid. You can't choose your own DG with the v2
profile - which uses values of approximatly: 23/24/24/27Do you mean the custom CMYK using SWOP Coated at 15% DG or just the FSv2
profile which one would expect to have 15% DG with CTP in mind? Or do you
have a source for the 15% DG statement which you can point me to? As stated
my measurements indicate approx values being 10% higher than 15%.> I must say that I keep re-reading Dan's book, and I understand more of it
> each time I read it. Now I want to put his methods into practice while
> maintaining settings for output that don't completely undermine everything
> I do.It would seem that working in a RGB space that is suitable for your inkjet
and press output would be the first step - probably A98.Next you would convert to a custom RGB output profile (unless you use a PostScript RIP) for the inkjet and sharpen these files for this purpose etc.
You would convert the same file to the CMYK profile/settings or aimpoints supplied by your printer in an ideal world. These press files would also be sharpened and perhaps have other edits after separation tailored for this output.
This presumes a calibrated and profiled monitor, calibrated and profiled output for inkjet and or perhaps proofing for press.
Regards,
Stephen Marsh.
Date: Tue, 9 Jul 2002 21:57:46 -0600
From: Chris Murphy
Subject: Re: Re: Color Management with Large Corporations?
Chris Brown writes:>The same way it's been done for the last 30 years, Andrew.
Things are changing. It's been the case that drum scans were used to convert analog transparencies into digital signals while simultaneously converting RGB light into CMYK signals. So you ended up with a CMYK digital file. It's an analog to digital profile if you will.
Today, an ever increasing number of separations are made by doing a mode change in Photoshop, or pre-press equipment designed to do so. In the case of Photoshop, all mode changes - all of them - are done using ICC profiles. And in the case of prepress equipment, they too are moving to ICC profile based separations.
> CMYK values don't
>magically shift on press to new (i.e., skewed) values just because a CMYK
>profile is not included. When a region of an image is, say C=35, M=25, Y=25,
>K=3, a pressman's job is to nail those values within the margin of dot gain.
>*Especially* in this day of CTP, where a hard dot on the plate is easy to
>achieve.How did you get those CMYK values to begin with?
>I've been through the smoke & mirrors with ICC profiles & CMYK. It's cute to
>see an accurate screen preview, but a calibrated proofing and printing
>system will reveal a poorly scanned or captured image regardless of a tuned
>profile.Yes, and an ever increasing number of proofing systems are using ICC profiles to do their job. Calibration alone is completely ineffectual for making digital proofers using inksets completely unlike press inks simulate a press. It's necessary to have some kind of table perform the job. At the high end, output device profiles are not considered adequate in a number of situations, but there is a class of ICC profile called the device link profile. The concept on which its based has been around for longer than I can even guess. The only thing that differentiates it, is that it's in a standard format that can be used in a wide variety of RIPs and proofing systems.
>In addition, if this business of generating CMYK profiles were such hot
>poop, the printers I've used for printing over 1 million copies of catalogs
>in the past ten years would've adapted the workflow long ago.They could easily be using them and not even know it.
>The only true benefit to a CMYK profile is for pretty viewing on a monitor.
That's just complete nonsense.
Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
Date: Tue, 09 Jul 2002 21:55:29 -0600
From: Andrew Rodney
Subject: Re: Re: Color Management with Large Corporations?
on 7/9/02 8:37 PM, Chris Brown wrote:> The same way it's been done for the last 30 years, Andrew. CMYK values don't
> magically shift on press to new (i.e., skewed) values just because a CMYK
> profile is not included.I never implied it did. HOW do you get those CMYK values? You either have some proprietary CMYK conversion from RGB in say a drum scanner, you have some color look up table (like we had in Photoshop in versions prior to Photoshop 5) or you use an ICC profile. If you are using Photoshop 5 to 7, LinoColor, FlexColor, NewColor etc, the only way to get RGB into CMYK is by use of an ICC profile. There isn't anything good bad or ugly about an ICC profile any more or less than a CLUT. Somehow RGB has to be transformed to CMYK values. Bad CLUT's make bad conversions. Good profiles (or good old fashion Photoshop tables) make good conversions. Good ICC profiles have far more control than the old Photoshop sep tables (the ability to control gamut mapping isn't a trivial feature).
> It's cute to
> see an accurate screen preview, but a calibrated proofing and printing
> system will reveal a poorly scanned or captured image regardless of a tuned
> profile.If the profile for the device was correctly made (like any conversion method) and the device remains consistent to that conversion, all is fine. That's been my point. People on some lists like to complain that ICC profiles are just bad bad bad. ANY incorrect method of conversion will be bad. If you take an ICC profile intended for device A and send the file to device B (whether the file has an embedded profile or not), you'll get poor results if device B isn't anything like device A. How do you insure you have the best method of getting optimized data for device A through Z (and do this with ONE scan?).
> In addition, if this business of generating CMYK profiles were such hot
> poop, the printers I've used for printing over 1 million copies of catalogs
> in the past ten years would've adapted the workflow long ago.They don't have to IF they handle the original RGB to CMYK conversions. They have the "special sauce" to do the job correctly. IF you provide me the same sauce (be it a profile or a Photoshop sep table) I'll produce color just as nice as the printer. BUT, the workflow today is such that lots of people are producing RGB data and don't have (and can't get) the special sauce. Often it's because the printer is using some dinosaur drum scanner that can only produce a CMYK file optimized for a certain print condition. Where does that leave you when a client comes in with a scan already in CMYK (separated god knows how), or RGB from some scanner or digital camera? The answer is to simply profile the contract proofing device, or if you think you can keep things consistent on press, the press itself and Viola, you have the special sauce needed to produce good color.
If everyone simply sent a prepress or printer transparencies and always got CMYK scans optimized for the specific print process, we wouldn't need color management. No matter how you feel, that isn't how things work any more. There is something to be said for having total control by keeping ALL the service under one roof. In such workflows, proprietary methods work fine and fall flat on their face when you have an open system were files are coming from all over the planet in multiple colorspaces AND users expect excellent color to multiple output devices.
> The only true benefit to a CMYK profile is for pretty viewing on a monitor.
The benefit of a CMYK profile is to get from RGB to CMYK. It's for allowing multiple users to see the same preview of the file 1000 miles apart. It allows a person with a CMYK file to see how on screen that file would appear if they sent it to another device. It allows a person to do a CMYK to CMYK conversion if they have no way to get the original RGB data and they have to make a completely different sep. It allows someone to convert from Press CMYK to Proofer CMYK to make that proofer simulate how the press (or any other CMYK device) will behave. It allows a user to go from CMYK to RGB if they have to go to the web or print that file on an RGB output device (because again, they were so closed minded to believe that one should scan the file as many times as one needs to output the file which is counter productive unless you sell scans for a living).
At some point in the workflow, if you are in CMYK correctly produced for your output device and have no intention of doing anything but sending the numbers to the printer, they yes, the EMBEDDED profile's only benefit is for preview. But you're not viewing the file so who cares what it looks like. Strip out the profile if it makes you feel better.
The fact that you say the only true benefit of a CMYK profile is for pretty viewing on screen leads me to believe you don't really know much about ICC
profiles.Andrew Rodney
Date: Wed, 10 Jul 2002 07:34:22 -0600
From: Andrew Rodney
Subject: Re: Re: Color Management with Large Corporations?
on 7/10/02 1:57 AM, Stephen Marsh wrote:> Crosfield Celsis - the operator usually gives me an untagged CMYK file with
> no USM (damn those negs are sharp) and then I have to correct the file. I
> usually convert to RGB for this initial conversion and keep my
> inversion/cast removal curve layer and colour correction layers in a layered
> file and save out a flat file which has been converted to our press CMYK.Ouch! Untagged CMYK color negs. So it's untagged so how to do you know how
to convert to RGB (from what CMYK flavor)? Sounds awful.> In some cases, I have to run an action to slightly reduce the sharpness of the
> data, as those extremely sharp scans with no USM in scanning are amplified
> when the range is expanded from neg.How do you know no USM is applied? Sometimes turning off what appears to be sharpening isn't completely turning off sharpening. The point source of the PMT isn't the best for color negs. You need to really play around with the aperture on the scanner (if you have that control).
> Thats the key - having software with the good range of average neg profiles
> which you can pick from to get the best result before any manual correction
> takes place.Profiles, not really. Look up tables OK.
> Is this proprietary to the scanning software as
> input, or could a drum scan be converted to RGB and then be processed by SF?
> I did a quick check on neg scans in the SFAI manual and it only seems to
> have this as a prescan/scan process in our version.You need at least 5.5 of SilverFast. The feature is called NegFix. And sending the software CMYK may not work. You want tagged RGB high bit if possible. You can download a demo from Lasersoft which is fully functional (it will place "Demo" over the image). Their software will work as a Photoshop plug-in or a stand-alone application. Look for the HDR version with Negfix.
> Simple economics and productivity, in my setting anyway. In some cases it
> can be a quality issue too, but not if you have the right tools.The best scan of a great print will never be as good as a good scan of the neg. That's just physics. The print paper has it's own curve so the minute you make that print, you lose a great deal of tonal data (and I'd suspect color gamut) that is in the neg that a good scanner could capture. Yes final will be a reflective original. But if you can't capture all the data, you can't decide what you want to end up on paper.
> But this is all hypothetical - what matters is what is available to the
> people who have to deal with the neg, it may not matter if someone somewhere
> can do this task better since the job is here and now and wanted yesterday.My point is that someone skilled in scanning and having the right tools can produce a scan that is just as pleasing (and with better quality) than the guy in the darkroom making a C print. Actually I'd prefer to see the photographer do either (make the print and scan if all else fails or better, make the scan himself). The guy who made the image should be the best person to decide how it should look. Not always possible I know.
> And who is doing the scan? Is this scanned by the photographer and supplied > as data?
That would be my preference and advice. Or someone who works with the photographer (his custom scanner operator who does the work, runs it past him, gets approval and finishes the job).
> What if the scanning place prefers not to handle negs?
Client finds a scanner that does (meaning first guy loses business). As a client, I don't really need to hear a shop tell me they prefer not do do some kind of work. I'll find someone that does (and can) do the work.
> Sorry Andrew, you have lost me here. The tag would probably show SWOP Coated
> 20% or SWOP v2 etc and would not match our custom proofing device and
> separation aimpoints.Why would it show that? Do you have any idea how many profiles are around that have the letters "SWOP" in them? You think they are remotely similar? You think SWOP is remotely similar to any kind of print process?
If you have a good, accurate, and correct CMYK profile in the file, you can see on screen what the person who provided you the file was seeing. Then you can do a soft proof and see how those numbers would look going to your output device (using a profile you must have that is good, accurate and correct). You can decide if you want to send the numbers as they appear to the device or alter the numbers. IF you have to do any mode conversions (like when you said you converted CMYK to RGB for the neg scans), you MUST have a CMYK profile tagged to get to RGB (or any other colorspace). Conversions are a two way street! The source (the tag) is JUST as important as the destination. Take a CMYK file. Duplicate it. Assign two different CMYK profiles to it and convert to say Adobe RGB 1998. Guess what, you end up with two different sets of numbers in each Adobe RGB 1998 file!
> If honouring the supplied CMYK tag then things would
> presumably look fine, since I would be seeing it in SWOP as incorrectly
> intended and not our magazine conditions. Although SWOP is not terrible for
> our conditions, it is not ideal either.Duplicate the file, convert to your output space, VIEW the original file (it is what the original user wanted) and try as best you can to make the numbers going to your output device to look like the original! Or better, get the RGB file and simply convert to your CMYK output device. That's always better. Getting CMYK for someone else's output device is never a good thing.
> By ignoring any CM of CMYK files upon opening - I get to see how the > supplied CMYK numbers fit into my conditions without the supplied profile
> interfering with things. As stated, if this then looks bad, then the file is
> reopended and the profile is given some consideration.CMYK files without a profile are just a set of numbers with no meaning. If you tag your output profile (good) you get to see how nice or ugly the file will look to your output device. Do you care how the file appeared to the person who gave you the file? Are you going to simply send the numbers to your output device despite how it will appear? If so then I've said you do not need an embedded profile. The numbers you got will provide a print and that's the end of the story. Oh, you want to fix the file so it looks good on your output device? OK, above you argue you need a reference to make a color neg scan in such a way that one can "match" the customers expectations. The original embedded CMYK profile does exactly that!
You either care how the CMYK data that wasn't optimized for your output device looks (you need the original profile) or you don't (you can ignore the profile).
> CMYK > CMYK, uprezing files, descreens, photocopy originals - there are many
> things which make me shudder which I am forced to do, CMYK > CMYK is
> harmless compared to many other things that are forced upon users do to the
> insanity known as production.Tell your customers you prefer RGB tagged files and send them away if they don't provide this<g>. You see, what customers prefer (like the ability to have you scan a color neg) plays a role here. You either never do CMYK to CMYK conversions or you occasionally do. If you do have to do this, you need the original CMYK profile embedded in the file or you've got CMYK mystery meat.
> There are untagged or mistagged files which some people like in sRGB and
> others prefer in Apple RGB...who is to say who is right?The person who signs off on the job and pays for it!
> Even though you do not like the thought - an embedded ICC tag is not usually
> trusted as the only definitive source of the description of a files numbers
> by those in the know.Nothing in life is 100%. Some people can tag the files incorrectly. It's real hard to do in Photoshop 6 or 7. I can scan a file at 72ppi, size it up to 300ppi and give it to you and as far as you know, it was scanned at 300ppi (but looks bad). Bad scanner? Bad operator? Who knows. More times than not, the tag is correct IF people would simply start getting with the program, stop burying their heads in the sand about color management, and instruct their customers correctly. All a tag does is label a file. You have the options of no label (mystery meat), the wrong profile (not impossible) or the right profile. I trust embedded profiles! If the image looks bad, I start to suspect that the profile is wrong so instead of trying to "fix" the numbers, I assign different profiles. In many cases, the file is just ugly (tag was correct) and it's time to edit the numbers. MOST of the time, the file looks fine.
> Too many service providers have been burned by
> honouring a profile which was incorrect.How? Because they didn't understand what an embedded profile does. If they just calibrated and profiled their displays, they could use their eyes and look at the file. How is having an untagged file any better here? You either send the data to the printer as you get it (in which case the tag didn't do a stinking thing) or you are mucking with the data. In the case of the latter, the embedded profile will play a role.
Despite what some here have been saying, profiles don't cause impotence, hair loss or the demise of the Margulies family tree. They are just labels. The numbers in a file are the numbers in the file. They are either right for the output device or they are not. The profile allows you to know what the case is and to deal with the situation.
Andrew Rodney
Date: Wed, 10 Jul 2002 10:00:16 -0500
From: Bob Smith
Subject: Re: Re: Color Management with Large Corporations?
Andrew Rodney wrote:> If you have a good, accurate, and correct CMYK profile in the file, you can
> see on screen what the person who provided you the file was seeing. Then you
> can do a soft proof and see how those numbers would look going to your
> output device (using a profile you must have that is good, accurate and
> correct). You can decide if you want to send the numbers as they appear to
> the device or alter the numbers.You and Stephen are getting at the same thing through different methods.
He's just ignoring the embedded profile and opening directly into his default CMYK space to see immediately (no messing with softproofing) how the image will print in his shop's conditions. Only if something looks questionable, does he go back and look at the preview the embedded profile can give him. That will hopefully give him some clue as to how to best sort out the problem. Yes, he's ignoring viewing a preview that shows what the person who created the file saw on every image he receives, but considering how many of those embedded profiles are probably totally incorrect; and how many are different profiles, but too close to his desired result to warrant doing a CMYK to CMYK conversion; his method would seem more productive. It seems the be the method used by most places I know of that receive CMYK files.Bob Smith
Date: Thu, 11 Jul 2002 01:30:00 +1000
From: "Stephen Marsh"
Subject: Re: Re: Color Management with Large Corporations?
> > Crosfield Celsis - the operator usually gives me an untagged CMYK file
> with
> > no USM (damn those negs are sharp) and then I have to correct the file.> Ouch! Untagged CMYK color negs. So it's untagged so how to do you know how
> to convert to RGB (from what CMYK flavor)? Sounds awful.The same way I deal with all our other drum scans for viewing - our CTP proofing profile is used as the input for the transform. Since the proofing profile is our magazine workspace and since the drum is producing seps targeted to those conditions - this is the best I can hope for in a less than ideal situation. The drum usually does a good job of capturing the subtle variations in colour of most reflective and positive transmissive originals, so I have to hope that the values I am presented match up to the proofing profile - for I have to have some description of what the numbers mean for the conversion to RGB. Yes it is possible to work directly in CMYK after I pull a quick curve to invert and remove the mask, but I find RGB a better space for these initial broad corrections. Any fine tuning can be done after the first proof is run.
It is less than ideal and the results would sound poor to many - but I am becoming more skilled at this task and results in print look just like a regular tranny or print, it is just that things take a lot more time in colour correction.
> > In
> > some cases, I have to run an action to slightly reduce the sharpness of the
> > data, as those extremely sharp scans with no USM in scanning are amplified
> > when the range is expanded from neg.
>
> How do you know no USM is applied? Sometimes turning off what appears to be
> sharpening isn't completely turning off sharpening. The point source of the
> PMT isn't the best for color negs. You need to really play around with the
> aperture on the scanner (if you have that control).Good point, not being a drum operator I have to take it on faith. The previous retoucher did tests with the scanner operator and they prefer minimal USM as a standard workflow. So it may well be applied in many cases, if minimally. In some cases the results were very unsightly and I requested a rescan with USM off (even if I was told it was off) and or even an optical defocus to a very minimal degree. The second scan was very sharp but without wide halos and made a very nice monitor image and proof - but was a bit dull on press...but that's what you get for attempting to match the art too close - but thats a different topic.
> > Is this proprietary to the scanning software as
> > input, or could a drum scan be converted to RGB and then be processed by SF?
> > I did a quick check on neg scans in the SFAI manual and it only seems to
> > have this as a prescan/scan process in our version.
>
> You need at least 5.5 of SilverFast. The feature is called NegFix. And
> sending the software CMYK may not work. You want tagged RGB high bit if
> possible. You can download a demo from Lasersoft which is fully functional
> (it will place "Demo" over the image). Their software will work as a
> Photoshop plug-in or a stand-alone application. Look for the HDR version
> with Negfix.Thanks for the info.
> > Simple economics and productivity, in my setting anyway. In some cases it
> > can be a quality issue too, but not if you have the right tools.
>
> The best scan of a great print will never be as good as a good scan of the
> neg. That's just physics. The print paper has it's own curve so the
> minute you make that print, you lose a great deal of tonal data (and I'd
> suspect color gamut) that is in the neg that a good scanner could capture.
> Yes final will be a reflective original. But if you can't capture all the
> data, you can't decide what you want to end up on paper.Well I have seen two different scanners where this was the case, but they were flatbeds and not dedicated film scanners. But this is my point, production does not always have the 'ideal' tool and often has to use a hammer as a screwdriver. In many cases the problem is not the neg inversion or software - but the mechanics of enlarging a 35mm neg to a half page or greater in size. A prosumer Umax Powerlook and a high end CreoScitex EverSmart I have used both provided much better results from a print of the neg than the neg itself.
> > But this is all hypothetical - what matters is what is available to the
> > people who have to deal with the neg, it may not matter if someone somewhere
> > can do this task better since the job is here and now and wanted yesterday.> My point is that someone skilled in scanning and having the right tools can
> produce a scan that is just as pleasing (and with better quality) than the
> guy in the darkroom making a C print. Actually I'd prefer to see the
> photographer do either (make the print and scan if all else fails or better,
> make the scan himself). The guy who made the image should be the best person
> to decide how it should look. Not always possible I know.OK, I was only thinking of my immediate situation and not the bigger picture. Yes I totally agree that in theory the neg should provide a better result and when ideal conditions are met it does. Sadly many production settings are not as ideal as one would hope (in many respects).
> > And who is doing the scan? Is this scanned by the photographer and supplied
> > as data?
>
> That would be my preference and advice. Or someone who works with the
> photographer (his custom scanner operator who does the work, runs it past
> him, gets approval and finishes the job).I have no issue with this. It is when we are given a neg that I do not like it - since we are not suited to producing optimal results from this media. If more than 1% of our work was negs then we would obviously look into a better neg input solution.
> Client finds a scanner that does (meaning first guy loses business). As a
> client, I don't really need to hear a shop tell me they prefer not do do
> some kind of work. I'll find someone that does (and can) do the work.In a commercial setting I agree and if I was buying scans then I would have this attitude too, if I wanted negs scanned well.
But what about a magazine publisher who gets less than 1% of work presented as negs and is not setup to give these originals justice? You really want your image to go in this publication, so what do you do? When working for design studios it irritated me that newspapers were so restrictive and forced paying advertisers to fit into senseless workflows, but this is a captive audience and where else can you go? So you learn to fit into the existing system and as a result your output improves as you are not fighting with the other party.
> Why would it show that? Do you have any idea how many profiles are around
> that have the letters "SWOP" in them? You think they are remotely similar?
> You think SWOP is remotely similar to any kind of print process?Because many of the foreign separations that worm their way into our workflow have these default Adobe CMYK tags.
My point was that I have better things to do than to try to see if the supplied tag makes sense, since it is my output that concerns me - it is only the files numbers and how my proofing profile relates to these numbers that is my initial concern.
> If you have a good, accurate, and correct CMYK profile in the file, you can
> see on screen what the person who provided you the file was seeing. Then you
> can do a soft proof and see how those numbers would look going to your
> output device (using a profile you must have that is good, accurate and
> correct). You can decide if you want to send the numbers as they appear to
> the device or alter the numbers. IF you have to do any mode conversions
> (like when you said you converted CMYK to RGB for the neg scans), you MUST
> have a CMYK profile tagged to get to RGB (or any other colorspace).
> Conversions are a two way street! The source (the tag) is JUST as important
> as the destination.Now I see your point - instead of my separate two step workflow which only bothers with a tag if the numbers are not ideal, you were suggesting that by honouring the profile from the start you might be able to see the others intent (if you can trust the tag) and that if the tag is trusted then this can be used to convert to the proofing conditions if you like the original tags description but prefer your own recipee for the same LAB values.
I do pretty much the same thing except I do not initally use the tag and proceed to assuming our output conditions as the first step, overall this is more productive for the volume of images I handle.
> > If honouring the supplied CMYK tag then things would
> > presumably look fine, since I would be seeing it in SWOP as incorrectly
> > intended and not our magazine conditions. Although SWOP is not terrible for
> > our conditions, it is not ideal either.
>
> Duplicate the file, convert to your output space, VIEW the original file (it
> is what the original user wanted) and try as best you can to make the
> numbers going to your output device to look like the original! Or better,
> get the RGB file and simply convert to your CMYK output device. That's
> always better. Getting CMYK for someone else's output device is never a good
> thing.Yes, in imaging heaven I agree - back on the shop floor with no time or other options you simply make do with the poor CMYK.
> > By ignoring any CM of CMYK files upon opening - I get to see how the
> > supplied CMYK numbers fit into my conditions without the supplied profile
> > interfering with things. As stated, if this then looks bad, then the file is
> > reopended and the profile is given some consideration.
>
> CMYK files without a profile are just a set of numbers with no meaning.Exactly - it forces the file to use my workspace as the preview and info palette and colour slider results for gray balance etc. This is a good thing, I do not care at this point what the tag may indicate - the only thing of any concern in the supplied CMYK file are the numbers - I supply the profile or tag.
> If
> you tag your output profile (good) you get to see how nice or ugly the file
> will look to your output device.Or by having the WS set to your preferred profile and not CM the doc on open, you see what is going on before a softproof is used, plus you do not have the chance of loosing the plot and leaving one file out of many with a different profile. This has the benefit of not having the profile tagged to the file when saving, since the CMYK profile is not of any concern in the flat layout file used for final output (a working layered file does have a use for a CMYK tag though, if you can follow my twisted logic<g>).
> Do you care how the file appeared to the
> person who gave you the file?Only if it can be proven to me 100% beyond doubt that the tag does actually describe the data in the file. Thus my statement that I will only give an unknown files tag some credence if there is some other documentation to backup the intent...otherwise I am forced to make educated guesses based on the tag or my own thoughts on how the file should appear.
It is not my place to care about how data is supplied to me - it is for others to care about giving me the correct data.<g>.
> Are you going to simply send the numbers to
> your output device despite how it will appear? If so then I've said you do
> not need an embedded profile. The numbers you got will provide a print and
> that's the end of the story. Oh, you want to fix the file so it looks good
> on your output device? OK, above you argue you need a reference to make a
> color neg scan in such a way that one can "match" the customers
> expectations. The original embedded CMYK profile does exactly that!If you can trust the tag. This is my point and many others. I know that your stance is that the profile is all that is needed to communicate the intent of the images numbers - but I am firmly saying that in my experience this is not going to work...and the industry seems to be saying the same.
We get a few wire photo publicity shots from image suppliers which come in as A98 JPEGS (I presume, they are CMYK by the time I see them - my concern is not supplied data in most cases, except cover shots. We have a pic editor who looks after supplied data). There is a white strip on the foot of each image which has black rasterized text which also states that the file is in A98 RGB and should be converted to the appropriate output space for the intended conditions. There is also copyright and other data here as well. This 'old fashioned visual method' still has a place among the brave new world of ICC tags and file info meta data.
Despite the advances of v6 - the colour handling of v5.x will continue to make impact for some time, and it is very easy to have an incorrect profile tagged in v5 to a CMYK file (like the SWOP Newsprint tag image file I got today which TIL and tonality did not indicate as being newsprint).
> You either care how the CMYK data that wasn't optimized for your output > device looks (you need the original profile) or you don't (you can ignore > the profile).
Standard procedure is ignore and simply output. If the file is in CMYK the numbers MUST be what is intended, since it is not the established workflow to provide numbers which are not right. It is also the standard workflow to consider a files CMYK values as taboo and not to be changed - unless you have a very good reason. Then as you say profiles do make a big difference. It all depends on the workflow and in which part of the workflow the tag is used.
If this looks bad in softproof or proofing - then the profile may or may not help the further corrections, it is always a 50/50 bet on the tag actually helping.
> > CMYK > CMYK, uprezing files, descreens, photocopy originals - there are many
> > things which make me shudder which I am forced to do, CMYK > CMYK is
> > harmless compared to many other things that are forced upon users do to the
> > insanity known as production.
>
> Tell your customers you prefer RGB tagged files and send them away if they
> don't provide this<g>. You see, what customers prefer (like the abilityto
> have you scan a color neg) plays a role here. You either never do CMYK to
> CMYK conversions or you occasionally do. If you do have to do this, you need
> the original CMYK profile embedded in the file or you've got CMYK mystery
> meat.And I find myself eating mystery meat all too often - RGB or CMYK it does not matter. Tagged or untagged it may all be the same in the end. Since the ONLY file that I can really trust as to having the right profile tagged is one that has been through my hands and not edited since (and even then things can slip through).
> > There are untagged or mistagged files which some people like in sRGB and > > others prefer in Apple RGB...who is to say who is right?
>
> The person who signs off on the job and pays for it!In many cases this is me, or the final say is with the art director who
marks up the proof asking me to correc the scan which is too light/dark or too bland or too vibrant etc.With no way to really trust that the tag is really correct and no hard copy reference, accepting digital files is often a crapshoot - and this is the way of the future! It is like the negs with no reference...it's all artwork.
> Nothing in life is 100%. Some people can tag the files incorrectly. It's
> real hard to do in Photoshop 6 or 7. I can scan a file at 72ppi, size iup
> to 300ppi and give it to you and as far as you know, it was scanned at
> 300ppi (but looks bad). Bad scanner? Bad operator? Who knows. More times
> than not, the tag is correct IF people would simply start getting with the
> program, stop burying their heads in the sand about color management, and
> instruct their customers correctly.This has been taking place - but differently to what you expect or want.
Users want to force tags and RGB and ICC down print shops throats. The service providers in more cases than not have rejected this workflow. This is not to say that ICC does not work or has no benefit - just that for input to a press workflow this may be more hassle than it is worth to established workflows (to the prepress or printers point of view).
Prepress and printers wrote the program - it is others who are throwing a spanner into the works. Printers often wan't CMYK in output ready mode which is ready for proofing as is, only the numbers matter. The CMYK file obviously would need to separated to produce a proof that both parties are willing to sign off on.
What has not been taking place is that suppliers of data have not been getting the correct separation aimpoints from prepress or printers.
A profitable RGB workflow for press (from prepress viewpoint) would have to be hassle free. It would be stated that if no tag is supplied then a certain RGB will be presumed and any alterations to the proof are at the customers expense. If a tag is used it will be honoured no matter what and if any alterations are required then this is at the customers expense. There are more overheads that seem to be absorbed by prepress than by clients when RGB enters the good old world of CMYK.
> All a tag does is label a file. You have
> the options of no label (mystery meat), the wrong profile (not impossible)
> or the right profile. I trust embedded profiles!I wish I could say the same, but a tag with no other data is worth almost next to nothing - unless you really trust the source. When I trust them but have no hard data for this trust (tag is not hard data it is a possibility to explore), then I have many nagging doubts. With no tag then at least I can blindly follow my best judement without the worry that perhaps the tag was wrong. What I really hate is when my best judgement tells me the tag is wrong but you are asked to follow the tag.
Any unknown file with a tag is a thorny issue, but give me some other indication as well as the tag and I feel a lot more comfortable.
Sincerely,
Stephen Marsh.
Date: Wed, 10 Jul 2002 11:54:29 EDT
From: DMargulis@aol.com
Subject: Re: Color Management with Large Corporations?
Stephen Greenfield writes,>>I was taken back a bit from the conversation, but according to the production manager, several magazines in this "group" are returning to a "transparency only" policy. The three major problems with digital photography according to my source, were the poor quality of work, "color" all over the place, and uneven consistency from one photograph to the next, even from the same photographer. She said many of the digital files needed a "lot of work" on their end to make it acceptable. It was more cost effective for them to scan trans than "redo" digital files.">>
Magazines and service providers do things in a logical fashion. For somebody trying to maintain color quality, their position makes perfect sense, just as it does with respect to embedded profiles. In theory, obviously it's better for the photographer to supply excellent digital files. Many of the photographers on this list can do exactly that. However, the large majority of photographers can't. If they would provide raw scans or digital captures that would be one thing, but many of them try to color-correct in Photoshop without knowing what they're doing. When that happens, it's a real headache for the next person to recorrect, if indeed it's possible to recorrect at all. I don't blame the magazine for concluding that photographers can't be trusted to deliver accurate digital files but I hope they would be willing to make exceptions for those who demonstrate that they can.
>>I believe that color management is critical for acceptance of files for print, and perhaps that is the reason I think that if clients want digital files, they must be properly prepared.>>
With respect to print production: he who can, does. He who cannot, blames color management.
>>In a way, it returns photography and imaging to the professionals, away from Uncle Bob with a digital camera, only if we make color critical to our success as professionals. It will separate the wheat from the chaff in the long haul.>>
That's exactly right. It's using the same real-world logic that the magazines and service providers do. In the real world, there are a lot of reasons why reproduction may not be satisfactory, but the client always sees it as bad photography. Those photographers who won't take matters into their own hands, IMHO, are just asking for the result they're almost certain to get.
Dan Margulis
Date: Wed, 10 Jul 2002 11:54:34 EDT
From: DMargulis@aol.com
Subject: Re: Sheetfed vs. Web profiles
Michael writes,>What I really intended to question here is the
>appparent stupidity of Adobe profiles for web and sheetfed printing. It
>would seem, and I'm not a technician, that the "fault" may be in Adobe
>trying too hard to get real world data.The key word, unfortunately, is "stupidity." Here, Adobe has released a "sheetfed" profile that anybody with more than a day or two of CMYK experience would know can't possibly be right. Stephen Marsh's numbers, although I haven't verified them, sound right to me. The dot gains for this "sheetfed" profile are right up in color copier range.
What particular error provoked this is not as important as the fact that somebody apparently approved it, providing yet more ammunition to those who say that all color management is bad.
Meanwhile, on another list, I observe that Adobe has finally grudgingly admitted that the Photoshop 7 CMYK JPEG bug discussed here some weeks ago is, in fact, a bug. At the same time we are treated to condescending advice that people who care about one percent differences shouldn't be saving in JPEG format. Further, we see the camera manufacturers again being blamed for Adobe's incompetent implementation of EXIF reading.
People who don't understand that the difference between 42% and 43% is one thing and 0% and 1% quite another, have no business writing graphics software. People who can't tell the difference between the performance of a sheetfed press and a color copier shouldn't be messing with profiles. And people who don't understand that forcing us to honor profiles that are known to be incorre