[Openicc] CUPS Color Management under Linux gets into distros

[Cyrille Berger Skott]

On Monday 28 February 2011, Hal V. Engel wrote:
> 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.

Actually QPainter::paintEngine()->type() == QPaintEngine::PDF would allow to 
know that. But that is irrelevant...

> [...]

> Or QImage needs to be extended to support this meta data and higher bit
> depths.

This seems to be the way to go for me. And in Krita we would skip our 
conversion step when creating the QImage for display/printing. And just set 
the correct profile on the QImage.

Then the PDF engine can set the correct information using the meta data, and 
other engines (if they don't support a proper color manangement workflow) 
should probably do a conversion to sRgb.

> 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.
Well, if QImage countains the meta data, then the png/jpeg/tiff loader can be 
fixed to load the meta data, and the problem is then solved.

> In addition it flattens the image to a max of 8 bits/channel.
That can be solved as well, with little effort, by adding QImage::Format_RGB64 
and QImage::Format_RGBA64 and implementing a few conversion function inside 
QImage. I suspect the biggest problem is that by-default, Qt would still have 
to do the flattening at a max of 8 bits/channel, for compatibility reason with 
existing applications.

-- 
Cyrille Berger Skott