[Openicc] CUPS Color Management under Linux gets into distros

[Kai-Uwe Behrmann]

Am 01.03.11, 10:24 -0800 schrieb 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 more the question if CPD and a 16-bit supporting Ghostscript can 
bring Krita, Inkscape and future Gimp better print support.

>>> 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

Almost agree, but it looks to me that they are already below the lowest 
common denominator. They omit the whole colour management area outside sRGB.
And I do not see the justification.

> 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
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org