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

Michael Sweet msweet at msweet.org
Sun May 30 20:53:07 UTC 2021


Till,

> On May 30, 2021, at 3:56 PM, Till Kamppeter <till.kamppeter at gmail.com> wrote:
> 
> On 30/05/2021 00:32, Michael Sweet wrote:
>> 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...
>> 
> 
> And if a printer without "icc" receives a file with embedded profile, does the printer reject the file or does it come out with ugly colors due to the profile being ignored?

Generally such files still encode the primaries in the regular EXIF data so the output won't be radically bad.

>> Longer term we'll need CUPS to convert JPEG files as needed and not just pass them through.
> 
> To convert JPEG with embedded profile (or AdobeRGB JPEG) into sRGB?

If the printer only supports sRGB, yes.

> To support a printer which does not support the input JPEG?

Yes, and there is a mechanism for that - the printer will add the document-unprintable-error value in job-state-reasons or return client-error-document-unprintable-error from the Print-Job/Send-Document request. Then CUPS will re-print as raster.

> Probably the imagetoraster() filter function would need to get this facility.

Yes.

>>> 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).
> 
> In any PDF I only find /DeviceRGB, never /AdobeRGB.

You will never see "AdobeRGB" or "sRGB" in the PDF file, you will see an ICC based color space or a calibrated color space (/CalRGB or /CalGray) with suitable parameters.

> I even tried to generate PDFs in AdobeRGB with digikam and with darktable, printing an AdobeRGB JPEG (from my camera) and fiddling around with print dialog settings, but I always get files with only /DeviceRGB.

I'm guessing that Cairo is only writing out device RGB...  Which is wrong, of course.

> Do you know how I can get appropriate PDF files for testing? Are there somewhere sample files for download? Is there a recipe how to turn an AdobeRGB JPEG into an AdobeRGB PDF under Linux?

I will shortly have the necessary changes in pdfio (https://www.msweet.org/pdfio) to be able to embed a JPEG or PNG file in a PDF file with the expected calibrated color spaces.

>> 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.
> 
> Unfortunately, I cannot test, as my printer only does 8-bit AdobeRGB, and I also do not have photo paper. Also how does one get files in AdobeRGB? Is the only way to simply send out-of-camera AdobeRGB JPEG files?

You can create images in Gimp that are suitably tagged, but certainly camera JPEG files are the simplest way.

________________________
Michael Sweet





More information about the Printing-architecture mailing list