[Openicc] CUPS Color Management under Linux gets into distros

[Hal V. Engel]

On Tuesday, March 01, 2011 12:45:46 AM Kai-Uwe Behrmann wrote:
> Am 28.02.11, 12:06 -0800 schrieb 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.
> 
> The only other way around these limitations is to generate early printer
> code. Thats done in PhotoPrint. But I guess what PhotoPrint does is out
> of scope for most applications (except of the mentioned Scribus). I wonder
> what could be suggested to use PhotoPrint from inside Krita (beside the
> Gtk/Qt appearance). Export a tiff and call PhotoPrint for it? Will this
> match the Krita settings? Or will CPD improve Kritas printing?

This limits printing to GutenPrint only.  Probably not going to happen even if 
teh GTK/Qt thing was not an issue.

> 
> > 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.
> 
> Qt appears here like on the same level as Google. They are make things
> less than just simple.

I think it is the opposite.  They have made things too simple and everything 
has been reduced to a lowest common denominator.   As a result they are doing 
the wrong things when creating PDF spool files.  QImages and QPixmaps are only 
good for a limited number of things for CM aware software.   CM aware Qt 
software like Scribus, Krita and LProf always use seperate buffers for actual 
images to allow for things like higher bit depths and float representations and 
do all manipulations of those images in the non-Qt image buffer.  In addition 
these apps only use QImages or QPixmaps for things like pushing the images out 
to the display or for things like icons in the UI.

> 
> kind regards
> Kai-Uwe Behrmann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110301/ce5511ed/attachment.html>