Standards-based inkjet proofing ABC_2
Standards-based inkjet proofing ABC_2
- Subject: Standards-based inkjet proofing ABC_2
- From: Henrik Holmegaard <email@hidden>
- Date: Sat, 3 Nov 2001 10:20:32 +0100
What is a colorimetric proof:
In a 1:1 colorimetric proof, you may chain multiple ICC profiles, for
instance, Source (e.g. Adobe RGB (1998)) via CIELab to Output (e.g.
ISO 12674-2 paper type 2 for positive plate) via CIELab to
Destination1 (e.g. HP 5000PS with HP dye inks and Sihl 3909 satin
proofing paper) and Destination2 (Apple Display gamma 1.8 5500
Kelvin). As the conversion passes the three channel ICC connection
space (CIE Lab or CIE XYZ), the Destination profile never sees the
channels in the Output profile, and the Output profile never sees the
channels in the Source profile. All the Output profile sees are the
connection space data (minus black generation) and all the
Destination profile sees is the connection space data, too. It
doesn't matter that the Destination is an inkjet in one chain and a
monitor in another.
So a standards-based colorimetric proof is not a proof that uses the
same ink settings (: separation) in the Output as in the Destination
process, because this is irrelevant by definition. Even if the both
the Output and the Destination space are printer spaces, the offset
press is a contact and the inkjet a non-contact printing technology,
and each requires a different maximum CMYK and black generation for
best results.
Finally, you want a conversion which is asymmetric, meaning that the
conversion from Source to Output uses a different rendering intent (:
LUT, block of numbers, tag ... different names, same thing) in the
Output profile than the conversion from Output to Destination uses.
The job of the first conversion in the chain is to compress the large
Source space into the Output space and the job of the second
conversion in the chain is to match the Output space 1:1 into the
Destination space without de-compression.
Proof validation workflow:
Tests with a variety of papers for the HP 5000PS, and with an Eye-One
Pro and the FOGRA strip shows that the average deltaE for the 34
color and 9 K patches is 3.5 which is just fine. There is always
interpolation even if in a colorimetric conversion there is no gamut
mapping. Also there is usually always some little area in reds or
blues or yellows where the Output space is larger than the
Destination space, because there is always going to be a trade-off
between optimizing for gamut size and optimizing for the look and
feel of offset, though I did find papers that proof pure 100% Y for
paper type 1 -:).
If the simulation and output space has the same white point as the
inkjet space, proof with Relative Colorimetric. If the inkjet space
has the higher white point, proof with Absolute Colorimetric (the
current application updates are not so well behaved here).
If you proof with Relative Colorimetric, and you do not send RGB and
CMYK to an ICC color server that only executes standard ICC
processing, be aware that there is a glitch in the Adobe ACE API. If
you set up the proof using Relative Colorimetric with Black Point
Compensation from Source to Output and Relative Colorimetric with
Black Point Compensation from Output to Destination space, the black
point in the softproof and proof print will be lower than in the
final output page. Black Point Compensation is at times a useful
option for the Source to Output transform, but not for a proof.
FOGRA has recently issued an update to its proof validation
spreadsheet. The update makes allowances for the Black Point
Compensation problem in proofs for paper types 1, 2 and 3. However,
for paper type 4 which is uncoated offset (: e.g. the Adobe
'EuroScale' Uncoated is ISO 12647-2 paper type 4) and for newsprint
(ISO 12647-3), the contrast may be increased which in turn decreases
the usefullness of the proof.
It is my understanding that FOGRA in addition to it's work in
standards bodies also serves as arbitration instance in production
disagreements. Thus the changes in the FOGRA proof validation
procedure are not static, but look for a middle-of-the-road balance
given the workflow realities we all share at any point in time.
(End part 2)