[Printing-architecture] [Openicc] [Gimp-print-devel] Colour

[Chris Murphy]

On Nov 13, 2009, at 8:32 PM, Hal V. Engel wrote:

> On Friday 13 November 2009 08:56:12 am Chris Murphy wrote:
>> But in the case of
>> calibration/characterization/prematching, the color space for those
>> objects should be DeviceRGB (I am referring to desktop inkjet printers,
>> treated as RGB output devices). 
> 
> I think the same things should be true for DeviceCMYK since this is simply a 
> variation on the same use case.

It is. Same for DeviceGray. Same for DeviceN.


>> Apple has argued that untagged data is evil. Yet the great thing about
>> PDF/X-3 (or X-4 or X-5) is that DeviceRGB is special because it is an
>> explicit indication that content to the intended device is not to be color
>> managed, but it still has an implicit source profile. And that's the
>> OutputIntent. So DeviceRGB isn't untagged.
> 
> The problem of course is that in the larger world many PDF documents use 
> DeviceRGB as a way of doing untagged RGB.  In fact I don't think the PDF 
> specification allows for untagged objects so the only option people have for 
> creating PDF documents where they don't have to tag the objects in very 
> specific ways is to use DeviceRGB.  Apple appears to be trying to "fix" this 
> problem and their fix has the unintended consequence that it makes 
> calibration/characterization/prematching very difficult.  My gut tells me that 
> they are trying to fix this problem in the wrong place and this is why we are 
> having these issues.

The PDF spec certainly allows for untagged objects. And so do the flavors of PDF/X. 

In PDF/X-1a objects can be only DeviceGray and DeviceCMYK. DeviceRGB is disallowed. OutputIntent must be CMYK, and is simultaneously the implied source and destination profile for all content in the document (i.e. no further conversions for output, unless diverted, e.g., for proofing).

In PDF/X-3 the OutputIntent can be RGB as well. If it's RGB, then DeviceRGB is allowed, but DeviceCMYK is not. If the OutputIntent is CMYK, then DeviceCMYK is allowed, but DeviceRGB is not. Additionally, ICCBased is allowed which means multiple objects in a PDF using multiple color spaces each defined by an ICC profile - which makes them all ICCBased (an RGB object tagged with Adobe RGB 1998 is considered to be ICCBased; a CMYK object tagged with GRACoL2006_Coated1 is also considered to be ICCBased - these are all considered to be in a color space OTHER than the OutputIntent color space and will be color managed prior to output).

There is a good reason why device spaces exist in these specifications. It was simply unworkable otherwise, to require everything in PDF destined for print, to be ICCBased. While on the other hand, requiring an OutputIntent makes sense for a PDF that's intended for output on a particular device.

> This is back to the RGB only assumption of Windows and OS/X.  Many of our open 
> source printer drivers support RGB as well as CMYK and true DeviceN.  Since we 
> have more flexible drivers available I think it changes how we should approach 
> this problem to some extent.

Sure.

What is not allowed in a PDF/X-3 framework is DeviceRGB and DeviceCMYK at the same time. For one it usually doesn't make sense. For another there isn't yet a mechanism in the spec for multiple instances of OutputIntent, on a page by page basis, for example (implying a single print job, containing pages with more than one possible print destination). This is being worked on, however. What you are talking about is a case where there aren't multiple physical destinations, but multiple virtual ones by virtue of the entry color space into the black box. And so I can see how this newer model might be applicable on Linux.


Chris Murphy