[Openicc] multiple per-job destination profiles, was: Introduction / Gutenprint

[Chris Murphy]

Michael Sweet mike at easysw.com
Tue Apr 12 17:31:27 PDT 2005

> Problem is, I haven't yet heard of a compelling use case which
> requires a per-job, user-specified destination profile.  Source
> profiles, sure, but then you might use a dozen source profiles
> depending on the document you are printing.

and

> My experience has been that professional printers that care about
> color management create new destination profiles on a regular basis
> (e.g. each day, week, or set of ink/media) and reuse those profiles
> for every job in the run.  In this case, embedding/attaching the
> destination profile with the document file is unnecessary and
> wasteful of disk/bandwidth.
>
In a high-quality print context, especially CMYK (and variants, i.e. 
where there is at least K), it is desirable to have the ability to 
select different destination profiles per object for a given job. This 
is something not currently implemented in any desktop publishing 
application, although it might exist in some pre-press software. Why 
would you need to do this?

In a page layout context you have multiple images with various kinds of 
content for which there is an ideal GCR. Very dark images with fine 
shadow detail will have more detail preserved with less GCR whereas 
screen-shots will need heavy GCR. Most images fall somewhere in 
between.

 From a certain point of view, the need for multiple destination 
profiles is really a problem with the ICC profile format which 
prescribes multiple output device profiles for a given device because a 
single output device profile is built with a single amount of GCR. To 
have different amounts of GCR, you need multiple profiles. To apply 
different amounts of GCR to different images, you need some means of 
selecting multiple destination profiles per object. This doesn't 
necessarily require that copies of these profiles be embedded in the 
spool file, however. The application really just needs to set metadata 
for each of the objects specifying a preference for GCR (this is 
already a heady subject and could get really crazy because you can have 
different amounts of GCR for varying amounts of chroma as well as 
lightness). Then the print driver could be responsible for selecting 
the appropriate profile from a bank of profiles for a given output 
condition.

Anyway, this limitation is a very real problem in implementing quality 
PDF/X-3 workflows.

At the moment I have no strong feelings about whether the destination 
profile should be included in the spool file, or externally referenced, 
but I see pros and cons to both methods.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
Published by PeachPit Press (ISBN 0-321-26722-2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2887 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/openicc/attachments/20050511/eec4bd03/attachment.bin