Proofing roundtrip 1984 - 2001
Proofing roundtrip 1984 - 2001
- Subject: Proofing roundtrip 1984 - 2001
- From: Henrik Holmegaard <email@hidden>
- Date: Wed, 5 Sep 2001 12:50:46 +0200
A gulp of morning air, a gulp of morning coffee and a quick scrap on
the List before the day's work -:).
What is a proof? Well, a proof is a prediction of what will come off
the press. The closest prediction is a wet proof, meaning a short
press run using actual process parameters. Otherwise, you must
simulate, and that leads into questions about the simulation pros and
cons of all sorts of printing systems ... and monitor systems, for
that matter.
The question is how many and how large trade-offs will each choice of
simulation system whittle off the predicability we are looking for?
Since the introduction of PostScript and the LaserWriter, discussions
have rolled this way and that over simulation on the desktop (: as
the desktop rules, there is no opposite, but never mind -:)).
a. the early approach was to outsource captures and separations from
scanner firmware device link conversions, try to print black and
white separation proofs inhouse on the LaserWriter as a simple form
of preflighting, and outsource photo laminate proofs at high cost and
long turnaround time, but the LaserWriter prints weren't color and
the photo laminate proofs weren't the right color,
b. the interim approach was to outsource captures and separations
from scanner firmware device link conversions, print color composites
on desktop printing systems with three types of substrate (often
called photo base, commercial base and publication base, intended
roughly to simulate high gamut offset, medium gamut offset and low
gamut offset), and use the Photoshop 4 concept of proofing which is
to send the CMYK for the simulation space into Lab and make the CRD
in the desktop printer separate to the full space of the desktop
color printer (as limited by the media and the CRD that corresponds
to that media combination),
c. the current approach is to have inhouse captures and stay
composite, using an on-they-fly conversion with modular device
profiles from a source RGB space via the simulation space to the
destination proofer space which has a gamut volume capable of holding
the simulation space and using a transform which does not displace
the colors to be rendered in facsimile (: if we don't change the Lab
to CMYK leg of the simulation profile -:)).
c1. colors produced by non-process inks are by and large outside the
process color gamuts, and they are as much of a challenge for digital
proofing as they are for older proofing technologies, but the
difference is that with say the ColorPicker module in ProfileMaker
Pro, you know which spot colors will reproduce in the proof and which
won't.
c2. "Every RIP I've tried seems to offer one of two things: Control
at the ink level, at the cost of screening that looks like sandpaper,
or Epson's pretty screening, and a hidden CMYK to RGB conversion that
makes the appearance of ink control illusory."
OK, OK, OK, out with the baby, the bathwater, the tub and the towel, too -:)
c3. "Press CMYK to Epson RGB with Abscol rendering, Advanced settings
set to No Color Adjustment."
Yes, for a one-step proof print, Absolute Colorimetric does not scale
the black point of the simulation space to the black point of the
destination proof space, if you separate to the simulation space
using Relative Colorimetric with Black Point Compensation enabled.
But page proofs rendered with Relative Colorimetric using an absolute
black point are as a rule more acceptable to users. For this to work
you also need an RGB color space like eciRGB10 that holds the largest
offset spaces.
c4. "I have some RIPs with which I can send CMYK directly to the
Epson and I realize there are some advantages to being able to
control the printer from an ink level including black. But a simple
CMYK to RGB conversion seems to produce the best matching I've seen
so far."
Whether the printer uses the OS RGB-only printing pipeline or the
PostScript printing pipeline, it should not make assumptions about
the source RGB, because in that case it will be likely to assume an
average of uncalibrated monitors, which means it will assume sRGB,
and this internal gamut is too small to proof offset, even if the
printer's ink gamut is larger. IOW the proof printing system should
be stable and should not effectively limit its own gamut. Wrt black
control, we don't want the same black on an inkjet that we do on an
offset press, which is why say Eye-One Match and ProfileMaker Pro
have presets for a low black start that keeps black out of the
lighter end of the inkjet color space. The idea found among some
printers that a proof is only a proof if it is limited to the Lab to
CMYK conversion in the simulation / output profile, and the rest is a
mechanical dot for dot likeness, that's off now as much as it was
when the first color servers came around that allowed us to add the
CMYK - Lab - CMYK leg into the proofer space. The CMYK - Lab - CMYK
conversion reseparates to the right ink limit and black generation
for the proof printer.
The way I see it, ink control is not about reproducing the same black
in the simulation space as in the space doing the simulation, but
with the way inkjets are becoming more like printing presses and less
like simple 'wow, it's color!' studio printers. Ink limiting on a
printing press is user configurable because the printing processes
are so flexible that you can't really build assumptions into them.
When I look at the inkjet scene, it seems to me they are moving in
this direction, too. People are trying so many papers and so many
inks that to get the right color means fingerprinting the colorimetry
using spectrophotometers, and to some extent setting the ink limits
via ICC profiles. The more flexible a printing system becomes, the
more user configurability will we want from it, but at the same time
nobody wants the learning curve.
Speed typing, probably ...