Re: CMYK to Lab bug plug uncorked_2
Re: CMYK to Lab bug plug uncorked_2
- Subject: Re: CMYK to Lab bug plug uncorked_2
- From: Henrik Holmegaard <email@hidden>
- Date: Sun, 8 Apr 2001 21:41:59 +0200
I wrote:
If the behaviour is Relative Colorimetric, then it is possible to
take CMYK >objects and reinstate the lost total ink coverage and
black generation. If it >is perceptual then gamut mapping is
applied, and this is not a good idea under >the circumstances.
After a walk and a reread, that's non-sense.
The CMYK object stays CMYK, the CIEBasedDEFG gets converted into a
barely legal ICC printer profile.
So the question is, What use is a printer profile that does gamut
mapping no matter what I do? And what use is a printer profile that
does relative colorimetric conversion no matter what I do?
Normally, if I have a CMYK object and want to change the separation
for the same printing condition (two profiles with two black
generations from the same measurement data), then a relative
colorimetric match would be fine. It would also be usable for
proofing. I would be unhappy with gamut remapping every which way.
And dread saturation boosts every which way, which I'd think might be
the risk for the printer profiles created from CSAs from the print
dialog and not those created from Pshop source color space
specifications.
But it's jumping through a whole stack of hoops backwards, first
subset a perfectly good multi-LUT ICC profile into a single-LUT
CIEBasedDEFG CSA and then try to pull a rabbit out of a hat by
reconverting that CSA into an ICC printer profile. I mean, why start
the whole CSA thing to begin with, especially when it was known from
the moment the PDF 1.2 spec was out that this was a dead end?
BTW come the day that ICC profiles in PDF documents can be extracted,
we'll need ColorThink to take a stab at all this. How does one tell
which behaviour the multiplied / multireferenced LUT has? How does
one tell which original LUT in an ICC printer profile a CSA
corresponds to?
--
Henrik Holmegaard
TechWrite, Denmark