[Openicc] CUPS Color Management under Linux gets into distros

[Alastair M. Robinson]

Hi :)

On 21/02/11 19:30, Chris Murphy wrote:

> Why does it seem necessary? You're saying poppler would need to render to sRGB and then do a hand off to what>
 > to do the conversion to CMYK?

We're talking about the Poppler-based pdftoraster filter that will be 
part of Ubuntu Natty.  Pdftoraster uses Poppler to rasterize the PDF.

If the printer's profile is RGB, then Pdftoraster asks Poppler to render 
directly to the printer's profile (how much notice Poppler takes of that 
request I'm not yet sure!).

If the printer's profile is CMYK then pdftoraster asks Poppler to use 
its default rendering (i.e. to sRGB), then pdftoraster handles the 
conversion to CMYK.

> The issue is both the source space L* going to 0, compared to the destination space L* going to something more than zero,
> and the lack of Black Point Compensation to use with RelCol. When both of these are true, Perceptual rendering should be used.

In this context BPC would be available, but I don't see any reason not 
to use Perceptual when converting a flat sRGB raster to a printer's profile?

> Even if a printer is described by an RGB output device profile, the L* will not go to 0 for any real device with a properly
> built profile. So the issue of intent is the same. Default rendering to print space needs to be either RelCol+BPC or Perceptual.

Agreed, however, when the printer's profile is RGB, Pdftoraster doesn't 
need to do its own conversion, so rendering intent then becomes a 
Poppler issue.

All the best
--
Alastair M. Robinson