Re: The MESS at the PRESS campaign
Re: The MESS at the PRESS campaign
- Subject: Re: The MESS at the PRESS campaign
- From: Graeme Gill <email@hidden>
- Date: Tue, 13 Apr 2004 14:10:29 +1000
- Organization: Color Technology Solutions
Henrik Holmegaard wrote:
Because a device link is device dependent in and device dependent out
and thus takes the numbers in the data space while disregarding their
color appearance, and
This is not correct. A device link can certainly take account of
color appearance in its transformation (most of my device links do!).
You are right to say that it does not provide a means of transforming
from device values to color appearance, but this is hardly interesting,
as that is not the purpose of a device link, it's the purpose of
a device profile.
Because a device link will ignore device to PCS information and will not
remap device values to PCS, Open File dialogs will not be able to show a
preview of the disk-based data and after the CMM has completed its
calculation the RAM-based object cannot be displayed on the studio
monitor or studio printer.
You are assuming certain usage of device links. Full usage would
entail packaging both device profiles and the device link, allowing
full flexibility, as well as providing a more optimized device to
device transform that can be quickly computed on the fly.
Post-document Positioning :
Because a device link will ignore the AtoBx backward rendering
The AtoB table is actually the forward information (ie. the "natural"
device characteristic.) It is the A2B information that has to be
inverted to compute the B2A table (the "backward" table).
information in ICC device profiles (and the ToCIE forward rendering
information in PostScript Color Space Arrays) CIEBased which includes
ICCBased is ignored in PDF 1.3+ and CIEBased is ignored in PostScript
which is to say that you get the Texas Chain Saw Massacre.
Again you are making a broad set of assumptions about rendering pipelines
and profile usage. While I think that it would be a distinct advantage
to be able to use device links as an alternative to pairs of device
profiles "upstream" of proofing, current file format standards (ie. PS
and PDF) do not support this concept. Expectations set by things such
as the ECI Altona test suite mean that the proofing RIP needs to try
and emulate the Platesetter/Imagesetter RIP behavior, including any
of the limitations of the "dumb CMM link on the fly" color conversions
implied by ICC. Having rendered the image to a virtual press colorspace,
the proofer can use an optimized device link to re-render to the actual
proofing device colorspace, yielding far superior results to what could
be achieved with a "dumb CMM" approach.
So I will maintain that there are many companies offering proprietary
solutions who are not coming clean about the capabilities of their
products, and I will maintain that this applies both to companies
offering proprietary technologies and to prepress and printing companies
deploying proprietary technologies to rip off (no pun intended) studio
image designers and studio page designers who work in ICC application
software.
It would be unusual for vendors to undersell their solutions, so I can't
say I follow what you're trying to say, or what you are implying here.
When I began researching in the late 1990s, it used to be the whispered
with dismay among ICC developers in Germany that customers could not
obtain an advertising job for high volume rotogravure unless the
customer owned an Iris and a "4D transform proofing interpreter". Today
there are ICC profiles for rotogravure printing on the European Color
Initiative web, ISO 12647-4 has been extended to cover rotogravure, and
the carpet has been pulled from under the proprietary people even in the
rotogravure market to make way for open standards workflows from the
image design studio through the page design studio to the prepress and
press manager's Adobe PostScript 3 proofing and production interpreter.
Let's have a bit more enligthenment in other regions of the world,
including California and Colorado -:).
There is no doubt that you can "get away" with concatenating two
3D transforms (device profiles), and get acceptable or even good
results (especially if you create the destination profile with a
gamut mapping specifically created for the source profile, thereby
making it almost as specific as a device link), but the fact still
remains that a device link is a way of caching a linking process
that is too slow to be acceptable to many people, while giving
superior gamut mapping and accuracy.
Graeme Gill.
_______________________________________________
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.