Proofing ABC
Proofing ABC
- Subject: Proofing ABC
- From: Henrik Holmegaard <email@hidden>
- Date: Wed, 15 Nov 2000 16:18:53 +0100
Steve Upton <email@hidden> wrote:
Ultimately I agree that the eye
is the final judge but I cannot tell you how many times I have
struggled with device proofing only to finally discover (after I
wrote the software to graph the profiles) that in many cases the
proofer did, in fact, not have the gamut required to make the proof.
Yes.
I used to think a proofing ABC was something to write once only.
Seeing the kind of black box implementations Adobe and Quark market,
maybe a proofing ABC bears repeating about once every month -:).
a. The first step is that (in most cases) the RGB source color space
is larger than the CMYK production color space, so you need gamut
remapping to handle the out of gamut colors. The gamut remapping uses
a displacement strategy which is proprietary to each profiling tool,
yet interpretable by open CMMs like the Apple and Heidelberg CMMs
(there are also proprietary tables and proprietary CMMs, for
instance, Kodak's). Such a displacement strategy is in principle just
like a pair kerning table that takes care of the fact that the Roman
alphabet forces curves, verticals and angles to meet up in
wordshapes, except in the case of colors the remapping tables serve
to avoid that colors which are out of gamut for the destination color
space aren't just clipped to the surface of the destination gamut.
b. Once you have calculated the RGB to CIELab to production CMYK
transform, then all displacement stops. If displacement doesn't stop,
then obviously you can kiss the proof goodbye. The bug in PressReady
and Photoshop 5X has to do with the fact that displacement is used
both in the separations transform and in the simulations transform
from production CMYK to CIELab to proof CMYK where it is prohibited.
The way the ICC framework is built, developers are allowed to use
their repro knowhow on the perceptual separations technology, but the
colorimetric simulations transform is intended to be by 1:1 and by
the letter.
c. The reason contract proof prints require some care is that you
must either use the same paper and profile for the differences in
inks / foils, or use different papers. If you use the same paper,
then build the proofing transform with the relative colorimetric
intent. If you use a special high grade proofing paper, then build
the proofing transform with the absolute colorimetric intent. But in
no case may the proofer gamut be smaller than the production gamut.
That's why there are all those proof profile smarts in Printopen, for
instance. Because when you build the proofing transform
colorimetrically, there is color clipping UNLESS the production color
space is smaller than the proof color space. Printopen 3X and 4 have
both lightness and saturation gamut viewers (
http://www.iccabc.com
abcB), ProfileMaker has a saturation gamut viewer but none for
lightness, or you can use a utility like Steve's ColorThink. So the
long and short of it is that the ICC framework supports accurate
proofs unlike older technologies, but not everything that prints on
an inkjet (or an Approval) is eo ipso a proof.
(Note that in the ICC framework, it isn't just the colors that get
matched, but equally the densities are optimized for the actual
printing device. In other words the proofing transform takes care of
reseparating an incoming 370% offset object to a 260% object
digestible to your inkjet.)