[Printing-architecture] Make use of extended color spaces on IPP printers

[Michael Sweet]

Till,

> On May 29, 2021, at 3:19 PM, Till Kamppeter <till.kamppeter at gmail.com> wrote:
> ...
> So one can identify the picture as AdobeRGB in the ugly way you describe, but it seems that the EXIF standard does not actually support AdobeRGB, even that cameras have this sRGB/AdobeRGB switch in their menus for decades (probably from the beginning of digital photography, I think my Canon IXUS 400 of the early aughties had it already).

This "ugly" way is the standard method for JPEG, and is also used for Display P3 photos you might get from iOS.

> But there is still the question whether this works with the AdobeRGB pictures of all cameras or only of some of them. I really do not want to have an AdobeRGB-identification quirk list for digital cameras (and phones).

This is the standard method for JPEG.

> Only there is also one thing: If you print a JPEG picture right away from the command line, it does not get filtered at all, due to this line in the auto-generated PPD files:
> 
> *cupsFilter2: "image/jpeg image/jpeg 0 -"

Right, and printers that support JPEG printing also support EXIF information (at least).  Beyond the primary chromacities, you can also embed an ICC profile in a JPEG file - only printers that advertise "icc" in their "jpeg-features-supported" attribute can properly print those files...

Longer term we'll need CUPS to convert JPEG files as needed and not just pass them through.

> So the printer takes care of however you set your camera in the hope to get the best image quality.
> 
> So it seems to be more important to identify AdobeRGB in raster-only PDFs, for example if you print a photo from a photo manager or editor and here it probably depends on what the user sets in the print settings whether the PDF is AdobeRGB or sRGB. digikam allows turning on color management in the print dialog and the select from a long list of standard color spaces (includes sRGB and AdobeRGB) or with custom color profile, but one does not know whether a JPEG image in AdobeRGB gets out as a raster PDF in AdobeRGB without converting forth and back when one selects AdobeRGB for printing.

A PDF file (raster or otherwise) has color space information encoded as resources for the pages in the file. If an application actually supports different color spaces, then it should preserve the color space when printing and then the print pipeline needs to avoid doing extra conversions (Ghostscript does this, for example).

> It seems not to be easy to make use of the fact that a printer supports AdobeRGB as input (sRGB probably serves 99.9 % of all printing needs). Did you already try this out somehow? Do you really get better output quality by that? And if you tried it, how did you do so?

I have several printers that support 48-bit AdobeRGB, and there is a definite difference in output quality for wider-gamut files.  But for me it is only worthwhile when printing photos or other large gamut content.

________________________
Michael Sweet