consequences of workflow change


Stephen Marsh <samarsh@...>
 

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 Covert 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.


Dave Badger <dbadge@...>
 

on 2/2/02 11:59 PM, 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
competetive market, I vote for the former.


Regards,

Dave Badger


Stephen Marsh <samarsh@...>
 

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 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
competetive market, I vote for the former.
I agree Dave, you cant afford to make clients unhappy - and the service
provider role is not always fun <g>.

Sincerely,

Stephen Marsh.


Andrew Rodney <andrew@...>
 

on 2/3/02 2:41 PM, Dave Badger at dbadge@... wrote:
Receiving RGB files with or without a proper tag almost seem more
straight forward
now.

You think? How come? You still don¹t 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 isn¹t 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. It¹s 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 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).

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


[Non-text portions of this message have been removed]


Bob Smith <yahoo@...>
 

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


Jerry L. P'Simer <jpsimer@...>
 

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


Dave Badger <dbadge@...>
 

on 2/4/02 9:20 AM, Andrew Rodney wrote:

Receiving RGB files with or without a proper tag almost seem more
straight forward
now.

You think? How come? You still don¹t 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 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. 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


Andrew Rodney <andrew@...>
 

on 2/4/02 8:11 AM, Bob Smith at yahoo@... wrote:

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.
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 don¹t see any issues with the tag
after editing a file. Files (with and without tags) are meant to be edited.

Andrew Rodney




[Non-text portions of this message have been removed]


Tracy Williams <t_williams@...>
 

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: Dave Badger <dbadge@...>
Date: Tue, 05 Feb 2002 05:56:20 -0500
To: Andrew Rodney <andrew@...>, Stephen Marsh
<samarsh@...>, <colortheory@...>
Subject: Re: [colortheory] Re: consequences of workflow change

on 2/4/02 9:20 AM, Andrew Rodney wrote:

Receiving RGB files with or without a proper tag almost seem more
straight forward
now.

You think? How come? You still don¹t 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 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. 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



To unsubscribe from this group, send an email to:
colortheory-unsubscribe@...



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


Andrew Rodney <andrew@...>
 

on 2/5/02 3:56 AM, Dave Badger at dbadge@... 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, it¹s 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 it¹s 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,
it¹s likely a bad conversion for YOUR device. Might look great to the
originally intended device (if it¹s 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 ³we didn¹t know it would output so ugly.²

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 that¹s 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 you¹d
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



[Non-text portions of this message have been removed]


Bob Smith <yahoo@...>
 

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 don¹t 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


Andrew Rodney <andrew@...>
 

on 2/5/02 9:33 AM, Bob Smith at bob@... 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 Defaults
The 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


Dan Margulis <76270.1033@...>
 

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


Andrew Rodney <andrew@...>
 

on 2/6/02 10:33 AM, Dan Margulis at 76270.1033@... 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 isn¹t 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 that¹s 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? That¹s fine. Laborious
but fine. It isn¹t 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 wasn¹t 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 don¹t affect that issue, they only
allow users to see and if necessary convert/correct. Profiles don¹t 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


[Non-text portions of this message have been removed]