[Openicc] CUPS Color Management under Linux gets into distros

[Hal V. Engel]

On Monday, February 28, 2011 06:22:29 AM Cyrille Berger Skott wrote:
> On Friday 11 February 2011, Hal V. Engel wrote:
> > I had a closer look at the PDF files produced by the Qt print dialog.  I
> > see the following:
> > 
> > 1.  The first line is
> > 
> > %PDF-1.4
> > 
> > So these are NOT PDF/X.
> > 
> > 2. All image objects are either DeviceRGB or DeviceGray even when using a
> > color managed app like Krita with a color managed image.   Looking at the
> > code in QPdfEnginePrivate I see that that this is hard coded.
> > 
> > 3. Images are always 8 bits/channel or less.  QImage limitation.
> > 
> > So the Qt PDF print work flow will need a lot of work done to it to be
> > fully useable.  Has anyone here who works on Qt or KDE based imaging apps
> > like krita or Scribus have any work arounds for this?
> 
> As far as I know Scribus uses its own PDF generation code.

I guess I knew this already.  In fact, if my memory is correct, the PDF code 
in Scribus is able to handle creating fully formed correctly color managed 
PDFs.  And it is one of the few open source apps that will do this.

> 
> As for Krita, by default, the image is converted to sRGB 8bit for printing,

I guess this is about all that can be done with the current printing software 
stack and the limitations currently imposed by Qt short of writting a printer 
interface.  Converting to sRGB is more than most apps are doing at this point.

> there is a configuration option (with no UI) to set a different profile for
> the printer.
> 
> It is worth to note that for Krita, we do not consider printing as part of
> our important features. IE, we consider that the artists job stops in
> Krita at creating the image. He can print it on his 30€ printer, but if
> the user is running a shop with 30000€ printers, he should use other
> software to print the image (after drawing it with Krita, of course ;P ).
> This is why Qt not supporting the color profile in PDF, and having to
> convert to sRGB 8bits, is not considered a critical issue for Krita. Of
> course, if at a latter stage, the API allows better support for color
> profiled printing, we will make sure that Krita makes the best of them.

The Qt PDF printing flow actually looks worse than I had originally thought.  
The app opens a logical paint (QPrinter) device that it paints the output to 
and it has no idea if that device is using a PDF or some other format for the 
spool file (this is set by the user in the QPrinterDialog) and the paint engine 
hides this detail from the app. doing the painting.  So the app. has no way to 
take advantage of PDF features such as color management or the ability to 
handle higher bit depths.  In other words it acts like a generic Qt paint 
device and is limited to what can be done to a QImage or a QPixmap (8 
bits/channel RGB, gray only and no metat data).  At a minimum the Qt PDF 
engine needs to tag images with either good default ICC profiles or with good 
default CalRGB and CalGray tags instead of using deviceRGB and deviceGray for 
all images.

The underlaying issue is that the paint engine should allow apps to paint 
images in formats other than QImage (IE. a jpeg or tiff) and the backend should 
parse the image for things like ICC profiles and it should use those as part of 
the output stream if the actual paint device support these like a PDF device 
can.   Or QImage needs to be extended to support this meta data and higher bit 
depths. I suspect that the Qt folks would argue that you can open most image 
formats as a QImage so is unnecessary to allow painting in native file formats 
but this ignores that fact that the process of opening a tiff or jpeg image as 
a QImage discards almost all of the meta data that is part of that image 
including ICC profiles.  In addition it flattens the image to a max of 8 
bits/channel. 

Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110228/b6aba560/attachment.htm>