[Openicc] [argyllcms] Re: Re: OT: PDF frustration

[Kai-Uwe Behrmann]

Am 08.10.08, 15:07 +1100 schrieb Graeme Gill:
> Leonard Rosenthol wrote:
> >     So, you have made an ASSUMPTION about the purpose of the 
> > OutputIntent that isn't true (though is understandable given the name of 
> > the object).  The OutputIntent is really more of an "Output 
> > Characterization" - in that it specifies the profile for which the 
> > Device dependent colors in the file (of the same number of colorants as 
> > the profile) should be considered.  As such, it is more of an "input 
> > profile" than an "output profile".
> 
> I don't think you're correct here. Page 141: "An array of output intent
> dictionaries describing the color characteristics of output devices on
> which the document might be rendered". Section 10.10.4 talks about
> OutputIntent being to "allow the production process to be customized
> to the expected workflow and the specific tools available", and it's clear
> from chapter 4 that the way of defining what the DeviceGray/RGB/CMYK spaces
> should be, is to specify a default color space. There is no mention
> of OutputIntent in this context. I guess you're right that it could
> be used in the manner to imply an input device color space specification,
> but it seems like a rather obscure way of doing it, and leaves plenty
> of room for different results due to different interpretations, particularly
> given that there is a list to choose from, and some RIPs may take device
> space to mean the actual device space.
> In contrast, setting a default color space leaves no room for interpretation.

Given there are DefaultXXX colour spaces possible to describe in the 
Resources section, this would free the OutputIntent to what Hal already 
mentioned: the intented final device profile.

So DeviceXXX colours can be specified enough. In the absence of a 
OutputIntent, a RIP can choose to retarget as it likes and selects the 
output device profile as it knows to its best.
PDF-1.7 4.5.4 Default Color Spaces (p. 257)

I must say, previous to reading about the DeviceXXX Default Color Spaces I 
took the OutputIntent like Graeme as a document describing hint and not as 
a final decission.

With a OutputIntent it should be considered as the decission of the PDF 
creator to have no interpretation on what to finally convert to. (Of 
course proofing on monitor is a excetion as the conversion may be not 
easily Cmyk compatible.)

With the over all availability of DeviceXXX spaces and honouring the 
OutputIntent there are most of the pices available to tell a remote RIP 
what to do with the document. Would be "cool" to add something 
"authoritative", just in free open source jargon ;-)

> >     In the case of proofer - the proofer would first render the colors 
> > according to the OutputIntent and then transform to the proofing profile 
> > - basicaly turning the OI profile into a "simulation profile".  No muss 
> > - no fuss.
> 
> Right, exactly the point I was making. So slavishly following the spec.
> and transforming to an inkjet profile put in the OutputIntent by a driver
> is not what you'd want at all.
 
It should not be left too much interpretation. The main rationale is to 
create a workflow with predictable results. In the context of 
CUPS/Ghostscript I see currently no way to tell a remote host to do 
proofing or to take the OutputIntent as final. So I would prefere the 
OutputIntent to be keept a safe place.

If one wants to proof a document, it is easy to do in applications and 
send the result to a proofer. A customised filter can do this for a 
special proofing queue hopefully without problems.
With the above cited PDF semantics it makes more sense to me, if the 
standard pdftoraster filter stays apart from retargeting a given 
OutputIntent.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org