RE: The MESS at the PRESS campaign
RE: The MESS at the PRESS campaign
- Subject: RE: The MESS at the PRESS campaign
- From: bruce fraser <email@hidden>
- Date: Mon, 5 Apr 2004 14:01:14 -0700
At 10:30 PM +0200 4/5/04, Henrik Holmegaard wrote:
In the late 1990s after the FOGRA ISO 12647 and the SWOP TR 001 data
had become available a concept of Virtual CMYK workflows was
published.
The concept was that industry would standardize on no more than ten
printing conditions
You need to stop right there.
When "the industry" does in fact standardize on no more than ten
printing conditions, we can revisit this discussion, but today's
reality is that printing conditions are becoming more, rather than
less diverse-we have direct digital printers whose behavior doesn't
resemble presses, and lot of work is starting to be done with
high-chroma inksets on press that have about 1.6 x the gamut volume
of traditional process inks. Factor in the tendency of US printers to
treat standards as something to be exceeded rather than met, and
you'll find that the concept is miles away from any foreseeable
reality.
and prepress (: color separators working with OPI systems) would scan to CMYK.
The CMYK would be placed in the page design application software,
emitted as PostScript and converted to the actual printing condition
at the press using an ICC device link.
The Virtual CMYK approach assumes that there is enough communication
between the color separators to ensure that they all separate to the
same printing condition.
In this case the page design application software does not have to
harmonize the separations and _one_ source can be assigned to all
CMYK in the PostScript job.
In reality only projects where all images are original photography
are outsourced to one and the same scanner operator and even not all
CMYK may be correct.
In all other projects a mixture of legacy and current photography,
from a mixture of current photographers, will occur side by side.
So in the normal case when CMYK is placed in a document it cannot
safely be assumed to be the CMYK for the intended printing condition.
The only safe assumption in this business is that there are no safe
assumptions. Schoolchildren here learn that when you assume you make
an ass out of u and me.
Now ICC mntr and prtr device profiles are device independent in and
device independent out, which is the same as to say that they are
bidirectionally device independent, but ICC device links are device
dependent in and device dependent out.
Yes, that's the whole point of dLinks. Specifically, they allow 4D-4D
transforms instead of 4D-3D-4D ones. mntr and pntr profiles are
bidirectional, but if you make a transform that compresses the color
into the gamut of the monitor or the printer, there is NO reliable
way to retrieve that lost gamut on a subsequent conversion, so while
they may conceptually be two-way, in terms of color fidelity, they're
very much one-way.
A device link profile will convert any object which is in the same
color model as the first color model in the profile sequence of the
device link. For instance, if the first color model is CMYK then all
CMYK is blindly converted.
This means that both CMYK which is correct, and which a same : same
device profile conversion would leave intact, and CMYK which is
incorrect will be converted by the ICC device link.
A deviceLink is a computer file. It doesn't convert anything unless a
human instructs it to do so. Stupid humans, or stupid automations,
may use it to to apply inapprorpriate conversions, just as they can
do with any other ICC profile. Smart humans, and smart automation,
will avoid doing so, just as they do with any other ICC profile.
This also means that the output of an ICC device link conversion
cannot be remapped because remapping is undefined. For instance,
there is no soft-proofing or proof-printing unless you assign an ICC
device profile to the data.
You are making this much more complicated than it really is. We have
the tools to preview, both by soft-proofing and by hard-proofing, the
appearance that any set of heterogenous CMYK's will produce on a
profiled printing condition.
We have the tools to preview the intended color appearance of all
these heterogenous CMYK's.
We have inteliigent human operators who can determine the delta
between the two and take the appropriate remedial action.
In the case of a dLink, all that is needed for proofing is to assign
the destination end of the dLink to the converted source material.
So a device link cannot meaningfully be used to harmonize the
separations for the intended printing condition before placing,
unless one verifies what device profile is embedded in the data and
that the embedded profile matches the first in the link sequence.
All that most rational people ask of a proofing system is that it
serves as a reliable predictor of the final manufactured piece. They
don't really care if the system uses ICC profiles, proprietary
transforms, or voodoo dolls to get there.
--
email@hidden
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.