Re: Colorsync-users Digest, Vol 4, Issue 51
Re: Colorsync-users Digest, Vol 4, Issue 51
- Subject: Re: Colorsync-users Digest, Vol 4, Issue 51
- From: Kevin Muldoon <email@hidden>
- Date: Thu, 1 Feb 2007 14:58:44 -0500
Hey Roger,
Have you ever experimented what you describe all the way to the press?
I have an EPSON and an XP so my experiments revolve around creating a
match between these two devices.
I have a client who insist on using SWOPv2 for separations, in
Photoshop.
Isn't it the same as running this client's separations on an
Approval or a FinalProof
I also had a client who insisted on using SWOPv2 seps and sending to
ink jet queues that had a profile of their proofer and they were
pleased with the results for quite a while. However, on some jobs
they would use a channel mixer in Photoshop to manually rearrange the
plates of the SWOPv2 file, pulling information away from the CMY and
creating a grayscale in K. What they found was a color difference
between inkjet and proofer that was substantial and made inkjet
proofing for color impossible.
After considering the problem for a while, my theoretical solution
was this. There are device independent L*a*b values and then there
are device dependent CMYK numbers that the profile would have
generated to best match a particular L*a*b value. When an inkjet RIP
receives a 4C file without embedded profile it 'backwards engineers'
the CMYK numbers into the theoretical original L*a*b values through
the intent profile (the process of assigning a profile to a 4C image)
and then creates the CMYK separation appropriate for the color space
of ink jet.
However, if we find that the 4C file is heavily edited and those 4C
numbers do not readily correspond to the CMYK table in the intent
profile, we find the match between inkjet and densitometric proofing
system will be less than accurate. When the client ceased using the
channel mixer and switched the seps from SWOPv2 to the color space of
the proofer, there was an excellent color match between the inkjet
and the proofer. In other words we achieved a better color match when
we separated directly into the XP profile. Not only did we have the
inkjet matching the XP, but the monitor display appeared more
accurate and thanks to a well profiled scanner, the shop gained
automatic 'match transparency'' capability that did not exist before.
This experience leads me to think that what is true for an extreme
case (such recreating a separation using channel mixer and sending to
inkjet) would be true using PS Preview to check the color behavior of
CMYK separations on devices other than the file was separated for.
Doesn't the color gamut of the monitor also come in the equation?
And why would it be worse for CMYK solids?
I can't speak first hand as to the color gamut of the monitor being a
huge influence. I'd suspect if my little Samsung SyncMaster 204T can
achieve competent results next to a D50 light booth then I'd think
higher end systems should work even better. The 'ICC blindness to
primary color' test is likely not a monitor issue at all, but an ICC
issue. It's a test to demonstrate the inherent flaws in CMYK
workflows within color managed shops. Or perhaps it's an ICC 'non-
issue' because I suspect ICC was never meant to create great color
from separations but rather create great separations for color.
I qualify all of this by saying my theory was born of very strange
and unusual circumstances but I believe they hold true, if in a
lesser extent, to the specific issue being discussed here.
Cheers!
-- Kevin Muldoon
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden