From: Dave Badger
Date: Fri, Feb 1, 2002, 9:00 PM
RE: [colortheory] More dangers of embedded CMYK Profiles
After following the discussion here a few weeks ago, I came upon my first real live instance of embedded CMYK profiles costing time and money.A job came in that had several screen shots of computer programs, along with other photos. According to the FlightCheck reports, some had no icc profile, some had sRGB, some had grayscale Gamma 2.2, and some had an icc profile called "ColorPass-V55 1100 Color Server"
Since ICC profiles are not something our people are used to checking, the job was opened (InDesign, I think) and Iris proofs run after converting all RGB's to our working space. (Which is close to the "SWOP 20%" profile in Photoshop). The converted sRGB's came out fine, but the ones with "ColorPass-55" came out all brownish and muddy. When I opened them on my monitor they looked bright and clean, which is when I discovered the problem.
I'm assuming they looked brownish and muddy because the embedded "ColorPass-55" profile is not an accurate description of our SWOP based calibrated Iris. (Which is supposed to emulate our press). Is this correct?
I'm also assuming the "ColorPass-55" profile is an accurate description of those files when scanned or created as the grays looked gray and the colors balanced when opened in PS6. We first tried doing a Covert to Profile from "ColorPass-55.icc" to "DIPress.icc" but got an undesirable color shift. We then did a Convert to Profile from "ColorPass-55.icc" to "ColorMatchRGB.icc" and then converted to "DIPress.icc". I would like to know why the first CMYK to CMYK conversion didn't work as well as going through RGB as an intermediate step. I would think both conversion methods would pass through LAB before being sent to the "DIPress.icc" profile.
This incident has me rethinking my strategy of embedding our shop's profile in all our scans. My thinking was our customers would see the scans (and/or corrections) as I had seen them assuming a calibrated profiled monitor and PS6 with a "Preserve embedded" policy. And even if they didn't, I couldn't see how the embedded profile could hurt... until now.
Then, there's the question of who should pay for the first round of Iris's. If this customer had not embedded, we would have assumed just another job with mediocre scans from a do-it-yourselfer. On the other hand, since they did embed, we caught the fact that these were really great scans/digital files, just with the wrong profile for our shop.
This means training the people who preflight to scour the report for mismatched profiles (not an easy task) and all the consequences involved with resolving that. As it is, they are hoping color management stays confined to my room as they don't want "one more problem to deal with".
So, to restate the question, should the client be responsible since they embedded, or should the printer/service bureau be responsible for this CMYK to CMYK mismatch? And yes we could post the press profile on our website, but I bet the downloads would be few and far between.
Thanks,
Dave Badger
From: Andrew Rodney
Date: Sat, Feb 2, 2002, 4:05 PM
RE: Re: [colortheory] More dangers of embedded CMYK Profiles
Dave Badger wrote:> I'm assuming they looked brownish and muddy because the embedded
> "ColorPass-55" profile is not an accurate description of our SWOP based
> calibrated Iris. (Which is supposed to emulate our press). Is this correct?Well it1s hard to say since your description of what you didn1t isn1t clear yet. You said you converted all the RGB files to your Iris. Are the files tagged as 3ColorPass-552 RGB files to begin with? Is it possible you did a CMYK to CMYK conversion? You go on to say2
> When I opened them on my > monitor they looked bright and clean, which is when I discovered the > problem.
I1m not clear what you mean. You opened the files (which are tagged) and they looked OK. So there shouldn1t be a problem here. That is, if the tag were wrong, the image should preview incorrectly. It sounds like you are saying that when you look at the numbers in the file with this ColorPass-55 tag, you like what you see. So at what point did the files end up ugly and brown? When you do a conversion from ColorPass-55 to Dave1s Iris, do the images appear OK or go ugly at this point?
> I'm also assuming the "ColorPass-55" profile is an accurate description of
> those files when scanned or created as the grays looked gray and the colors
> balanced when opened in PS6.That sounds like a reasonable guess to me as well. Where the RGB values neutral?
> We first tried doing a Covert to Profile from
> "ColorPass-55.icc" to "DIPress.icc" but got an undesirable color shift. We
> then did a Convert to Profile from "ColorPass-55.icc" to "ColorMatchRGB.icc"
> and then converted to "DIPress.icc". I would like to know why the first CMYK
> to CMYK conversion didn't work as well as going through RGB as an
> intermediate step. I would think both conversion methods would pass through
> LAB before being sent to the "DIPress.icc" profile.Off hand I can't think of a reason this would happen (Chris?). Going from ColorPass-55 to ColorMatch to DIPRess shouldn1t have made much of a difference other than an extra conversion. If the file converted fine from ColorPass-55 to ColorMatch, it should be fine going from ColorPass-55 directly to DIPress. Was the original conversion done outside of Photoshop where a RIP setting or some software setting could have hosed the file?
> This incident has me rethinking my strategy of embedding our shop's profile
> in all our scans. My thinking was our customers would see the scans (and/or
> corrections) as I had seen them assuming a calibrated profiled monitor and
> PS6 with a "Preserve embedded" policy. And even if they didn't, I couldn't
> see how the embedded profile could hurt... until now.This is sound logic. The embedding of a profile only aids in removing ambiguity in a set of numbers. At least as far as previewing the data. Since it sounds like you are scanning directly into an output space, (no one is going to convert the file), then embedding just allows each user to see what you saw. There is no way that1s going to happen without the profile (unless all your users are very lucky and happen to have the DIPress profile loaded as their CMYK work space).
> Then, there's the question of who should pay for the first round of Iris's.
> If this customer had not embedded, we would have assumed just another job
> with mediocre scans from a do-it-yourselfer. On the other hand, since they
> did embed, we caught the fact that these were really great scans/digital
> files, just with the wrong profile for our shop.You have to get to the bottom of why the images got so ugly. It makes no sense that viewing the tagged files looked good and then something happened to make them ugly after a conversion. If the embedded profile was originally wrong to begin with, the preview should have shown this UNLESS the profile was somehow highly screwed up! I guess that1s not impossible but then how did the conversion to ColorMatch Fix this issue?
> So, to restate the question, should the client be responsible since they
> embedded, or should the printer/service bureau be responsible for this CMYK
> to CMYK mismatch?Confused again. Why do you say CMYK to CMYK? Was the file (ColorPass-55) CMYK? If so, the tag isn1t the issue. Getting an untagged CMYK file would be just as problematic since you1d have to do a CMYK to CMYK conversion but you would have no idea what recipe of CMYK you got to begin with. The preview would certainly be science fiction and you1d have to 3tag2 the file with something anyway to get to your final CMYK output.
Getting a CMYK file tagged and seeing a good preview leads me to believe that the numbers in the file and the tag are in sync. How you got ugly brown files from here is what is the mystery.
Andrew Rodney
From: Brad Perkinson
Date: Sat, Feb 2, 2002, 4:04 PM
RE: Re: [colortheory] More dangers of embedded CMYK Profiles
The "ColorPass-55" profile is likely a profile of a color laser printer and that laser printer could well be in some bizarre, non-linear state so it is definitely not an accurate description of your SWOP Iris. We have a similar problem with a customer using a Fiery CMYK profile that looks good in Photoshop but has strange colors when converted to our output profiles (RGB or CMYK). I don't know if the client's profile is bad somehow or if it is such a major change (5C 3M 30Y in what is visually a light neutral on screen) that profile-to-profile just can't handle it. We have had some luck trying different combinations of rendering intents and black point compensation on or off but the best result is when we have the client convert them to RGB and then everything works fine.The initial problem is that the clients are creating CMYK files that are not suitable for "standard" printing. The embedded profile should actually solve that problem by letting you do a profile-to-profile conversion but clearly that doesn't always work.
I would think ideally the client should be responsible for using correct CMYK settings but that will be a tough sell because they have been told that in ICC color management world you should be able to take their files with embedded profiles and convert them to your output profile. Maybe someone else can explain why it doesn't work and offer a solution.
Brad
--
Brad Perkinson
Mousegraphics
1414 W 14th St
Tempe, AZ 85281
480-894-1992
brad@mousegraphics.com
From: Dan Margulis
Date: Sat, Feb 2, 2002, 4:05 PM
RE: [colortheory] Re: Embedded profiles
Dave writes,>>A job came in that had several screen shots of computer programs, along with other photos. According to the FlightCheck reports, some had no icc profile, some had sRGB, some had grayscale Gamma 2.2, and some had an icc profile called "ColorPass-V55 1100 Color Server">>
This should immediately raise red flags. It strongly suggests that the client doesn't know anything about this and that the embedded profiles are meaningless.
>>Then, there's the question of who should pay for the first round of Iris's. If this customer had not embedded, we would have assumed just another job with mediocre scans from a do-it-yourselfer. On the other hand, since they did embed, we caught the fact that these were really great scans/digital files, just with the wrong profile for our shop.>>
In the year 2002, expecting embedded profiles to be honored by another party is a highly nonstandard workflow. If Party A expects Party B to respect the profile, it's up to Party A to make sure that both are on the same wavelength. Absent such a request, if Party B decides to respect the profile nonetheless, then it's Party B's problem if things don't turn out well. That's what your company did, so it should eat the cost of the proof.
>>So, to restate the question, should the client be responsible since they embedded, or should the printer/service bureau be responsible for this CMYK to CMYK mismatch?>>
Embedded profiles, especially in CMYK files, are likely to have been embedded by mistake. If the client wants them used, it's the client's obligation to make that fact known. It's not fair to penalize the client for inadvertently throwing profiles in. If the printer decides to use them, the printer is the one who takes the responsibility.
Dan Margulis
From: steven moreno
Date: Sat, Feb 2, 2002, 7:32 PM
RE: Re: [colortheory] Re: Embedded profiles
Dan, that is an interesting perspective on client versus printer. But I thought that is why we have lawyers. If only the world was that easy
From: Stephen Marsh
Date: Sun, Feb 3, 2002, 9:24 AM
RE: [colortheory] Re: consequences of workflow change
Dave wrote:
> After following the discussion here a few weeks ago, I came upon my first
> real live instance of embedded CMYK profiles costing time and money.This can happen from following any tag - or by ignoring the tag and presuming colour input. Either way you can get burned - or get the intended results, depending on the situation.
> A job came in that had several screen shots of computer programs, along with
> other photos. According to the FlightCheck reports, some had no icc profile,
> some had sRGB, some had grayscale Gamma 2.2, and some had an icc profile
> called "ColorPass-V55 1100 Color Server"Four different types of input conditions - untagged in any mode, tagged grayscale, tagged RGB and tagged CMYK.
The untagged files will be dependent on their colour mode. A grayscale and CMYK untagged file would be presumed 'print ready' and in final form that is suitable for your conditions. These formats usually mean 'hands off' - since they are in locked final device colour modes. This is the traditional workflow, when art in grayscale or CMYK is supplied it is usually considered final unless otherwise stated by most print service providers. The images having sRGB for colour and a gamma grayscale profile would seem to indicate that the author of these images may not understand the print process or setting up colour settings in Photoshop. So right away the profiles would seem doubtful, but at least you have a place to start for the RGB conversions (as stated grayscale and CMYK would not be actively altered by you, it is only the RGB which is not print ready).
> Since ICC profiles are not something our people are used to checking, the
> job was opened (InDesign, I think) and Iris proofs run after converting all
> RGB's to our working space. (Which is close to the "SWOP 20%" profile in
> Photoshop). The converted sRGB's came out fine, but the ones with
> "ColorPass-55" came out all brownish and muddy. When I opened them on my
> monitor they looked bright and clean, which is when I discovered the
> problem.I take it that the gray (both tagged and untagged ) were left as is, with the profiles being meaningless to your traditional output workflow. I presume that untagged CMYK was not altered by you, since this was assumed to be final and press ready.
Now things get confusing. There should be no reason that you converted a CMYK file, with or without a tag - so is it correct that the ColorPass profile and file are RGB? If this is so your comments below make things sound like this is a CMYK file/profile.
So which is it, RGB or CMYK?
> I'm assuming they looked brownish and muddy because the embedded
> "ColorPass-55" profile is not an accurate description of our SWOP based
> calibrated Iris. (Which is supposed to emulate our press). Is this correct?It now sounds like the ColorPass files are CMYK with a CMYK tag. This is confusing things as the last paragraph sounded like RGB.
Try these suggestions when inspecting unknown or suspect CMYK files/profiles:
* If on a Mac, use the supplied ColorSync AppleScript or free third party tools like ProfileDestillator to pull the profile out of the image so that you can install and use the suspect profile for some deeper testing.
* Inspect the shadows (solids) for a converted solid black RGB patch with your info palette - what is the CMYK TAC? 280% 300% 360% etc.
* What is the maximum black limit reading for solids in the info palette? 70% 80% 90% etc.
* Compare a 100% C, M and Y patch of ColorPass CMYK profile to your SWOP CMYK profile assigned to the same test target. Are the LAB values for the ColorPass file similar to the SWOP CMYK profile for the same solid inks?
* Make a grayscale step chart and gradation and convert to both profiles and see how black generation (UCR/GCR) and gray balance is generated across the tonal range. Do both profiles produce similar seps?
Even with basic tests like these, you should be able to get a general feel for how the two profiles (devices) behave.
> I'm also assuming the "ColorPass-55" profile is an accurate description of
> those files when scanned or created as the grays looked gray and the colors
> balanced when opened in PS6.How do the LAB values for these files read? Do neutrals read with AB channel readings near a perfect 0, say +/- 1 to 3 points?
> We first tried doing a Convert to Profile from
> "ColorPass-55.icc" to "DIPress.icc" but got an undesirable color shift. We
> then did a Covert to Profile from "ColorPass-55.icc" to "ColorMatchRGB.icc"
> and then converted to "DIPress.icc". I would like to know why the first CMYK
> to CMYK conversion didn't work as well as going through RGB as an
> intermediate step. I would think both conversion methods would pass through
> LAB before being sent to the "DIPress.icc" profile.They both would go through LAB, but since one is a CMYK > CMYK move and the other is a CMYK > WS RGB > CMYK move I would expect some differences - usually only small but there is potential room for larger shifts. Theory states that the CMYK > CMYK move would be more accurate, since less colour transforms are taking place - but results indicate otherwise.
There are many rendering and BPC mapping decisions to make in these transforms from Client CMYK > WS RGB > Output CMYK. The greater amount of variables might lead to more room for error - but not so in this case.
In the failed conversion, the file went from Client CMYK > Output CMYK - were any conversion settings different between these two conversions? As mentioned in theory this should have been better, but your results indicate otherwise.
I wonder if it is only this profile, or if you reproduce the workflow with your own tagged files or other clients? CMYK > CMYK in theory should not have this issue. Just for curiosity, does Client CMYK > LAB > Output CMYK suffer the same issues, or does it respond like the RGB workflow?
Perhaps Photoshop's internal LAB is different to what is used in the profiles as a connection space? This is getting too deep into profile behaviour specifics which I know nothing about.
> This incident has me rethinking my strategy of embedding our shop's profile
> in all our scans. My thinking was our customers would see the scans (and/or
> corrections) as I had seen them assuming a calibrated profiled monitor and
> PS6 with a "Preserve embedded" policy. And even if they didn't, I couldn't
> see how the embedded profile could hurt... until now.This is where things get tricky. One setting I have worked in used CTP and the proofing profile was of the Epson used for producing a contract proof. Although CMYK, this was an inkjet proofing profile and not suitable for separation. So even though it provided a great monitor softproof - we did not tag it or use this profile for separation. So the question was the same as yours - what to tag the CMYK scan with? The scanner was ICC capable but the proprietary tables gave better results - so no profile was available from that quarter. We could have tagged with the separation profile used for supplied RGB data (SWOP v2 or custom CMYK table profile) - but since the workflow and users did not care about the active use of CM or profiles - none got tagged! We never had any clients ask for a profile, and if they did they would have been quoted a 'generic' custom built in CMYK setting to dial in and tag on their system. If we gave them the Epson proofing profile which provided the best softproof results - there would be the chance of them using that profile in a conversion and we would be held accountable to our profile being used in the wrong setting, rightly or wrongly. It was a catch 22 situation.
So the general consensus was that tagging CMYK profiles were pretty much ignored from a workflow aspect for any internal work or outgoing scans. Where they were needed they were set-up and forgotten (contract proofing RIP). I am not suggesting this as the ideal workflow or anything - just one real life approach.
> Then, there's the question of who should pay for the first round of Iris's.
> If this customer had not embedded, we would have assumed just another job
> with mediocre scans from a do-it-yourselfer. On the other hand, since they
> did embed, we caught the fact that these were really great scans/digital
> files, just with the wrong profile for our shop.Most printers do not touch a clients data for exactly the reasons you mention. Most have a 'all care but no responsibility' approach - where at best they will inspect things and ask questions if they spot potential issues with incoming data, or they will simply output the files as supplied and proofing shows any issues. The client pays for the next round of proofs if not happy with the initial ones, since the data needs changing either by them or by the printer to match the intended output. The original proofing is obviously built into the original job quote.
For CMYK, grayscale and duotone/spot inks, the tag is not an active issue for most print service providers. The values in the final presented file are output and proofed to the accepted proofing medium. If the numbers in the file produce a bad result for your output - it is the concern of the separator (client). Most printers accept output ready data or material as the preferred option.
If the printer is making conversions or edits to files - then the ground rules have to be established so that both parties know where they stand. If presenting RGB or LAB to a printer, the use of tags or the presumed RGB space the conversion will be based on need to be stated and it should be understood that there may be colour reproduction issues, even with LAB supplied images (which avoid many common ICC problems, as in some printers not caring for colour management).
If you altered things that were in CMYK or grayscale, then it is at your cost - whether you honor the profile or not does not matter, since an unwanted conversion took place. For RGB it will depend on the stated or agreed colour handling policy between the two parties.
> This means training the people who preflight to scour the report for
> mismatched profiles (not an easy task) and all the consequences involved
> with resolving that. As it is, they are hoping color management stays
> confined to my room as they don't want "one more problem to deal with".Either make inocming work fit your workflow from the artwork originator, or someone at your end has to do it - or the mess that results is accepted.
> So, to restate the question, should the client be responsible since they
> embedded, or should the printer/service bureau be responsible for this CMYK
> to CMYK mismatch? And yes we could post the press profile on our website,
> but I bet the downloads would be few and far between.Traditionally it is up to the separator to provide workable seps to the printer. It would be ideal if the printer or service provider could post their preferred colour settings or profile for use by clients who wish to use this method, although this does create some issues for the service provider, which may be why it is not often done. The minimum which should be done by the printer is a written spec. of the basic custom CMYK settings or printing conditions needed for Photoshop to produce an acceptable 'base' separation, with the separators understanding that separation is often subjective and that post separation edits might be needed to produce ideal results.
If your policy is to output supplied CMYK as is - then it is the clients concern to supply the right seps (this process can be helped by asking the service provider for details, settings or profiles).
If your policy is to make whatever CMYK you are given work - then it is your duty to do this.
Sorry about the long winded reply, but this is a subject which has been an issue for me in the past and probably in the future.
Hope this helps,
Stephen Marsh.
From: Dave Badger
Date: Sun, Feb 3, 2002, 4:35 PM
RE: Re: [colortheory] More dangers of embedded CMYK Profiles
Andrew Rodney wrote:>>You have to get to the bottom of why the images got so ugly. It makes no
sense that viewing the tagged files looked good and then something happened
to make them ugly after a conversion.>>Ok, let me try to clarify; all the images that came in with the "ColorPass-V55 1100 Color Server" tag were already CMYK, the conversion having been done in an unknown program. I suspect some kind of a color server based on the full name of the tag. The rest were RGB files tagged with "sRGB" which we manually converted in our Photoshop. Then the whole job was sent from InDesign to our Iris for proofs.
The ones we converted from sRGB to "DIPress.icc" came out fine. The CMYK "ColorPass-55" images sent untouched to the Iris came out ugly. When I checked out these images on my monitor, they looked great and were tagged with the "ColorPass-55" profile. I then went to 'Assign Profile" and temporarily changed it to the "DIPress.icc" profile upon which the preview changed to reflect the ugly Iris's. This is when I came to the conclusion:
> I1m not clear what you mean. You opened the files (which are tagged) and they
> looked OK. So there shouldn1t be a problem here. That is, if the tag were
> wrong, the image should preview incorrectly.Are you saying as long as the CMYK preview and tag are correct, then they should output just as seen directly to the Iris?(or other output device). I understand in an RGB workflow, the proper conversions should take place so that color A in the original matches color A on the output. But in a CMYK workflow, we send the images (regardless of where they came from) directly to the Iris (no conversions in PS). So the only thing I could think of is that the CMYK values that produced correct color through the "ColorPass-55" profile, produced incorrect color when sent through the Iris's "DIPress Profile". (As the Iris rip ignores CMYK embedded tags??).
> So at what point did the files end up ugly and brown?
> You have to get to the bottom of why the images got so ugly. It makes no sense
> that viewing the tagged files looked good and then something happened to make
> them ugly after a conversion.When sent directly from InDesign to the Iris, we did no conversions.
> If the embedded profile was originally wrong to begin with, the preview should
> have shown this UNLESS the profile was somehow highly screwed up! I guess
> that1s not impossible but then how did the conversion to ColorMatch Fix this
> issue?In order to fix it, we first tried a "Convert to Profile" of the CMYK images tagged with "ColorPass-55.icc" to "DIPress.icc". The preview showed some undesirable color shifts. I've always heard a CMYK to CMYK conversion like this should be avoided, but need to understand why.
So we next tried a "Convert to Profile" of the CMYK images tagged with "ColorPass-55.icc" to "ColorMatchRGB.icc". This, of course converted to images to RGB, but the color preview remained the same. Then we converted from "ColorMatchRGB.icc" to "DIPress.icc" with acceptable results and sent those files to the Iris. (Which came out much better).
> Why do you say CMYK to CMYK? Was the file (ColorPass-55) CMYK?(Yes) If so, the tag
> isn1t the issue. Getting an untagged CMYK file would be just as problematic
> since you1d have to do a CMYK to CMYK conversion but you would have no idea
> what recipe of CMYK you got to begin with.Understood. But does this mean you recommend taking all incoming CMYK files and converting them through Photoshop or iQueue to our in house profiles? (Assigning untagged files with a best guess assumed profile)? Again, I thought it was best to leave CMYK files alone, and then if the customer is unhappy with the proof, make corrections in Photoshop.
One other thought; this is the first time we've noticed such a drastic difference between Photoshop preview and output, and we also rarely use Adobe InDesign. Could it have some color management options that would mess with a CMYK file?
Thanks again,
Dave Badger
From: Andrew Rodney
Date: Sun, Feb 3, 2002, 4:36 PM
RE: Re: [colortheory] More dangers of embedded CMYK Profiles
Dave Badger wrote:> Ok, let me try to clarify; all the images that came in with the "ColorPass-V55
> 1100 Color Server" tag were already CMYK, the conversion having been done in
> an unknown program. I suspect some kind of a color server based on the full
> name of the tag. The rest were RGB files tagged with "sRGB" which we manually
> converted in our Photoshop. Then the whole job was sent from InDesign to our
> Iris for proofs.There are not that many programs that would tag the image with a profile.
But none the less, you have two options:1. Believe that ICC profiles are the cause of evil in the world and assume (as Dan does) that most tags are incorrect.
2. Open the file and view it on a calibrated display with the tag and see if
it looks funny or not. If it looks really odd, you can now suspect that someone tagged the file incorrectly (or the file is just plan ugly).Since there are few applications around that do tag files (the most common being Adobe Photoshop and with that application, a least version 6, it1s difficult to tag the file incorrectly), simply looking at the numbers WITH the profile can provide you some information. You can also use the soft proof features in Photoshop and pick your house profile (or use the Assign profile command) and you will see what the existing numbers would look like IF you simply sent them to your output device. This is VERY powerful. You don1t alter the data one lick but you view the data going to your device.
At this point you have to decide a few things. If the file looks OK with the tag, do you want to do a conversion from the EXISTING numbers to your output device (Convert to Profile) or simply send the numbers to your device.
Since the file has a tag (correct or not), we are able to see the numbers as the customer saw them. The numbers are the numbers you got. The tag doesn1t alter this one bit! If the customer gave you goofy numbers that would produce ugly output, the blame is on their heads. BUT!!!!.. By tagging the file, they have at least provided some idea of what they wanted. They may have provided CMYK optimized for newsprint and expect you to print on coated paper (ugly output) but their intentions where provided with the tag.
Lets look at the other side of the equation. We like to believe (like Dan) that anyone that provides a file that is tagged is kind of stupid and didn1t tag the file correctly. I guess the tag showed up on it1s way from the customer in the currier1s van. Anyway, let1s assume it1s of no use. Fine, you open the file in Photoshop to inspect it and remove the tag. Now you are viewing the file in whatever CMYK space you have set in color pref1s. That could be your house profile. Again, you haven1t changed anything here. You get to see how the numbers in the file will appear if you send them to your printer (but you need a profile, god forbid, for your printer).
But if you must convert, you1ve lost the tag (be it accurate or not) so you get to guess what the SOURCE is for conversion. Let1s say you decide that in the past, a conversion back to RGB fixed the issue. OK, you1ve hosed the original tag so what source is being used to go from CMYK to RGB? Again, a guessing game.
Tags don1t change the data in your file until you make some kind of conversion. The number are either going to produce good output or they will not. If you decide that your policy is to take any CMYK file you get and send those numbers to the output device (and the customer is responsible for the numbers they provide), having or not having a tag is moot. But if you decide that when a custom provides you with CMYK numbers, you need to decide if the output will be good or not, only the Tag will assist you. It1s a starting point in understanding what the INTENT of the customer was. We all know some (a lot?) of customers don1t have a bloody clue what CMYK numbers to provide. They had the scans made elsewhere or someone in the chain did the CMYK conversions. If you, yourself didn1t do the conversions, then you have to make some guesses (and simply sending all files to the printer and then seeing the results is very counter productive).
So, you can decide that any tag is simply the result of some stupid user or you can view the file as such and make decisions from there. You can decide that proper education to users about the benefits of embedding a profile will make your life easier or you can continue to believe that communicating color (which is what tags do) is for idiots. Tagging a file incorrectly isn1t impossible. But it isn1t as easy as some would lead you to believe. And if the tag is wrong, no worries as long as you know how to investigate the issues. Proposing that tagging files is a bad idea only keeps numbers ambiguous. Tags are only a method of communication.
> Are you saying as long as the CMYK preview and tag are correct, then they > should output just as seen directly to the Iris?
No, I1m saying the numbers in the file are sound based on the tag and that you should be able to:
1. View the numbers unaltered and see what they would produce on the Iris if you just sent them out to that device (no conversion).
2. View the numbers altered if you did a conversion using this original tag as a source for a conversion and Iris as the destination.
3. See what the user saw (what was his intent) and what the numbers would look like to his device (tagged profile).With no profile, you get nada (well you can see what those numbers would look like to your Iris with an Iris profile assigned or soft proofed but you1ll need a profile for your Iris).
> I understand in an RGB workflow, the proper conversions should take place so
> that color A in the original matches color A on the output. But in a CMYK
> workflow, we send the images (regardless of where they came from) directly to
> the Iris (no conversions in PS). So the only thing I could think of is that
> the CMYK values that produced correct color through the "ColorPass-55"
> profile, produced incorrect color when sent through the Iris's "DIPress > Profile".EXACTLY!!! You1ve got it. With the tag, you can see all this before you output the file (on a profiled display). As I said above, if your policy is to take any CMYK file and output without conversion, then the tag is useful. You can provide your Iris profile to the customer and tell them 3assign our Iris profile to your file that is now in ColorPass-55 and see how ugly it will look.2 Now they can re-separate from the original RGB data OR decide they need to convert from ColorPass-55 to Iris (or DIPress) profile. You can put the responsibility to get the correct CMYK numbers for your device back into their hands. They can see how dumb it is to send you a file in
ColorPass-55.> In order to fix it, we first tried a "Convert to Profile" of the CMYK images
> tagged with "ColorPass-55.icc" to "DIPress.icc". The preview showed some
> undesirable color shifts.Exactly! The CMYK numbers for ColorPass-55 isn1t the correct set of numbers for Iris or DIPress.
> So we next tried a "Convert to Profile" of the CMYK images tagged with
> "ColorPass-55.icc" to "ColorMatchRGB.icc". This, of course converted to images
> to RGB, but the color preview remained the same. Then we converted from
> "ColorMatchRGB.icc" to "DIPress.icc" with acceptable results and sent those
> files to the Iris. (Which came out much better).Well it1s strange that this didn1t happen in the above step (ColorPass-55 to DIPress). But, if going to RGB solved the problem, fine. You could not have produced the same conversion to RGB had you not had the original ColorPass-55 tag. Any colorspace conversion requires a source and destination. In this case the original tag was used. The bottom line was that you were able to fix the problem (although going back to the original RGB scan would have been better).
> But does this mean you recommend taking all incoming CMYK files and converting > them through Photoshop or iQueue to our in house profiles?
Yes if you want the best possible output and want to take on this extra work. You have a device that requires a specific set of CMYK values and your customers are providing you a set of CMYK numbers for other devices. To get to the aim point you need to convert. IF the numbers you are provided are close to your eventual aim point, the output will be pretty good. If the numbers you are provided are a mile off, the output will be a mile off (which may be something you want if the policy is to take any CMYK number provided and simply output). But if the idea is to get YOUR CMYK device to produce the closest intent of the customer, AND the customer provides a tagged file, you can use both profiles to get to the desired CMYK numbers. With no tagged profile from the customer, you can1t do this.
> One other thought; this is the first time we've noticed such a drastic
> difference between Photoshop preview and output, and we also rarely use Adobe
> InDesign. Could it have some color management options that would mess with a
> CMYK file?Trust Photoshop. But InDesign 2.0 (which I just got the other day) seems to
have color settings that are virtually identical to Photoshop 6. I can1t
comment on the two being a match but I can say that Photoshop (with a
profiled display) will preview correctly. I assume InDesign 2.0 will too.Andrew Rodney
From: Dave Badger
Date: Mon, Feb 4, 2002, 12:14 AM
RE: Re: [colortheory] More dangers of embedded CMYK Profiles
Andrew Rodney wrote:> Tags don1t change the data in your file until you make some kind of > conversion. The number are either going to produce good output or they will > not.
Thank you for an extraordinary helpful response. Your "meaning of the numbers" approach is the only way I can mentally visualize what's happening in Photoshop.
Thanks again,
Dave Badger
From: Dave Badger
Date: Mon, Feb 4, 2002, 12:13 AM
RE: Re: [colortheory] Re: consequences of workflow change
Stephen Marsh wrote:> Now things get confusing. There should be no reason that you converted a
> CMYK file, with or without a tag - so is it correct that the ColorPass
> profile and file are RGB? If this is so your comments below make things
> sound like this is a CMYK file/profile.I apologize for not being more precise on that point and it caused a lot of confusion. The images with the "ColorPass-55.icc" profile were CMYK when we received them.
I meant this to be a discussion of CMYK profiles in the workflow. Receiving RGB files with or without a proper tag almost seem more straight forward now. I think assuming all CMYK files are print ready is the safe way to go and then charging for corrections if the customer is unhappy with the proofs. In this case the customer had marked "check all color" on the 1st round proofs so they knew something wasn't right but didn't know what. When I saw what the "ColorPass-55.icc" profile did for the images, it was hard to ignore.
> In the failed conversion, the file went from Client CMYK > Output CMYK -
> were any conversion settings different between these two conversions? As
> mentioned in theory this should have been better, but your results indicate
> otherwise.No, same settings. I wouldn't call it a "failed" conversion, just not as good as the Client CMYK > WS RGB > Output CMYK approach. This surprised me. Maybe a Client CMYK has a vasly different black generation which doesn't translate accurately into LAB, so the Output CMYK isn't optimal. This is why Scitex creates DeviceLink profiles-so that each of the four channels is passed directly to the Output space bypassing a reconversion from LAB.
> So the question was the same
> as yours - what to tag the CMYK scan with? The scanner was ICC capable but
> the proprietary tables gave better results - so no profile was available
> from that quarter. We could have tagged with the separation profile used for
> supplied RGB data (SWOP v2 or custom CMYK table profile) - but since the
> workflow and users did not care about the active use of CM or profiles -
> none got tagged!On a related note, you've talked several times about how if edits are make to a CMYK image then the tag is no good anymore. Is this because the edits have created a "new" color space that the profile no longer describes? And is this an issue only when you to do a CMYK>CMYK conversion, or do you consider the original profile no good for previewing also?
> Try these suggestions when inspecting unknown or suspect CMYK
> files/profiles:> * If on a Mac, use the supplied ColorSync AppleScript or free third party
> tools like ProfileDestillator to pull the profile out of the image so that
> you can install and use the suspect profile for some deeper testing.Do you have any links? I'd like to follow through with this type of testing.
> Most printers do not touch a clients data for exactly the reasons you
> mention. Most have a 'all care but no responsibility' approach - where at
> best they will inspect things and ask questions if they spot potential
> issues with incoming data, or they will simply output the files as supplied
> and proofing shows any issues.About half our work is printed in house on our short run presses. In the end the customer only care if the images came off the press how he/she envisioned it. They don't care about all the calibration/color management garblelygook that took place inbetween. Their monitor > your press. Better educated clients would be nice, but doesn't seem to be our market. One faction argues we should do whatever it takes to produce good images off the press and corrections/conversions are part of that cost. Another faction argues that we give 'em what they gave us and move on. In a highly competitive market, I vote for the former.
Regards,
Dave Badger
From: Stephen Marsh
Date: Mon, Feb 4, 2002, 9:43 AM
RE: Re: [colortheory] Re: consequences of workflow change
> On a related note, you've talked several times about how if edits are make
> to a CMYK image then the tag is no good anymore. Is this because the edits
> have created a "new" color space that the profile no longer describes? And
> is this an issue only when you to do a CMYK>CMYK conversion, or do you
> consider the original profile no good for previewing also?Not really - it is just gray balance which concerns me, if other conversions are taking place off the CMYK file if it has a tag (the tag is trusted).
In a basic RGB > CMYK the gray balance is fine, it matches the separation profile. If you make no edits and convert back to another mode from this tagged file which has not been edited in CMYK - then the results should be close to the original file (apart from contrast issues from TAC and black ink limits). Since the numbers in the file match the profile in gray balance - all the conversions work as intended.
If you do not care about the profile after separation and only consider it a 'start point', fine - this means more knowledge and skill is required in CMYK. Make all edits to the separated data and use whatever gray balance and other specifications that your local conditions aim for. There are probably neutral gray aimpoints which are followed or something.
Or convert RGB > CMYK and make edits in CMYK - but follow the gray balance indicated in the profile. Now if the tag is kept and a conversion is made off the tag - neutrals are not hosed.
> Do you have any links? I'd like to follow through with this type of testing.
The ColorSync AppleScripts are probably in your ColorSync or AppleScrit scripts folder on your hard drive (if you did not clean up all of the install) or on the Mac OS CD - I have never used them.
I have sent you the Mac only freeware utility off list - please virus check before use.
> About half our work is printed in house on our short run presses. In the end
> the customer only care if the images came off the press how he/she
> envisioned it. They don't care about all the calibration/color management
> garblelygook that took place inbetween. Their monitor > your press. Better
> educated clients would be nice, but doesn't seem to be our market. One
> faction argues we should do whatever it takes to produce good images offthe
> press and corrections/conversions are part of that cost. Another faction
> argues that we give 'em what they gave us and move on. In a highly
> competetive market, I vote for the former.
I agree Dave, you can't afford to make clients unhappy - and the service provider role is not always fun.<g>
Sincerely,
Stephen Marsh.
From: Andrew Rodney
Date: Mon, Feb 4, 2002, 9:46 AM
RE: Re: [colortheory] Re: consequences of workflow change
Dave Badger wrote:
>Receiving RGB files with or without a proper tag almost seem more straight forward
> now.You think? How come? You still don1t have a description of the RGB numbers and you have to end up with CMYK so you have to assume something about the numbers which is just as dangerous as assuming something about CMYK numbers. In fact, untagged RGB isn1t any better or worse than untagged CMYK as far as tags. At least an RGB file can be separated into CMYK with a lot less damage and hassles once you know the meaning of the RGB numbers (with a tag).
> I think assuming all CMYK files are print ready is the safe way to go
> and then charging for corrections if the customer is unhappy with the
> proofs.RGB is print ready too. It1s just not the colorspace you use to print. But lots of people have devices that you send RGB to and an untagged RGB file is just as close OR far away from the optimal numbers for that printer as untagged CMYK.
> On a related note, you've talked several times about how if edits are make
> to a CMYK image then the tag is no good anymore. Is this because the edits
> have created a "new" color space that the profile no longer describes? And
> is this an issue only when you to do a CMYK>CMYK conversion, or do you
> consider the original profile no good for previewing also?Editing an existing CMYK in no way invalidates the tag unless that edit was a colorspace conversion. You are viewing the data through the original profile and making edits. The preview accurately reflects the edits. The tag still describes the numbers for the preview and resulting (if necessary) conversion (where a new tag would be inserted).
> About half our work is printed in house on our short run presses. In the end
> the customer only care if the images came off the press how he/she
> envisioned it.Then you need to supply the ICC profile for your Iris (or press or whatever you have that describes the condition of your print process). They can then see on their (hopefully) calibrated display what the color will look like to your device with THEIR numbers. OR better, they can convert RGB to CMYK using that profile which is ideal. Or they can view RGB data with your profile and let you convert to CMYK with that profile latter in the chain. But they saw what they will get because you allowed them to soft proof their RGB with your profile. Of course they have to have their RGB tagged or all bets are off.
Andrew Rodney
From: "Jerry L. P'Simer"
Date: Mon, Feb 4, 2002, 11:21 PM
RE: Re: [colortheory] Re: consequences of workflow change
Andrew Rodney wrote:> Editing an existing CMYK in now way invalidates the tag unless that edit was
> a colorspace conversion. You are viewing the data through the original
> profile and making edits. The preview accurately reflects the edits. The tag
> still describes the numbers for the preview and resulting (if necessary)
> conversion (where a new tag would be inserted).Are you saying that it is impossible to change color spaces through ps edits which would invalidate the profile used for conversion?
Jerry P'Simer
From: Bob Smith
Date: Mon, Feb 4, 2002, 11:20 PM
RE: Re: [colortheory] Re: consequences of workflow change
Andrew Rodney wrote:> Editing an existing CMYK in now way invalidates the tag unless that edit was
> a colorspace conversion.It does if someone does the editing by trying to achieve certain numbers rather than by relying on making the image look good on the monitor. I'm guessing that there are a lot of people on this list that have routinely worked that way for ages. That's probably at least partially because of the fact that former versions of Photoshop were not nearly as elegant at delivering a reliable monitor proof. People got used to editing CMYK strictly by trying to achieve highlight or gray balance numbers that they knew their conditions required while paying relatively little attention to the monitor display. Do that in an embedded profile workflow and you confuse anyone who gets the image downstream and assumes that the profile embedded is accurate.
Bob Smith
From: Dave Badger
Date: Tue, Feb 5, 2002, 8:34 AM
RE: Re: [colortheory] Re: consequences of workflow change
Andrew Rodney wrote:> You think? How come? You still don1t have a description of the RGB numbers
> and you have to end up with CMYK so you have to assume something about the
> numbers which is just as dangerous as assuming something about CMYK numbers.True, but I was thinking in terms of we *have* to open RGB files in PS and convert to our shop output space. If it's untagged, and the operator so inclined, you'd have a fair chance of subjectively using one of Photoshop predefined RGB working spaces as the assumed profile and while you have the image open, tweak the CMYK if necessary. In any case the client who sends us untagged RGB's can only expect our "best effort" to convert.
With supplied CMYK's how can we have any clue as to how close or how far their separation is from our output CMYK? We could open the image and if deemed to have an accurate tag do a CMYK>CMYK Convert to Profile to our output profile, but if untagged, you can't even begin to guess at an assumed profile. If I look at the file through a soft proof of the shop's output profile, am I looking at a lousy sep make through the correct profile (let's say SWOP, which is close to the shop's profile), or am I'm looking at a good sep make through the wrong profile? In any case, as soon as we open that CMYK image, we've taken liability for that color and with 75% of the images supplied in CMYK, we can't take the time or chance altering the supplied file.
In the case I first cited, it turned out the "ColorPass-55" profile was from a Canon Color laser rip, so the difference between that and our SWOP based output was obvious. Most cases, we would never know if the supplied sep was our of sync with our output space.
> Then you need to supply the ICC profile for your Iris (or press or whatever
> you have that describes the condition of your print process). They can then
> see on their (hopefully) calibrated display what the color will look like to
> your device with THEIR numbers. OR better, they can convert RGB to CMYK
> using that profile which is ideal.I agree this would be ideal, but one, I'm still tweaking our profiles as different problems show up, and two, if the customer is their not happy with the color, all they have to say is "but I used your profile". Then we're into a big blame game.
Dave Badger
From: Andrew Rodney
Date: Tue, Feb 5, 2002, 4:52 PM
RE: Re: [colortheory] Re: consequences of workflow change
Bob Smith wrote:> It does if someone does the editing by trying to achieve certain numbers
> rather than by relying on making the image look good on the monitor. I'm
> guessing that there are a lot of people on this list that have routinely
> worked that way for ages.The description of the numbers is still honored by the edit AND the tag is
used if any further colorspace conversion takes place. Plus as you say, the
preview remains faithful to the edit. I don1t see any issues with the tag
after editing a file. Files (with and without tags) are meant to be edited.Andrew Rodney
From: Andrew Rodney
Date: Tue, Feb 5, 2002, 4:52 PM
RE: Re: [colortheory] Re: consequences of workflow change
Bob Smith wrote:> After editing a file without regard to the preview (correcting by the
> numbers) the embedded profile is still correct in that accurately shows how
> the file will look on the device the profile describes, so I guess that
> technically you could say that the profile is accurate.Yes plus should someone need to do a CMYK to CMYK conversion (for proofing), the original profile is still needed and will allow the new edits to be honored.
>However it is not faithful to what the editors intentions were (printing on a >device different from what the profile describes) and that is where the
>confusion arises.No image editing after the fact is. That really has nothing to do with the profile. If you un-tag the profile or assign a different profile, the preview changes and so does any subsequent conversions. So the profile really didn't hurt and (unless you do a conversion) doesn't do anything anyway.
> I get a file in with an embedded profile indicating
> that the image was prepped for SWOP. I look at the numbers and decide that
> its not going to print correctly on my press so I edit the CMYK to values
> that will work on my press with no regard to the profile or the monitor
> display. In essence I'm manually doing what would be accomplished in a
> profile to profile conversion.Well maybe. It's semantics at this point. Yes, doing a Convert to Profile would alter every pixel and update the tag. Doing a global edit alters all the pixels too and leaves the tag set as it was originally. Again, I don't see this being more than a decision to alter the numbers using edits within Photoshop or using a profile to do a conversion. One is fine control and the other is a very brutal, heavy handed edit (using a conversion). I guess if stuck in such a position, if I found that some slight editing was in order, I'd use many of Dan's techniques like channel editing to get to my aim point. If I needed to convert say SWOP coated to newsprint, doing a CMYK to CMYK conversion (with perhaps additional edits in PS after) might be faster, easier and ultimately better. The new condition would be updated in the new tagged profile, no problem.
> The SWOP profile is still in the file and will be saved with it if I have
> PS6 prefs set to US Prepress DefaultsThe original profile will be saved regardless of what you set in Color Preferences (unless you turned your policy to OFF).
> That's all fine and dandy
> until that file gets handed off to someone else. Maybe someone pulls the
> file out of an archive a few months later to print in a totally different
> type of job. Now when opened, the file still has the SWOP profile so its
> displayed like it would print in SWOP, not like it printed when used on my
> press.If the original profile remained (as I think it should), then it will look ugly and someone should take notice. Or if they read by the numbers, as so many here support, they will SEE the file isn't set correctly based on the numbers.
I'd suggest that when you did the work above, you do it on a copy! That way the original file numbers/tag is intact. Anytime you take a file in output space (be it CMYK or RGB) and edit it, it's no longer optimized for the original output device. So tag or not, you would be advised to keep a new copy of the edited file IF you think someone would go back months latter and hope to take the file to a different device (or better, just archive the file in an RGB Working Space and re-convert for any device you have a profile for). Repurposing a file in output space is a recipe for disaster and just a lot of counter productive work! That's why we have color management. IF all you need to do is produce one set of numbers for one device, you don't need tags, profiles, calibrated displays or RGB archives. If you do need to repurpose files, you need the above.
> If someone other than the person who did the editing is opening the
> file, what they see on screen is confusing and difficult to sort out.Not if they work by the numbers. And if they work visually (and by the numbers), the original tag with the new pixel editing shows them what they would get. But how many rounds of edits does one put up with? Go back to the original SWOP file with tag and send it out to your SWOP device.
Andrew Rodney
From: Andrew Rodney
Date: Tue, Feb 5, 2002, 4:51 PM
RE: Re: [colortheory] Re: consequences of workflow change
Dave Badger wrote:> True, but I was thinking in terms of we *have* to open RGB files in PS and
> convert to our shop output space. If it's untagged, and the operator so
> inclined, you'd have a fair change of subjectively using one of Photoshop
> predefined RGB working spaces as the assumed profile and while you have the
> image open, tweak the CMYK if necessary.The same can be said of CMYK. Picking a predefined CMYK space might work, might not. Without a tag, it1s simply a guessing game.
> In any case the client who sends us
> untagged RGB's can only expect our "best effort" to convert.The same could be said of clients sending CMYK. But I understand that IF you sell input and/or you want total control over conversions, one could hardly blame you for simply taking any set of CMYK numbers you get and sending that to your output device. The client gets what he gets.
> With supplied CMYK's how can we have any clue as to how close or how far
> their separation is from our output CMYK?If it1s tagged, yes.
> We could open the image and if deemed to have an accurate tag do a CMYK>CMYK
> Convert to Profile to our
> output profile, but if untagged, you can't even begin to guess at an assumed
> profile.Right. Untagged CMYK is very problematic.
> If I look at the file through a soft proof of the shop's output
> profile, am I looking at a lousy sep make through the correct profile (let's
> say SWOP, which is close to the shop's profile), or am I'm looking at a good
> sep make through the wrong profile?You are viewing their numbers through your output device. If it looks lousy, it1s likely a bad conversion for YOUR device. Might look great to the originally intended device (if it1s tagged, how does it preview?).
> In any case, as soon as we open that
> CMYK image, we've taken liability for that color and with 75% of the images
> supplied in CMYK, we can't take the time or chance altering the supplied
> file.Understood. Then customers should know any CMYK they supply will output as is to your device and if they have your shop profile, they can view that prior to even sending you the file. It would be one less area where they could say 3we didn1t know it would output so ugly.2
> In the case I first cited, it turned out the "ColorPass-55" profile was from
> a Canon Color laser rip, so the difference between that and our SWOP based
> output was obvious. Most cases, we would never know if the supplied sep was
> our of sync with our output space.Well you can now see that a Canon Laser CMYK numbers are vastly different than your numbers so that1s why the output (could have been the preview) looked so bad. Tagged or untagged, some numbers are so far from their aim point (this being a good example), that you just have to wonder if anyone had a clue on the customer end in providing this file. But with the tag, you were able to see the issue and fix it.
> I agree this would be ideal, but one, I'm still tweaking our profiles as
> different problems show up, and two, if the customer is their not happy with
> the color, all they have to say is "but I used your profile". Then we're
> into a big blame game.Just let them use the profile for soft proofing then. Yes, ideally you1d want the golden version of a profile in case they do decide to use it to convert from RGB. But if you tell them you need to control conversions and the profile is only for preview purposes, at least they can get an idea how awful a Canon Laser CMYK file would look to your printer.
Andrew Rodney
From: Tracy Williams
Date: Tue, Feb 5, 2002, 4:50 PM
RE: Re: [colortheory] consequences of workflow change
Hi all.
I have been following this thread and after reading today's postings would like to comment. I am still *old school*. I haven't made the switch to Photoshop 6 (and what I read on this list makes me even more hesitant to upgrade), I correct by *numbers* (I still don't trust monitors. My final product will not be an image on a monitor, it will be ink on paper.), and I try to give the shop that will print my critical jobs a sample disk of images that I have done cmyk conversions on to evaluate before I turn over the entire job. Some printers have even offered to make proofs from the sample files so that we can both be comfortable with how my files will translate in their system. Then, if their pre-press department sees anything grossly out of whack, I can adjust my files before I put the a job full of images thay they would need to tweak in their laps.This workflow has been successful for me. The pre-press department won't get as many unpleasant surprises and neither will I.
Tracy Williams
From: Bob Smith
Date: Tue, Feb 5, 2002, 4:52 PM
RE: Re: [colortheory] Re: consequences of workflow change
Andrew Rodney wrote:> The description of the numbers is still honored by the edit AND the tag is
> used if any further colorspace conversion takes place. Plus as you say, the
> preview remains faithful to the edit. I don1t see any issues with the tag
> after editing a file. Files (with and without tags) are meant to be edited.After editing a file without regard to the preview (correcting by the numbers) the embedded profile is still correct in that accurately shows how the file will look on the device the profile describes, so I guess that technically you could say that the profile is accurate. However it is not faithful to what the editors intentions were (printing on a device different from what the profile describes) and that is where the confusion arises.
Take this scenario. I get a file in with an embedded profile indicating that the image was prepped for SWOP. I look at the numbers and decide that its not going to print correctly on my press so I edit the CMYK to values that will work on my press with no regard to the profile or the monitor display. In essence I'm manually doing what would be accomplished in a profile to profile conversion. From past posts and from what Dan teaches, its clear that many on this list and in the industry at large work that way. The SWOP profile is still in the file and will be saved with it if I have PS6 prefs set to US Prepress Defaults (A common and sensible choice which turns on preserve embedded profile). After editing, the numbers in the file are correct to make the file print on my device, but the display probably doesn't look like what the original creator of the file saw while editing and viewing the file with his SWOP profile. I don't care... I know its going to print like what he wants on my press. That's all fine and dandy until that file gets handed off to someone else. Maybe someone pulls the file out of an archive a few months later to print in a totally different type of job. Now when opened, the file still has the SWOP profile so its displayed like it would print in SWOP, not like it printed when used on my press. If someone other than the person who did the editing is opening the file, what they see on screen is confusing and difficult to sort out.
To me, the above is a good argument for keeping an accurate profile... one that accurately describes how the file will print on the intended device... attached to the file at almost all times. Edit all you want by the numbers, but have a profile that accurately describes what your numbers mean and keep that attached to the file so others can tell what you did an why. I point out the above just to illustrate how some on this list will hit snags from time to time with profiles. Unfortunately the response is too often to try to avoid anything remotely resembling a profile. If you're passing those files around, that only adds to the confusion. It doesn't reduce it.
Bob Smith
From: Dan Margulis
Date: Wed, Feb 6, 2002, 12:42 PM
RE: Re: [colortheory] Re: consequences of workflow change
Bob writes,>>Take this scenario. I get a file in with an embedded profile indicating that the image was prepped for SWOP. I look at the numbers and decide that its not going to print correctly on my press so I edit the CMYK to values that will work on my press with no regard to the profile or the monitor display. In essence I'm manually doing what would be accomplished in a profile to profile conversion. From past posts and from what Dan teaches, its clear that many on this list and in the industry at large work that way.>>
Many do, and there are a largish number of other ways for incorrect profiles to creep in. Embedding profiles in CMYK is a very different animal from doing so in RGB.
>>To me, the above is a good argument for keeping an accurate profile... one that accurately describes how the file will print on the intended device...attached to the file at almost all times. Edit all you want by the numbers, but have a profile that accurately describes what your numbers mean and keep that attached to the file so others can tell what you did an why.>>
It's definitely a PITA to do this, so one must ask whether the benefits (if any) outweigh the risks.
>>I point out the above just to illustrate how some on this list will hit snags from time to time with profiles. Unfortunately the response is too often to try to avoid anything remotely resembling a profile. If you're passing those files around, that only adds to the confusion.>>
Considering that at least 99% of CMYK work does not involve conversion based on CMYK profiles, and that 100% of all CMYK work prior to 1998 did, it is very difficult to understand what confusion is being referred to. Nobody other than color management vendors appears to perceive any.
The benefits of sinking tags into CMYK files are as I see it, as follows.
1) If the user dies or is otherwise utterly unavailable for consultation, conceivably the profile may help somebody down the line understand what was going on, probably not. If the user is not dead, he is either sophisticated, in which case he will not want anybody to act on that profile without previous discussion, or unsophisticated, in which case the profile is meaningless. And, if the sophisticated user has to discuss with the next person that a conversion is necessary, then there isn't any need for an embedded profile in the first place.
2) It keeps the few color management vendors who have not realized that this particular application is a lost cause, happy.
The disadvantages are:
1) Unlike RGB profiles, where I'm not aware of any reported conversion problems, conversions from CMYK do not appear to be stable enough for most professionals. Situations like the one reported by Dave aren't uncommon, where in principle the conversion should work and in practice it doesn't. When it happens, the normal result is the one Dave now enjoys, viz., a) he eats the cost of the job; b) he cheeses off the client; c) he gets to practice his troubleshooting skills, for which he can charge nobody.
2) As we have previously seen here, there exist firms such as Dave's that apparently see an embedded profile as a license to convert. In many cases that leads to a ruined job.
Considering the exceedingly limited upside of embedding, and the very real threat of ruined jobs, the choice seems very easy. In my book, I advocated embedding CMYK profiles only when the CMYK is substantially different from SWOP. That's the way I felt at the time, but so many of these snags have popped up since then that I now would not embed even in that case.
Dan Margulis
From: Andrew Rodney, andrew@digitaldog.net
Date: Wed, Feb 6, 2002, 2:24 PM
RE: Re: [colortheory] Re: consequences of workflow change
Dan Margulis wrote:> And, if the sophisticated user has to discuss with
> the next person that a conversion is necessary, then there isn't any need
> for an embedded profile in the first place.IF the user is working in Photoshop 5 or 6.... a profile will be used to do that subsequent conversion. There isn1t a way to do a colorspace conversion WITHOUT a profile in these applications. If you want to simply remove the tag, a conversion with a profile in these applications will take place none the less. The difference is the Working Space CMYK profile will be used for the source and that1s very likely not the correct profile to be using.
> 1) Unlike RGB profiles, where I'm not aware of any reported conversion
> problems, conversions from CMYK do not appear to be stable enough for most
> professionals.So you convert from CMYK back to RGB? A profile needs to be used. You simply send the same numbers provided to the device? You get ugly output (as we heard from Dave). If any kind of conversion is going to take place, a profile will be used at least in any modern version of Photoshop. Or are you suggesting you can fix all this using standard tools? That1s fine. Laborious
but fine. It isn1t the only way to fix the issue.> Situations like the one reported by Dave aren't uncommon,
> where in principle the conversion should work and in practice it doesn't.The conversion did work. He fixed the problem using profiles and conversions. He had a profile for his house device. He used a profile to get back to RGB.
> 2) As we have previously seen here, there exist firms such as Dave's that
> apparently see an embedded profile as a license to convert. In many cases
> that leads to a ruined job.Dave has two options and it has NOTHING to do with profiles! He can send the numbers he is supplied (by an admittedly bone headed customer who gave him CMYK optimized for a laser printer) or he can convert. Which route he takes is a business/service decision, not a color management decision (unless his business decision is to fix the numbers by converting from Laser Printer CMYK ultimately to his house printer CMYK). The issue wasn1t that he had an embedded profile, the issue was he got bad CMYK numbers. All the profile did was allow him to see what his customers intent was (to the Laser), what his output would look like if he simply sent those numbers to his printer (Ugly output) and a way to get from the supplied CMYK to a new set of CMYK values. In the future, any tagged CMYK file will be a nice indicator of what might possibly happen if he sends the numbers to his printer. Can you possibly explain why that would be a bad thing Dan?
Bad numbers are bad numbers. Profiles don1t affect that issue, they only allow users to see and if necessary convert/correct. Profiles don1t kill jobs, people kill jobs.
> In my book, I advocated
> embedding CMYK profiles only when the CMYK is substantially different from
> SWOP.This is exactly what happed to Dave (unless you feel that Laser Printer CMYK is remotely similar to SWOP). Oh, please define SWOP (not as SWOP in their spec does but as every printer who has a different printer behavior that is supposed to be SWOP).
Andrew Rodney
Adobe Photoshop training classes are taught in the US by Sterling Ledet & Associates, Inc.