[Printing-architecture] Human-readable strings for standard IPP options/choices/attributes/propertirs

[Printing-architecture] Human-readable strings for standard IPP options/choices/attributes/propertirs

[Till Kamppeter]

Hi,

while I was looking through the code of the PPD file generators in CUPS 
and cups-filters for creating CUPS queues for driverless IPP printers I 
wa thinking about where the human-readable strings for the PPD files 
(and also for print dialogs) come from and whether one could also 
generate PPD files translated into non-English languages.

I have also seen that printers supply human-readable strings for options 
and choices via the URL listed in the printer-strings-uri IPP attribute, 
but these strings are only for the options and choices which are not IPP 
or PWG standard.

Seeing this I thought that the wide majority of IPP attributes, options, 
choices, and properties ar IPP/PWG standardized, and so they should 
always be well served by the same human-readable strings, independent of 
operating system, desktop, or other client software being used.

So it would be great to have some central repository for these strings 
for any operating system and application software to use when working 
with IPP printers. Is there something like that? Was susch a thing 
already discussed at the PWG? Or is every OS or application developer 
supposed to "invent" his own, personal set of human-readable strings for 
standard IPP attributes?

    Till

Re: [Printing-architecture] Human-readable strings for standard IPP options/choices/attributes/propertirs

[Michael Sweet]

Till,

The CUPS repository already contains a nearly-complete set of these, and they came from the IPP Registry project's exported strings from the IANA IPP registry.

    https://github.com/OpenPrinting/cups/tree/master/locale
    https://github.com/istopwg/ippregistry/tree/master/localizations

The PWG maintains a copy of the English strings (I've tried a few times to get localizations for other languages without much success) on their FTP server (also served by HTTP/HTTPS):

    https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.pot
    https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.strings


> On Apr 27, 2021, at 1:46 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> Hi,
> 
> while I was looking through the code of the PPD file generators in CUPS and cups-filters for creating CUPS queues for driverless IPP printers I wa thinking about where the human-readable strings for the PPD files (and also for print dialogs) come from and whether one could also generate PPD files translated into non-English languages.
> 
> I have also seen that printers supply human-readable strings for options and choices via the URL listed in the printer-strings-uri IPP attribute, but these strings are only for the options and choices which are not IPP or PWG standard.
> 
> Seeing this I thought that the wide majority of IPP attributes, options, choices, and properties ar IPP/PWG standardized, and so they should always be well served by the same human-readable strings, independent of operating system, desktop, or other client software being used.
> 
> So it would be great to have some central repository for these strings for any operating system and application software to use when working with IPP printers. Is there something like that? Was susch a thing already discussed at the PWG? Or is every OS or application developer supposed to "invent" his own, personal set of human-readable strings for standard IPP attributes?
> 
>   Till
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
> 

________________________
Michael Sweet

Re: [Printing-architecture] Human-readable strings for standard IPP options/choices/attributes/propertirs

[Till Kamppeter]

Thank you very much. Then I am going into the right direction with 
cups-filters.

    Till

On 27/04/2021 20:02, Michael Sweet wrote:
> Till,
> 
> The CUPS repository already contains a nearly-complete set of these, and they came from the IPP Registry project's exported strings from the IANA IPP registry.
> 
>      https://github.com/OpenPrinting/cups/tree/master/locale
>      https://github.com/istopwg/ippregistry/tree/master/localizations
> 
> The PWG maintains a copy of the English strings (I've tried a few times to get localizations for other languages without much success) on their FTP server (also served by HTTP/HTTPS):
> 
>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.pot
>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.strings

Re: [Printing-architecture] Human-readable strings for standard IPP options/choices/attributes/propertirs

[Till Kamppeter]

I have found one problem. For the color modes IPP has only the following 
choices:

"print-color-mode" = "Print Color Mode";
"print-color-mode.auto" = "Automatic";
"print-color-mode.auto-monochrome" = "Auto Monochrome";
"print-color-mode.bi-level" = "Text";
"print-color-mode.color" = "Color";
"print-color-mode.highlight" = "Highlight";
"print-color-mode.monochrome" = "Monochrome";
"print-color-mode.process-bi-level" = "Process Text";
"print-color-mode.process-monochrome" = "Process Monochrome";

Apple Raster and PWG Raster support more modes though, especially with 
16 bit instead of 8 bit color depth, "device" color modes and Adobe RGB 
instead of sRGB. Are there standard strings for these? And where do I 
find them?

    Till

On 27/04/2021 20:02, Michael Sweet wrote:
> Till,
> 
> The CUPS repository already contains a nearly-complete set of these, and they came from the IPP Registry project's exported strings from the IANA IPP registry.
> 
>      https://github.com/OpenPrinting/cups/tree/master/locale
>      https://github.com/istopwg/ippregistry/tree/master/localizations
> 
> The PWG maintains a copy of the English strings (I've tried a few times to get localizations for other languages without much success) on their FTP server (also served by HTTP/HTTPS):
> 
>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.pot
>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.strings
> 
> 
>> On Apr 27, 2021, at 1:46 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>
>> Hi,
>>
>> while I was looking through the code of the PPD file generators in CUPS and cups-filters for creating CUPS queues for driverless IPP printers I wa thinking about where the human-readable strings for the PPD files (and also for print dialogs) come from and whether one could also generate PPD files translated into non-English languages.
>>
>> I have also seen that printers supply human-readable strings for options and choices via the URL listed in the printer-strings-uri IPP attribute, but these strings are only for the options and choices which are not IPP or PWG standard.
>>
>> Seeing this I thought that the wide majority of IPP attributes, options, choices, and properties ar IPP/PWG standardized, and so they should always be well served by the same human-readable strings, independent of operating system, desktop, or other client software being used.
>>
>> So it would be great to have some central repository for these strings for any operating system and application software to use when working with IPP printers. Is there something like that? Was susch a thing already discussed at the PWG? Or is every OS or application developer supposed to "invent" his own, personal set of human-readable strings for standard IPP attributes?
>>
>>    Till
>> _______________________________________________
>> Printing-architecture mailing list
>> Printing-architecture@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>>
> 
> ________________________
> Michael Sweet
> 
> 
> 

Re: [Printing-architecture] Human-readable strings for standard IPP options/choices/attributes/propertirs

[Michael Sweet]

Till,

With IPP you *don't* select color spaces as user options as those are artifacts of the file format and not part of the job ticket.

Realistically, the best thing to do is use the "print-content-optimize" value ('auto', 'graphic', 'photo', 'text', 'text-and-graphic') and/or the original document format (e.g. printing an image means default to photo mode, etc.) and then (if sending raster data) choosing an appropriate "pwg-raster-document-type-supported"/"urf-supported" value (which is where you will find the color spaces and bit depths that the printer supports). The current CUPS PPD generator uses these to generate ColorModel choices, which is how we let the user choose a color mode today.

In the future we should hide that implementation detail (maybe exposed under "expert controls"?) since it is confusing for a lot of users.  Moreover, it is possible for a smart PDF RIP will detect the kind of colors being used in a PDF document and choose an appropriate raster color space and bit depth when rendering a page.

I know there are going to be people that scream, "I need to have absolute control over every aspect of my printing!"  But that kind of control doesn't belong in the printing system or in the main UI - it belongs in the Printer Application (or printer, in the case of an IPP Everywhere/AirPrint printer) because those are device process/calibration settings that are explicitly *not* part of the IPP model.  IPP has always been about specifying intent (*what* you want) and not process (*how* to do it).


> On Apr 28, 2021, at 4:17 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> I have found one problem. For the color modes IPP has only the following choices:
> 
> "print-color-mode" = "Print Color Mode";
> "print-color-mode.auto" = "Automatic";
> "print-color-mode.auto-monochrome" = "Auto Monochrome";
> "print-color-mode.bi-level" = "Text";
> "print-color-mode.color" = "Color";
> "print-color-mode.highlight" = "Highlight";
> "print-color-mode.monochrome" = "Monochrome";
> "print-color-mode.process-bi-level" = "Process Text";
> "print-color-mode.process-monochrome" = "Process Monochrome";
> 
> Apple Raster and PWG Raster support more modes though, especially with 16 bit instead of 8 bit color depth, "device" color modes and Adobe RGB instead of sRGB. Are there standard strings for these? And where do I find them?
> 
>   Till
> 
> On 27/04/2021 20:02, Michael Sweet wrote:
>> Till,
>> The CUPS repository already contains a nearly-complete set of these, and they came from the IPP Registry project's exported strings from the IANA IPP registry.
>>     https://github.com/OpenPrinting/cups/tree/master/locale
>>     https://github.com/istopwg/ippregistry/tree/master/localizations
>> The PWG maintains a copy of the English strings (I've tried a few times to get localizations for other languages without much success) on their FTP server (also served by HTTP/HTTPS):
>>     https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.pot
>>     https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.strings
>>> On Apr 27, 2021, at 1:46 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> while I was looking through the code of the PPD file generators in CUPS and cups-filters for creating CUPS queues for driverless IPP printers I wa thinking about where the human-readable strings for the PPD files (and also for print dialogs) come from and whether one could also generate PPD files translated into non-English languages.
>>> 
>>> I have also seen that printers supply human-readable strings for options and choices via the URL listed in the printer-strings-uri IPP attribute, but these strings are only for the options and choices which are not IPP or PWG standard.
>>> 
>>> Seeing this I thought that the wide majority of IPP attributes, options, choices, and properties ar IPP/PWG standardized, and so they should always be well served by the same human-readable strings, independent of operating system, desktop, or other client software being used.
>>> 
>>> So it would be great to have some central repository for these strings for any operating system and application software to use when working with IPP printers. Is there something like that? Was susch a thing already discussed at the PWG? Or is every OS or application developer supposed to "invent" his own, personal set of human-readable strings for standard IPP attributes?
>>> 
>>>   Till
>>> _______________________________________________
>>> Printing-architecture mailing list
>>> Printing-architecture@lists.linux-foundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>>> 
>> ________________________
>> Michael Sweet
> 

________________________
Michael Sweet

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

[Till Kamppeter]

TL;DR: Some doubts about supporting extended color depth and color spaces:
  - How to discover if a page in a PDF is 8/16-bit color/grayscale
    sRGB/Adobe RGB?
  - How important is Adobe RGB for printing? If a printer advertises that
    it supports it, is it worthwhile for us to support jobs in Adobe RGB?
  - How is all this influenced by the "print-content-optimize" setting?


I want to make it possible to make use of the support for extended color 
spaces of driverless IPP printers (or Printer Applications).

IPP allows the user to only select from the following color modes for a 
job (list taken from PAPPL, actually available modes advertised in the
"print-color-mode-supported" IPP attribute):

   'auto'               - Automatic color/monochrome print mode
   'auto-monochrome'    - Automatic monochrome/process mono print mode
   'bi-level'           - B&W (threshold) print mode
   'color'              - Full color print mode
   'monochrome'         - Grayscale print mode using 1 color
   'process-monochrome' - Grayscale print mode using multiple colors

On mono/grayscale printers there is no 'auto-monochrome' and 'color'

Printers support some extended color space modes, at least for raster 
input, as advertised in the "urf-supported" attribute for Apple Raster, 
and the "pwg-raster-document-type-supported" attribute for PWG Raster. 
The extensions are:

  - 16 bit per color instead of 8 bit per color in color or grayscale
  - Adobe RGB instead of sRGB in color

These extensions should be used depending on the input data from the 
client and depending on the "print-content-optimize" setting for the job.

Now I am looking into implementing this in cups-filters.

To control the use of the extensions based on the input data we need to 
find out the color depth of the input and also if it is perhaps Adobe 
RGB instead of sRGB.

For raster input data (Apple Raster or PWG Raster this info should be in 
the raster header and we should simply take care to keep color space and 
depth on any needed conversion, only exception is to convert to 
grayscale or (dithered) bi-level if the user requests it via 
print-color-mode attribute.

As the client knows the printer attributes we expect that it only sends 
raster data of (extended) color spaces which we support.

More complicated is if for example CUPS receives a PDF job from a user 
application, as here CUPS has to convert the PDF into the best possible 
raster format for the printer. If the printer understands PDF, we pass 
on the input PDF (only apply pdftopdf filter) and assume that the 
printer to print it in the best possible quality.

So being left with converting PDF to raster, here we would need to know 
which color space and color depth the resulting raster data needs to 
have so that the PDF's content is best reproduced but no unneeded 
overhead is produced. To do so, we need to know of the color depth and 
color space of the graphical elements of the PDF to get the maximum one 
for each page (and naturally we should only produce raster which the 
printer supports).

So my question to the PDF experts here (Jay? Vikrant? Sahil?), how can I 
determine from a page in a PDF file

- which maximum color depth is needed to reproduce it?

- is the PDF page sRGB or Adobe RGB?

For raster-only PDFs (coming from a photo manager/editor or a scanner, 
or PCLm) it is probably trivial, and one could make this working in 
pclmtoraster.

More complex it gets for actual raster graphics. Or does color depth in 
the vector graphics of PDFs not exist and gets only introduced with 
rasterization?

And how relevant is actually Adobe RGB for printing? I assume that ALL 
driverless IPP printers do sRGB and so if the input file is sRGB one 
lets get it printed in sRGB.

But for some reason some printers support printing Adobe RGB (and for 
the JPEG output of EVERY digital camera you can choose between sRGB and 
Adobe RGB). So if the input PDF is Adobe RGB we need to discover that 
and take care that the raster is also Adobe RGB. I hope I am right.

And how is all this influenced by the setting of "print-content-optimize"?

    Till


On 28/04/2021 13:43, Michael Sweet wrote:
> Till,
> 
> With IPP you *don't* select color spaces as user options as those are artifacts of the file format and not part of the job ticket.
> 
> Realistically, the best thing to do is use the "print-content-optimize" value ('auto', 'graphic', 'photo', 'text', 'text-and-graphic') and/or the original document format (e.g. printing an image means default to photo mode, etc.) and then (if sending raster data) choosing an appropriate "pwg-raster-document-type-supported"/"urf-supported" value (which is where you will find the color spaces and bit depths that the printer supports). The current CUPS PPD generator uses these to generate ColorModel choices, which is how we let the user choose a color mode today.
> 
> In the future we should hide that implementation detail (maybe exposed under "expert controls"?) since it is confusing for a lot of users.  Moreover, it is possible for a smart PDF RIP will detect the kind of colors being used in a PDF document and choose an appropriate raster color space and bit depth when rendering a page.
> 
> I know there are going to be people that scream, "I need to have absolute control over every aspect of my printing!"  But that kind of control doesn't belong in the printing system or in the main UI - it belongs in the Printer Application (or printer, in the case of an IPP Everywhere/AirPrint printer) because those are device process/calibration settings that are explicitly *not* part of the IPP model.  IPP has always been about specifying intent (*what* you want) and not process (*how* to do it).
> 
> 
>> On Apr 28, 2021, at 4:17 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>
>> I have found one problem. For the color modes IPP has only the following choices:
>>
>> "print-color-mode" = "Print Color Mode";
>> "print-color-mode.auto" = "Automatic";
>> "print-color-mode.auto-monochrome" = "Auto Monochrome";
>> "print-color-mode.bi-level" = "Text";
>> "print-color-mode.color" = "Color";
>> "print-color-mode.highlight" = "Highlight";
>> "print-color-mode.monochrome" = "Monochrome";
>> "print-color-mode.process-bi-level" = "Process Text";
>> "print-color-mode.process-monochrome" = "Process Monochrome";
>>
>> Apple Raster and PWG Raster support more modes though, especially with 16 bit instead of 8 bit color depth, "device" color modes and Adobe RGB instead of sRGB. Are there standard strings for these? And where do I find them?
>>
>>    Till
>>
>> On 27/04/2021 20:02, Michael Sweet wrote:
>>> Till,
>>> The CUPS repository already contains a nearly-complete set of these, and they came from the IPP Registry project's exported strings from the IANA IPP registry.
>>>      https://github.com/OpenPrinting/cups/tree/master/locale
>>>      https://github.com/istopwg/ippregistry/tree/master/localizations
>>> The PWG maintains a copy of the English strings (I've tried a few times to get localizations for other languages without much success) on their FTP server (also served by HTTP/HTTPS):
>>>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.pot
>>>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.strings
>>>> On Apr 27, 2021, at 1:46 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> while I was looking through the code of the PPD file generators in CUPS and cups-filters for creating CUPS queues for driverless IPP printers I wa thinking about where the human-readable strings for the PPD files (and also for print dialogs) come from and whether one could also generate PPD files translated into non-English languages.
>>>>
>>>> I have also seen that printers supply human-readable strings for options and choices via the URL listed in the printer-strings-uri IPP attribute, but these strings are only for the options and choices which are not IPP or PWG standard.
>>>>
>>>> Seeing this I thought that the wide majority of IPP attributes, options, choices, and properties ar IPP/PWG standardized, and so they should always be well served by the same human-readable strings, independent of operating system, desktop, or other client software being used.
>>>>
>>>> So it would be great to have some central repository for these strings for any operating system and application software to use when working with IPP printers. Is there something like that? Was susch a thing already discussed at the PWG? Or is every OS or application developer supposed to "invent" his own, personal set of human-readable strings for standard IPP attributes?
>>>>
>>>>    Till
>>>> _______________________________________________
>>>> Printing-architecture mailing list
>>>> Printing-architecture@lists.linux-foundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture
>>>>
>>> ________________________
>>> Michael Sweet
>>
> 
> ________________________
> Michael Sweet
> 
> 
> 

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

[Michael Sweet]

Till,

> On May 7, 2021, at 2:52 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> 
> TL;DR: Some doubts about supporting extended color depth and color spaces:
> - How to discover if a page in a PDF is 8/16-bit color/grayscale
>   sRGB/Adobe RGB?

So there are ways to do this, but none are pretty... :/

> - How important is Adobe RGB for printing? If a printer advertises that
>   it supports it, is it worthwhile for us to support jobs in Adobe RGB?

Very important, since a lot of cameras use AdobeRGB (or provide an option for it) for an expanded color gamut.  And if you are going from Display P3 (which is another one you'll see a lot of from iPhones/iPads) it is even more important since sRGB is a really small color space.

> - How is all this influenced by the "print-content-optimize" setting?

Two different things - certainly the 'photo' value might be hint that AdobeRGB/deep color is useful/important, but I'd also say that "print-quality" can also feature in this decision, e.g., 'high' (5) print quality might indicate deep color is preferred.

> I want to make it possible to make use of the support for extended color spaces of driverless IPP printers (or Printer Applications).
> 
> IPP allows the user to only select from the following color modes for a job (list taken from PAPPL, actually available modes advertised in the
> "print-color-mode-supported" IPP attribute):
> 
>  'auto'               - Automatic color/monochrome print mode
>  'auto-monochrome'    - Automatic monochrome/process mono print mode
>  'bi-level'           - B&W (threshold) print mode
>  'color'              - Full color print mode
>  'monochrome'         - Grayscale print mode using 1 color
>  'process-monochrome' - Grayscale print mode using multiple colors
> 
> On mono/grayscale printers there is no 'auto-monochrome' and 'color'
> 
> Printers support some extended color space modes, at least for raster input, as advertised in the "urf-supported" attribute for Apple Raster, and the "pwg-raster-document-type-supported" attribute for PWG Raster. The extensions are:
> 
> - 16 bit per color instead of 8 bit per color in color or grayscale
> - Adobe RGB instead of sRGB in color

So print-color-mode and pwg-raster-document-type-supported/urf-support do two different things.  "print-color-mode" is a rendering intent (color, grayscale, bi-level, etc.) while the others list the actual color spaces and bit depths that are supported.

________________________
Michael Sweet

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

[Till Kamppeter]

On 07/05/2021 21:53, Michael Sweet wrote:
>> TL;DR: Some doubts about supporting extended color depth and color spaces:
>> - How to discover if a page in a PDF is 8/16-bit color/grayscale
>>    sRGB/Adobe RGB?
> 
> So there are ways to do this, but none are pretty... :/
>

Are they somewhere documented? Is there sample code? Is it worthwhile to 
implement it? Does implementing it take less new lines in cups-filters 
than cups-filters already has?

If it is too complicated, I think the most intuitive solution, at least 
for the high color depth is to trigger it by print-quality=high.

WDYT, would it also make sense to also switch to Adobe RGB (if available 
on the printer) if the user sets print-quality=high?

>> - How important is Adobe RGB for printing? If a printer advertises that
>>    it supports it, is it worthwhile for us to support jobs in Adobe RGB?
> 
> Very important, since a lot of cameras use AdobeRGB (or provide an option for it) for an expanded color gamut.  And if you are going from Display P3 (which is another one you'll see a lot of from iPhones/iPads) it is even more important since sRGB is a really small color space.
> 

For printing photos from photo applications the incoming PDF is probably 
raster-only and could be treated with pclmtoraster and so an easy way to 
determine whether it is AdobeRGB, but if it is an actual vector PDF it 
gets more difficult. And what does one do with Display P3? Is it 
mentioned in PWG/IPP/Apple Raster/PWG Raster/Mopria? Is it well known, 
is there a free solution to convert it to Adobe RGB?

>> - How is all this influenced by the "print-content-optimize" setting?
> 
> Two different things - certainly the 'photo' value might be hint that AdobeRGB/deep color is useful/important, but I'd also say that "print-quality" can also feature in this decision, e.g., 'high' (5) print quality might indicate deep color is preferred.
> 

OK, probably I will trigger it by the high quality setting. Important is 
to know whether I can simply switch to Adobe RGB (only if printer has 
Adobe RGB) regardless of the incoming job and the printer does always 
the right thing (and not try to print sRGB unconverted as Adobe RGB or 
uses a conversion with significant quality loss).

> So print-color-mode and pwg-raster-document-type-supported/urf-support do two different things.  "print-color-mode" is a rendering intent (color, grayscale, bi-level, etc.) while the others list the actual color spaces and bit depths that are supported.

OK.

    Till

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

[Michael Sweet]

Till,

> On May 7, 2021, at 6:11 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 07/05/2021 21:53, Michael Sweet wrote:
>>> TL;DR: Some doubts about supporting extended color depth and color spaces:
>>> - How to discover if a page in a PDF is 8/16-bit color/grayscale
>>>   sRGB/Adobe RGB?
>> So there are ways to do this, but none are pretty... :/
>> 
> 
> Are they somewhere documented? Is there sample code? Is it worthwhile to implement it? Does implementing it take less new lines in cups-filters than cups-filters already has?

You have to parse the PDF file and look at the images.

> If it is too complicated, I think the most intuitive solution, at least for the high color depth is to trigger it by print-quality=high.
> 
> WDYT, would it also make sense to also switch to Adobe RGB (if available on the printer) if the user sets print-quality=high?

That would be a reasonable approach.

>>> - How important is Adobe RGB for printing? If a printer advertises that
>>>   it supports it, is it worthwhile for us to support jobs in Adobe RGB?
>> Very important, since a lot of cameras use AdobeRGB (or provide an option for it) for an expanded color gamut.  And if you are going from Display P3 (which is another one you'll see a lot of from iPhones/iPads) it is even more important since sRGB is a really small color space.
> 
> For printing photos from photo applications the incoming PDF is probably raster-only and could be treated with pclmtoraster and so an easy way to determine whether it is AdobeRGB, but if it is an actual vector PDF it gets more difficult. And what does one do with Display P3? Is it mentioned in PWG/IPP/Apple Raster/PWG Raster/Mopria? Is it well known, is there a free solution to convert it to Adobe RGB?

It is a standard colorspace backed by an ICC profile.

>>> - How is all this influenced by the "print-content-optimize" setting?
>> Two different things - certainly the 'photo' value might be hint that AdobeRGB/deep color is useful/important, but I'd also say that "print-quality" can also feature in this decision, e.g., 'high' (5) print quality might indicate deep color is preferred.
> 
> OK, probably I will trigger it by the high quality setting. Important is to know whether I can simply switch to Adobe RGB (only if printer has Adobe RGB) regardless of the incoming job and the printer does always the right thing (and not try to print sRGB unconverted as Adobe RGB or uses a conversion with significant quality loss).
> 
>> So print-color-mode and pwg-raster-document-type-supported/urf-support do two different things.  "print-color-mode" is a rendering intent (color, grayscale, bi-level, etc.) while the others list the actual color spaces and bit depths that are supported.
> 
> OK.
> 
>   Till
> 

________________________
Michael Sweet

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

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

On Sat, May 08, 2021 at 12:11:51AM +0200, Till Kamppeter wrote:
> WDYT, would it also make sense to also switch to Adobe RGB (if available on
> the printer) if the user sets print-quality=high?

The colorspace is a property of the submitted printjob. As transforms 
into different colorspaces are inherently lossy, it must only be done
if/when absolutely necessary.

At the end of the day, there are only really three basic scenarios:

 1) Printjob is submitted in the printer's native/preferred colorspace,
    eg due to a fully color-managed workflow.
 2) Colorspace-aware printer that will parse embedded ICC profiles and
    transform data into the printer's native colorspace.
 3) Non-colorspace-aware printer

This leads to a handful of requirements:

 1) It must be possible to tell the printer that the job is already in 
    its native/preferred colorspace.  (It's called various things in 
    UIs, such as "disable color correction" or "host-managed color")
 2) The job *must* support embedding an arbitrary ICC profile
 3) If there is no embedded ICC profile and the "host managed color" 
    option is not set, just assume everything is sRGB

Notes:

 * "Printer" and "Printer Application" are interchangeable here
 * "Printer native colorspace" is arbitrary, and defined by an ICC profile.

With respect to (2), It seems the PWG raster format only defines a 
handful of colorspaces via ColorSpaceEnum; eg DeviceRGB, sRGB, and 
AdobeRGB.  This is a weakness vs JPEG or PDF (which allows arbitrary 
profiles.  Can we rely on that ColorSpace field being set correctly?

(In practice, IPP client UIs seem to be _very_ lacking when it comes to 
 exposing supported options...)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michael Sweet]

Solomon,

> On May 8, 2021, at 7:52 PM, Solomon Peachy <pizza@shaftnet.org> wrote:
> ...
> 1) It must be possible to tell the printer that the job is already in 
>    its native/preferred colorspace.  (It's called various things in 
>    UIs, such as "disable color correction" or "host-managed color")
> 2) The job *must* support embedding an arbitrary ICC profile

Not the Job.  The *Document*.

> ...
> With respect to (2), It seems the PWG raster format only defines a 
> handful of colorspaces via ColorSpaceEnum; eg DeviceRGB, sRGB, and 
> AdobeRGB.  This is a weakness vs JPEG or PDF (which allows arbitrary 
> profiles.  Can we rely on that ColorSpace field being set correctly?

First, yes.  We've been doing so for years, even with Ghostscript (which typically converts everything to sRGB).

Second, it isn't a weakness to support well-known RGB color spaces along with a device RGB color space.  Printers that only support PWG/Apple raster really don't offer much in the way of color management.  I've been working with a couple vendors of these printers to make use of the device RGB color space for wider gamut RGB printing, since none of them want to support CIE Lab because Lab is *too* wide a color space and they can't optimize for it.

________________________
Michael Sweet

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

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

On Sat, May 08, 2021 at 09:24:27PM -0400, Michael Sweet wrote:
> >    its native/preferred colorspace.  (It's called various things in 
> >    UIs, such as "disable color correction" or "host-managed color")
> > 2) The job *must* support embedding an arbitrary ICC profile
> 
> Not the Job.  The *Document*.

Thanks for the correction -- I'm not as familiar with the IPP 
terminology as I should be.

> > handful of colorspaces via ColorSpaceEnum; eg DeviceRGB, sRGB, and 
> > AdobeRGB.  This is a weakness vs JPEG or PDF (which allows arbitrary 
> > profiles.  Can we rely on that ColorSpace field being set correctly?
> 
> First, yes.  We've been doing so for years, even with Ghostscript 
> (which typically converts everything to sRGB).

Excellent.  But I'm thinking more of folks trying to print something 
from a random app on their their iOS or Android devices.  Having a rich 
standard doesn't help when the client implementations are all 
differently brain-dead. :)

> Second, it isn't a weakness to support well-known RGB color spaces 
> along with a device RGB color space. 

I'm sorry, that's not what I was trying to say.

The "weakness" is that the PWG raster format doesn't have a way to 
self-describe what "Device RGB" means, unlike more standalone image 
formats (eg jpeg, png, tiff) that have a standard method to embed ICC 
profiles.

Now if PWG raster data can only exist (or be submitted) within a 
"Document" that explicitly supports embedding an ICC profile, that's 
another matter, but that goes back to my worry about brain-damaged 
clients that don't do the right thing.

(And trying to accomodate those brainead clients possibly breaking stuff 
 that does properly adhere to the spec..)

> Printers that only support PWG/Apple raster really don't offer much in 
> the way of color management. 

True.

(But PWG raster is mandatory, lossless, and a lot less complicated to 
 implment than PDF or the TIFF abombination..)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michael Sweet]

Solomon,

> On May 8, 2021, at 10:24 PM, Solomon Peachy <pizza@shaftnet.org> wrote:
> ...
> Excellent.  But I'm thinking more of folks trying to print something 
> from a random app on their their iOS or Android devices.  Having a rich 
> standard doesn't help when the client implementations are all 
> differently brain-dead. :)

Well, at least on iOS you'll find that the whole system is wired up for ICC-based color management, just as on macOS.  As for Android, I heartily agree!

>> Second, it isn't a weakness to support well-known RGB color spaces 
>> along with a device RGB color space. 
> 
> I'm sorry, that's not what I was trying to say.
> 
> The "weakness" is that the PWG raster format doesn't have a way to 
> self-describe what "Device RGB" means, unlike more standalone image 
> formats (eg jpeg, png, tiff) that have a standard method to embed ICC 
> profiles.

PWG Raster (and Apple Raster) are "last-mile" formats.  The color space is explicitly defined by the Printer (sometimes with ICC profiles, particularly for Device RGB), and the Client is responsible for providing raster data in a supported color space.

________________________
Michael Sweet

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

[Till Kamppeter]

On 09/05/2021 04:54, Michael Sweet wrote:
> 
> PWG Raster (and Apple Raster) are "last-mile" formats.  The color space is explicitly defined by the Printer (sometimes with ICC profiles, particularly for Device RGB), and the Client is responsible for providing raster data in a supported color space.

If the printer supports the following (according to urf-supported):

- sGray (does this come from "W8"?)
- DeviceGray
- sRGB
- AdobeRGB
- DeviceRGB

What does this exactly mean? I asume that Raster input files need to 
match one of these color spaces and in the Raster header the actually 
used color space must be specified. Am I right?

Now for DeviceRGB (and DeviceGray) I assume that here the data is 
required in the printer's native color space. Am I right? But can I do 
true driverless printing with this? Can I download the printer's ICC 
profiles from the printer? And if yes, by which URL?

    Till

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

[Michael Sweet]

Till,

> On May 9, 2021, at 4:20 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 09/05/2021 04:54, Michael Sweet wrote:
>> PWG Raster (and Apple Raster) are "last-mile" formats.  The color space is explicitly defined by the Printer (sometimes with ICC profiles, particularly for Device RGB), and the Client is responsible for providing raster data in a supported color space.
> 
> If the printer supports the following (according to urf-supported):
> 
> - sGray (does this come from "W8"?)

Yes.

> - DeviceGray
> - sRGB
> - AdobeRGB
> - DeviceRGB
> 
> What does this exactly mean? I asume that Raster input files need to match one of these color spaces and in the Raster header the actually used color space must be specified. Am I right?

Correct.

> Now for DeviceRGB (and DeviceGray) I assume that here the data is required in the printer's native color space. Am I right? But can I do true driverless printing with this? Can I download the printer's ICC profiles from the printer? And if yes, by which URL?

So printers that support device RGB and device gray also support the "printer-icc-profiles" attribute, which allows you to determine which profile to use for a particular combination of Job Template attributes.  In some cases a single profile is reported that represents the printer's internal working color space.

________________________
Michael Sweet

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

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

On Sun, May 09, 2021 at 09:41:38AM -0400, Michael Sweet wrote:
> So printers that support device RGB and device gray also support the 
> "printer-icc-profiles" attribute, which allows you to determine which 
> profile to use for a particular combination of Job Template 
> attributes.  In some cases a single profile is reported that 
> represents the printer's internal working color space.

Forgive my ignorance here, but am I correct in my understanding that 
this attribute provides a URI for clients to retrieve the profile?

So ideally, the client should retrieve the profile and transform the 
colorspace into the appropriate DeviceXXX space, and tag the 
raster/document as such?

Otherwise, the client should submit the document tagged with a standard 
(eg sRGB or AdobeRGB) colorspace, and let the printer do any necessary
transforms?

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michael Sweet]

Solomon,

> On May 9, 2021, at 10:03 AM, Solomon Peachy <pizza@shaftnet.org> wrote:
> 
> On Sun, May 09, 2021 at 09:41:38AM -0400, Michael Sweet wrote:
>> So printers that support device RGB and device gray also support the 
>> "printer-icc-profiles" attribute, which allows you to determine which 
>> profile to use for a particular combination of Job Template 
>> attributes.  In some cases a single profile is reported that 
>> represents the printer's internal working color space.
> 
> Forgive my ignorance here, but am I correct in my understanding that 
> this attribute provides a URI for clients to retrieve the profile?

Yes.  It's actually a set (array) of profiles with any associated Job Template attributes (color mode, resolution, etc.) that might influence the profile that should be used.

> So ideally, the client should retrieve the profile and transform the 
> colorspace into the appropriate DeviceXXX space, and tag the 
> raster/document as such?

Yes.

> Otherwise, the client should submit the document tagged with a standard 
> (eg sRGB or AdobeRGB) colorspace, and let the printer do any necessary
> transforms?

Right.  And also that the Client can use the closest matching standard color space when generating raster - use sRGB for sRGB images and AdobeRGB for AdobeRGB images, but transform to AdobeRGB for some other RGB color space to give yourself the most headroom.

________________________
Michael Sweet

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

[Till Kamppeter]

On 09/05/2021 15:41, Michael Sweet wrote:
> 
>> Now for DeviceRGB (and DeviceGray) I assume that here the data is required in the printer's native color space. Am I right? But can I do true driverless printing with this? Can I download the printer's ICC profiles from the printer? And if yes, by which URL?
> 
> So printers that support device RGB and device gray also support the "printer-icc-profiles" attribute, which allows you to determine which profile to use for a particular combination of Job Template attributes.  In some cases a single profile is reported that represents the printer's internal working color space.

Unfortunately, this is not always the case. My HP OfficeJet Pro 8730 has 
the following attributes

urf-supported (1setOf keyword) = 
CP1,MT1-2-8-9-10-11,PQ3-4-5,RS300-600,SRGB24,OB10,W8,DEVW8,DEVRGB24,ADOBERGB24,DM3,FN3,IS1-2,V1.4pwg-raster-document-type-supported 
(1setOf keyword) = sgray_8,srgb_8,adobe-rgb_8,rgb_8

but no "printer-icc-profiles" attribute. So for Apple Raster it supports 
Device Gray and Device RGB and for PWG Raster input it supports at least 
Device RGB ("rgb_8"?), but there is no information about how to download 
the appropriate ICC profiles from the printer, meaning that these device 
color spaces are unusable for true driverless printing. Am I right?

    Till

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

[Michael Sweet]

Till,

> On May 9, 2021, at 3:26 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 09/05/2021 15:41, Michael Sweet wrote:
>>> Now for DeviceRGB (and DeviceGray) I assume that here the data is required in the printer's native color space. Am I right? But can I do true driverless printing with this? Can I download the printer's ICC profiles from the printer? And if yes, by which URL?
>> So printers that support device RGB and device gray also support the "printer-icc-profiles" attribute, which allows you to determine which profile to use for a particular combination of Job Template attributes.  In some cases a single profile is reported that represents the printer's internal working color space.
> 
> Unfortunately, this is not always the case. My HP OfficeJet Pro 8730 has the following attributes
> 
> urf-supported (1setOf keyword) = CP1,MT1-2-8-9-10-11,PQ3-4-5,RS300-600,SRGB24,OB10,W8,DEVW8,DEVRGB24,ADOBERGB24,DM3,FN3,IS1-2,V1.4pwg-raster-document-type-supported (1setOf keyword) = sgray_8,srgb_8,adobe-rgb_8,rgb_8
> 
> but no "printer-icc-profiles" attribute. So for Apple Raster it supports Device Gray and Device RGB and for PWG Raster input it supports at least Device RGB ("rgb_8"?), but there is no information about how to download the appropriate ICC profiles from the printer, meaning that these device color spaces are unusable for true driverless printing. Am I right?

So if you used a color profile generation utility you could print a target image in DeviceRGB to generate an ICC profile that could be used locally.

________________________
Michael Sweet

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

[Till Kamppeter]

On 09/05/2021 22:34, Michael Sweet wrote:
> So if you used a color profile generation utility you could print a target image in DeviceRGB to generate an ICC profile that could be used locally.

"color profile generation utility"? What is that? Do you mean that the 
user calibrates the printer by himself? And the device color spaces are 
simply to allow that the user can calibrate this printer by himself?

    Till

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

[Michael Sweet]

Till,

Among many commercial options, ArgyllCMS (http://www.argyllcms.com) includes profile generation utilities that will work for printing.

> On May 9, 2021, at 4:43 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 09/05/2021 22:34, Michael Sweet wrote:
>> So if you used a color profile generation utility you could print a target image in DeviceRGB to generate an ICC profile that could be used locally.
> 
> "color profile generation utility"? What is that? Do you mean that the user calibrates the printer by himself? And the device color spaces are simply to allow that the user can calibrate this printer by himself?
> 
>   Till
> 

________________________
Michael Sweet

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

[Till Kamppeter]

I am thinking about doing the auto-generation of the PPD file and the 
filtering for a CUPS queue pointing to a driverless IPP printer as follows:

1. The PPD generator creates a ColorModel option which only contains the 
choices of the print-color-mode-supported IPP attribute. The choice's 
pseudo-PostScript-code snippets represent color depth and color space 
for the normal print quality (usually 8-bit, sRGB).

2. It also adds the usual print quality option with 3 levels, one is "high".

3. In (PDF, ... -rendering) filters, if print-quality=high is chosen, 
right after each ppdRasterInterpretPPD() call, we modify the raster 
header created by the function, to 16-bit and to AdobeRGB if the printer 
supports it, latter only with also print-color-mode/output-mode=color. 
This makes PDF input be rendered in the printer's highest quality if 
"high" quality is requested.

4. In filters where input is PWG/Apple/CUPS Raster we use the color 
depth and color space of the input, and not of the attributes, as they 
could have been upgraded by a previous filter due to (3)

5. In filters where the input is raster or an image, pass it on in ts 
original color depth and color space, only convert if the printer does 
not support the color depth/space or the user wants to print in 
grayscale. Especially we also do not want to convert 8-bit input to 
16-bit (if the printer supports both) or sRGB input to AdobeRGB as this 
does not improve the output quality.

6. For the resolution always use the requested resolution (usually via 
the pseudo-PostScript code in the print-quality option choices).

7. As the PPD generator does not add choices for the extended color 
modes to the ColorModel option (see (1)) we need to somehow add the info 
of how to upgrade the color depth and color space for print-quality=high 
in (3) and which is the highest color depth/space supported by the 
printer for (5). So we let the PPD generator add a line like 
"*cupsHighQuality: 16bit,AdobeRGB" (exact content depends on what the 
printer supports).

8. A way to make it even better is to somehow detect whether PDF input 
is a raster-only PDF (PCLm, PDF-IS, PDF-R, PDF from scanner, PDF from 
photo editor/manager) and in this case run it through pclmtoraster 
instead of through gstoraster or pdftoraster and treat it like raster 
input a in (4) and (5).

This way the user chooses under "ColorModel" which is expected for the 
print-color-mode in IPP. The actual color depth and color space 
(standard or best) is chosen based on whether the user wants "high" 
print quality or not.

I hope this way we better map IPP to the PPD file for the CUPS queue.

WDYT?

    Till


On 07/05/2021 21:53, Michael Sweet wrote:
> Till,
> 
>> On May 7, 2021, at 2:52 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>
>>
>> TL;DR: Some doubts about supporting extended color depth and color spaces:
>> - How to discover if a page in a PDF is 8/16-bit color/grayscale
>>    sRGB/Adobe RGB?
> 
> So there are ways to do this, but none are pretty... :/
> 
>> - How important is Adobe RGB for printing? If a printer advertises that
>>    it supports it, is it worthwhile for us to support jobs in Adobe RGB?
> 
> Very important, since a lot of cameras use AdobeRGB (or provide an option for it) for an expanded color gamut.  And if you are going from Display P3 (which is another one you'll see a lot of from iPhones/iPads) it is even more important since sRGB is a really small color space.
> 
>> - How is all this influenced by the "print-content-optimize" setting?
> 
> Two different things - certainly the 'photo' value might be hint that AdobeRGB/deep color is useful/important, but I'd also say that "print-quality" can also feature in this decision, e.g., 'high' (5) print quality might indicate deep color is preferred.
> 
>> I want to make it possible to make use of the support for extended color spaces of driverless IPP printers (or Printer Applications).
>>
>> IPP allows the user to only select from the following color modes for a job (list taken from PAPPL, actually available modes advertised in the
>> "print-color-mode-supported" IPP attribute):
>>
>>   'auto'               - Automatic color/monochrome print mode
>>   'auto-monochrome'    - Automatic monochrome/process mono print mode
>>   'bi-level'           - B&W (threshold) print mode
>>   'color'              - Full color print mode
>>   'monochrome'         - Grayscale print mode using 1 color
>>   'process-monochrome' - Grayscale print mode using multiple colors
>>
>> On mono/grayscale printers there is no 'auto-monochrome' and 'color'
>>
>> Printers support some extended color space modes, at least for raster input, as advertised in the "urf-supported" attribute for Apple Raster, and the "pwg-raster-document-type-supported" attribute for PWG Raster. The extensions are:
>>
>> - 16 bit per color instead of 8 bit per color in color or grayscale
>> - Adobe RGB instead of sRGB in color
> 
> So print-color-mode and pwg-raster-document-type-supported/urf-support do two different things.  "print-color-mode" is a rendering intent (color, grayscale, bi-level, etc.) while the others list the actual color spaces and bit depths that are supported.
> 
> ________________________
> Michael Sweet
> 
> 
> 

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

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]

On Sun, May 09, 2021 at 12:45:53AM +0200, Till Kamppeter wrote:
> 5. In filters where the input is raster or an image, pass it on in ts
> original color depth and color space, only convert if the printer does not
> support the color depth/space or the user wants to print in grayscale.
> Especially we also do not want to convert 8-bit input to 16-bit (if the
> printer supports both) or sRGB input to AdobeRGB as this does not improve
> the output quality.

It's worth considering that using 16bpp has benefits if any intermediate 
processing is done due to stacked quantization errors, even if the final 
sent-to-the-printer output is only 8bpp.  As for colorspace... that's 
more complicated.

> 7. As the PPD generator does not add choices for the extended color modes to
> the ColorModel option (see (1)) we need to somehow add the info of how to
> upgrade the color depth and color space for print-quality=high in (3) and
> which is the highest color depth/space supported by the printer for (5). So
> we let the PPD generator add a line like "*cupsHighQuality: 16bit,AdobeRGB"
> (exact content depends on what the printer supports).

It is is mistake to think about colorspace conversions in terms of 
"print quality" and as such something that can be "upgraded". Instead, 
one should think about it in terms of "correctness".

For example, the "T-Mobile Magenta" color is [226,0,116] in 8-bit sRGB, 
but might be [215,0,123] in 8-bit AdobeRGB, or [200,10,135] on the 
GruntMaster6000 printer on my desk.

If we're not absolutely sure [1] about the source colorspace (and the 
destination colorspace) it is logically impossible to "correctly" 
transform it.  The only sane thing to do is leave it completely alone.

If we _do_ know the source and destination colorspaces, we can (must?) 
transform from one to the other to ensure the colors are as correct as 
possible. I say "as possible" because this conversion is nearly always 
lossy: (1) there may be colors that the destination cannot represent, 
and (2) quantization step differences mean you might not be able to 
represent the exact shade you want.

Additionally, if the data is transformed from one colorspace to another, 
all associated metadata/attributes/etc *must* be updated correctly to 
reflect this.  Gotta keep ourselves internally consistent...

Anyway..

[1] Typically this means the source has been _explicitly_ tagged with 
    its corresponding ICC profile. In the case of PWG raster, this 
    means only "sRGB" and "AdobeRGB", as the others are device-dependent 
    and as such are meaningless without an ICC profile to tell us how to 
    interpret the values.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Till Kamppeter]

On 09/05/2021 03:38, Solomon Peachy wrote:
>> 7. As the PPD generator does not add choices for the extended color modes to
>> the ColorModel option (see (1)) we need to somehow add the info of how to
>> upgrade the color depth and color space for print-quality=high in (3) and
>> which is the highest color depth/space supported by the printer for (5). So
>> we let the PPD generator add a line like "*cupsHighQuality: 16bit,AdobeRGB"
>> (exact content depends on what the printer supports).
> 
> It is is mistake to think about colorspace conversions in terms of
> "print quality" and as such something that can be "upgraded". Instead,
> one should think about it in terms of "correctness".
> 

OK< then I will only upgrade from 8 to 16 bit (for the rasterizing of a 
standard vector-graphics-PDF) when the user requests "high" quality and 
the printer supports it.

My problem now is the following use cases:

1. A user wants to print photos in best possible (wide gammut) color 
reproduction quality. So he either sets his camera to produce AdobeRGB 
JPEGs or he shoots RAW and saves the processed RAW images in 
16-bit-per-color AdobeRGB. He sends his images out of his photo 
editor/manager to the printer, but the application sends print jobs in 
PDF. So we get a raster-only PDF with the raster data embedded being 
16-bit AdobeRGB (assuming that the printer supports it as the 
application's print dialog does a get-printer-attributes request and so 
knows what the printer supports).

In this case in the CUPS filtering process we have to discover at first 
whether the incoming PDF is raster-only. In this case we would not 
render it but pass it through pclmtoraster to extract the raster data 
with its color space info (AdobeRGB). We do not convert this to sRGB or 
anything else, but pass on a Raster file in AdobeRGB.

Question here: Do we need to discover that the PDF is raster-only and 
then use pclmtoraster? Or can we simply do the standard rendering 
(GhostScript, Poppler, or MuPDF) and tell the renderer (by command line 
for example) that we want AdobeRGB output? Would the renderer pass on 
the AdobeRGB data without conversion, especially not doing AdobeRGB -> 
sRGB -> AdobeRGB?


2. Another user wants to write a review of mobile phone providers, 
containing pictures and logos of the candidates (one of them is 
T-Mobile). In order to avoid the providers feeling stepped on their toes 
he wants to have best color reproduction. So he creates the print output 
(which is in PDF) in AdobeRGB as he knows that the printer supports it.

My question: Now how can the CUPS filters auto-discover that the PDF is 
in AdobeRGB and therefore the PDF needs to get rasterized in AdobeRGB? 
Is there some tool for that? Some special call of GhostScript or QPDF? 
Or can I uncompress the PDF and then search it for "/ColorSpace" keys? 
Also how to rasterize if there are some sRGB and some AdobeRGB pieces in it?

    Till

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

[Michael Sweet]

Till,

> On May 9, 2021, at 5:20 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> 1. A user wants to print photos in best possible (wide gammut) color reproduction quality. So he either sets his camera to produce AdobeRGB JPEGs or he shoots RAW and saves the processed RAW images in 16-bit-per-color AdobeRGB. He sends his images out of his photo editor/manager to the printer, but the application sends print jobs in PDF. So we get a raster-only PDF with the raster data embedded being 16-bit AdobeRGB (assuming that the printer supports it as the application's print dialog does a get-printer-attributes request and so knows what the printer supports).

The best solution here is to look at the image color space and try to match it to the closest printer-supported color space.

> In this case in the CUPS filtering process we have to discover at first whether the incoming PDF is raster-only. In this case we would not render it but pass it through pclmtoraster to extract the raster data with its color space info (AdobeRGB). We do not convert this to sRGB or anything else, but pass on a Raster file in AdobeRGB.

Again, you want to look at the input data to determine its color space, and then pass it through or convert as needed.

> Question here: Do we need to discover that the PDF is raster-only and then use pclmtoraster? Or can we simply do the standard rendering (GhostScript, Poppler, or MuPDF) and tell the renderer (by command line for example) that we want AdobeRGB output? Would the renderer pass on the AdobeRGB data without conversion, especially not doing AdobeRGB -> sRGB -> AdobeRGB?

Ideally we want whatever converts the file to know the input color space(s) and the printer's supported color spaces.  Then we can make a semi-intelligent decision about the color space that preserves as much of the original data as possible.

> 2. Another user wants to write a review of mobile phone providers, containing pictures and logos of the candidates (one of them is T-Mobile). In order to avoid the providers feeling stepped on their toes he wants to have best color reproduction. So he creates the print output (which is in PDF) in AdobeRGB as he knows that the printer supports it.

Again, if the source images are sRGB, it is best to stay in sRGB until the last possible moment.

> My question: Now how can the CUPS filters auto-discover that the PDF is in AdobeRGB and therefore the PDF needs to get rasterized in AdobeRGB? Is there some tool for that? Some special call of GhostScript or QPDF? Or can I uncompress the PDF and then search it for "/ColorSpace" keys? Also how to rasterize if there are some sRGB and some AdobeRGB pieces in it?

Images are almost always embedded as objects in the PDF file and references in the content streams, so as to take best advantage of the available compression filters that PDF offers.  The typical exceptions are small icons or logos that wouldn't benefit from this treatment and probably wouldn't be adversely affected by an incorrect choice about color space (so long as the RIP does ICC).

Therefore, you can examine the embedded image objects (all of the current tools provide utilities for extracting them) as a hint to what color space might be best if you have to choose between AdobeRGB and sRGB.

That said, if you have a printer ICC profile and the printer supports device RGB (or device gray), then *that* is the best color space for the "last mile" to the printer.

________________________
Michael Sweet

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

[Till Kamppeter]

On 09/05/2021 15:49, Michael Sweet wrote:
>> 1. A user wants to print photos in best possible (wide gammut) color reproduction quality. So he either sets his camera to produce AdobeRGB JPEGs or he shoots RAW and saves the processed RAW images in 16-bit-per-color AdobeRGB. He sends his images out of his photo editor/manager to the printer, but the application sends print jobs in PDF. So we get a raster-only PDF with the raster data embedded being 16-bit AdobeRGB (assuming that the printer supports it as the application's print dialog does a get-printer-attributes request and so knows what the printer supports).
> 
> The best solution here is to look at the image color space and try to match it to the closest printer-supported color space.
> 

This is my intention here.

>> In this case in the CUPS filtering process we have to discover at first whether the incoming PDF is raster-only. In this case we would not render it but pass it through pclmtoraster to extract the raster data with its color space info (AdobeRGB). We do not convert this to sRGB or anything else, but pass on a Raster file in AdobeRGB.
> 
> Again, you want to look at the input data to determine its color space, and then pass it through or convert as needed.
> 

Yes, exactly this.

>> Question here: Do we need to discover that the PDF is raster-only and then use pclmtoraster? Or can we simply do the standard rendering (GhostScript, Poppler, or MuPDF) and tell the renderer (by command line for example) that we want AdobeRGB output? Would the renderer pass on the AdobeRGB data without conversion, especially not doing AdobeRGB -> sRGB -> AdobeRGB?
> 
> Ideally we want whatever converts the file to know the input color space(s) and the printer's supported color spaces.  Then we can make a semi-intelligent decision about the color space that preserves as much of the original data as possible.
> 

But this would be the task of the renderer then. Does Ghostscript do this?

>> 2. Another user wants to write a review of mobile phone providers, containing pictures and logos of the candidates (one of them is T-Mobile). In order to avoid the providers feeling stepped on their toes he wants to have best color reproduction. So he creates the print output (which is in PDF) in AdobeRGB as he knows that the printer supports it.
> 
> Again, if the source images are sRGB, it is best to stay in sRGB until the last possible moment.
> 
>> My question: Now how can the CUPS filters auto-discover that the PDF is in AdobeRGB and therefore the PDF needs to get rasterized in AdobeRGB? Is there some tool for that? Some special call of GhostScript or QPDF? Or can I uncompress the PDF and then search it for "/ColorSpace" keys? Also how to rasterize if there are some sRGB and some AdobeRGB pieces in it?
> 
> Images are almost always embedded as objects in the PDF file and references in the content streams, so as to take best advantage of the available compression filters that PDF offers.  The typical exceptions are small icons or logos that wouldn't benefit from this treatment and probably wouldn't be adversely affected by an incorrect choice about color space (so long as the RIP does ICC).
> 
> Therefore, you can examine the embedded image objects (all of the current tools provide utilities for extracting them) as a hint to what color space might be best if you have to choose between AdobeRGB and sRGB.
> 

Yes, it is not a big problem to find all image objects, pclmtoraster 
does it for example. One could perhaps add a mode to this filter in 
which, instead of producing output, it tells hwther the input file is 
sRGB, AdobeRGB, or whatever.

My questions:

1. Let us in the second use case assume that the t-Online logo is 
complete represented as vector graphics, like an SVG, but not 
necessarily in any standard format. How is its color defined then? An 
how the color space?

2. And how about a PDF with a mix of sRGB and AdobeRGB images? Should we 
produce the resulting (raster) page in AdobeRGB then as this has the 
wider gammut?

> That said, if you have a printer ICC profile and the printer supports device RGB (or device gray), then *that* is the best color space for the "last mile" to the printer.

Then I could simply let Ghostscript apply it for the rasterization?

    Till

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

[Michael Sweet]

Till,

> On May 9, 2021, at 4:14 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> But this would be the task of the renderer then. Does Ghostscript do this?

It might, but certainly not with the current CUPS driver.

>> ...
>> Therefore, you can examine the embedded image objects (all of the current tools provide utilities for extracting them) as a hint to what color space might be best if you have to choose between AdobeRGB and sRGB.
> 
> Yes, it is not a big problem to find all image objects, pclmtoraster does it for example. One could perhaps add a mode to this filter in which, instead of producing output, it tells hwther the input file is sRGB, AdobeRGB, or whatever.
> 
> My questions:
> 
> 1. Let us in the second use case assume that the t-Online logo is complete represented as vector graphics, like an SVG, but not necessarily in any standard format. How is its color defined then? An how the color space?

So there you would need to look at the PDF content stream or the page's dictionary (and its Resources array).  Any resource object that has an array value with "/ICCBased" is an ICC color space, and the referenced object after the "/ICCBased" is the ICC profile.  There are other ways that common profiles can be specified/approximated (e.g. "CalRGB" is approximately sRGB and "CalGray" is approximately sGray).

> 2. And how about a PDF with a mix of sRGB and AdobeRGB images? Should we produce the resulting (raster) page
>  in AdobeRGB then as this has the wider gammut?

In general, yes.  If there is also device RGB support and you have a profile, then *that* is your best color space.

>> That said, if you have a printer ICC profile and the printer supports device RGB (or device gray), then *that* is the best color space for the "last mile" to the printer.
> 
> Then I could simply let Ghostscript apply it for the rasterization?

Yes, if you have a profile.

________________________
Michael Sweet

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

[Till Kamppeter]

On 09/05/2021 22:55, Michael Sweet wrote:
> Till,
> 
>> On May 9, 2021, at 4:14 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> But this would be the task of the renderer then. Does Ghostscript do this?
> 
> It might, but certainly not with the current CUPS driver.
>

Probably I have to check with the Ghostscript developers to see what to 
add to the ghostscript() filter function to make the Ghostscript called 
by it do this.

>> 1. Let us in the second use case assume that the t-Online logo is complete represented as vector graphics, like an SVG, but not necessarily in any standard format. How is its color defined then? An how the color space?
> 
> So there you would need to look at the PDF content stream or the page's dictionary (and its Resources array).  Any resource object that has an array value with "/ICCBased" is an ICC color space, and the referenced object after the "/ICCBased" is the ICC profile.  There are other ways that common profiles can be specified/approximated (e.g. "CalRGB" is approximately sRGB and "CalGray" is approximately sGray).
>

Zre their more "variants" of sRGB and AdobeRGB? Is this documented 
somewhere? I hope this does not get arbitrarily complicated to rasterize 
a vector PDF into the desired color space.


>> 2. And how about a PDF with a mix of sRGB and AdobeRGB images? Should we produce the resulting (raster) page
>>   in AdobeRGB then as this has the wider gammut?
> 
> In general, yes.  If there is also device RGB support and you have a profile, then *that* is your best color space.
>

OK, then I will go this way.

    Till

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

[Michael Sweet]

TIll,

> On May 9, 2021, at 5:31 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> be specified/approximated (e.g. "CalRGB" is approximately sRGB and "CalGray" is approximately sGray).
>> 
> 
> Are their more "variants" of sRGB and AdobeRGB? Is this documented somewhere? I hope this does not get arbitrarily complicated to rasterize a vector PDF into the desired color space.

No, just that sRGB is approximated with RGB primaries and a 2.2 gamma curve vs. the official ICC profile, or using the CalRGB/CalGray colorspace.  Similarly, AdobeRGB can be approximated using its primaries and the 2.2 gamma curve vs. the official ICC profile.  And then there are multiple sRGB and AdobeRGB profiles for different ICC versions...

________________________
Michael Sweet

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

[Till Kamppeter]

As discussed on the gs-devel mailing list

https://ghostscript.com/pipermail/gs-devel/2021-May/010456.html

we came to the conclusion that for PDF files for which we do not know 
the color space the data comes in we default to sRGB in general, and 
default only to AdobeRGB if it is available in 16-bit per color and high 
color depth is requested via print-quality=high, as most PDFs are sRGB 
and if we convert sRGB to AdobeRGB with only 8 bit color depth, we can 
easily get ugly color banding.

Now I have questions about raster input files, either images or 
raster-only PDFs:

If I look into the source code of the pclmtoraster filter of 
cups-filters (cupsfilters/pclmtoraster.cxx) I see that when readin the 
embedded bitmaps from a PDF file there only occur /DeviceGray, 
/DeviceRGB, and /DeviceCMYK color spaces. How do I determine whether I 
have sRGB or AdobeRGB? Vikrant?Ans what is the default/IPP/PWG-standard 
color space of /DeviceCMYK?

Also, if I have images (JPEG, TIFF, PNG, ...) how do I know which coloe 
space they are? imagetoraster seems not to determin whether images are 
sRGB or AdobeRGB.

    Till

On 09/05/2021 15:49, Michael Sweet wrote:
> Till,
> 
>> On May 9, 2021, at 5:20 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> 1. A user wants to print photos in best possible (wide gammut) color reproduction quality. So he either sets his camera to produce AdobeRGB JPEGs or he shoots RAW and saves the processed RAW images in 16-bit-per-color AdobeRGB. He sends his images out of his photo editor/manager to the printer, but the application sends print jobs in PDF. So we get a raster-only PDF with the raster data embedded being 16-bit AdobeRGB (assuming that the printer supports it as the application's print dialog does a get-printer-attributes request and so knows what the printer supports).
> 
> The best solution here is to look at the image color space and try to match it to the closest printer-supported color space.
> 
>> In this case in the CUPS filtering process we have to discover at first whether the incoming PDF is raster-only. In this case we would not render it but pass it through pclmtoraster to extract the raster data with its color space info (AdobeRGB). We do not convert this to sRGB or anything else, but pass on a Raster file in AdobeRGB.
> 
> Again, you want to look at the input data to determine its color space, and then pass it through or convert as needed.
> 
>> Question here: Do we need to discover that the PDF is raster-only and then use pclmtoraster? Or can we simply do the standard rendering (GhostScript, Poppler, or MuPDF) and tell the renderer (by command line for example) that we want AdobeRGB output? Would the renderer pass on the AdobeRGB data without conversion, especially not doing AdobeRGB -> sRGB -> AdobeRGB?
> 
> Ideally we want whatever converts the file to know the input color space(s) and the printer's supported color spaces.  Then we can make a semi-intelligent decision about the color space that preserves as much of the original data as possible.
> 
>> 2. Another user wants to write a review of mobile phone providers, containing pictures and logos of the candidates (one of them is T-Mobile). In order to avoid the providers feeling stepped on their toes he wants to have best color reproduction. So he creates the print output (which is in PDF) in AdobeRGB as he knows that the printer supports it.
> 
> Again, if the source images are sRGB, it is best to stay in sRGB until the last possible moment.
> 
>> My question: Now how can the CUPS filters auto-discover that the PDF is in AdobeRGB and therefore the PDF needs to get rasterized in AdobeRGB? Is there some tool for that? Some special call of GhostScript or QPDF? Or can I uncompress the PDF and then search it for "/ColorSpace" keys? Also how to rasterize if there are some sRGB and some AdobeRGB pieces in it?
> 
> Images are almost always embedded as objects in the PDF file and references in the content streams, so as to take best advantage of the available compression filters that PDF offers.  The typical exceptions are small icons or logos that wouldn't benefit from this treatment and probably wouldn't be adversely affected by an incorrect choice about color space (so long as the RIP does ICC).
> 
> Therefore, you can examine the embedded image objects (all of the current tools provide utilities for extracting them) as a hint to what color space might be best if you have to choose between AdobeRGB and sRGB.
> 
> That said, if you have a printer ICC profile and the printer supports device RGB (or device gray), then *that* is the best color space for the "last mile" to the printer.
> 
> ________________________
> Michael Sweet
> 
> 
> 

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

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

On Thu, May 27, 2021 at 08:04:30PM +0200, Till Kamppeter wrote:
> Also, if I have images (JPEG, TIFF, PNG, ...) how do I know which coloe
> space they are? imagetoraster seems not to determin whether images are sRGB
> or AdobeRGB.

TIFF, JPEG [1], and PNGs have standard ways to embed an ICC profile, and 
you'd have to parse that profile's description and search for 'AdobeRGB' 
(or sRGB).  Anything other than those two and you can probably just 
assume the file is DeviceRGB (or DeviceCMY[K] for CMY[K] TIFFs)

I think it's safe to assume that if there's no embedded profile in a 
file of those formats, it will be sRGB.  Where things get messier are 
formats [2] that don't support embedded profiles.

As for how to extract this, I routinely use exiftool on the command 
line, but libexiv2 is commonly used to do this (See [3] for an example) 
Once you have the profile, liblcms2 (already used by cups-filters) can 
parse it.

Incidently, my personal photo print flow submits DeviceRGB ppm files via 
lpr.  I don't care if the system defaults to assuming sRGB for 
everything, but IMO there needs to be a way to override that default via 
a runtime option...

[1] Plus jpeg2k, jpegxr, heif, webp, and undoubtedly others..
[2] gif, bmp, tga, and many, many others
[3] https://github.com/Exiv2/exiv2/blob/main/samples/toexv.cpp#L137

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michael Sweet]

Till,

> On May 27, 2021, at 2:04 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> If I look into the source code of the pclmtoraster filter of cups-filters (cupsfilters/pclmtoraster.cxx) I see that when readin the embedded bitmaps from a PDF file there only occur /DeviceGray, /DeviceRGB, and /DeviceCMYK color spaces. How do I determine whether I have sRGB or AdobeRGB? Vikrant?Ans what is the default/IPP/PWG-standard color space of /DeviceCMYK?

Assume sRGB/sGray - pclm was intended as a format for entry-level HP laser printers. DeviceCMYK is CUPS_CSPACE_CMYK (no associated profile, always a device color space).

> Also, if I have images (JPEG, TIFF, PNG, ...) how do I know which coloe space they are? imagetoraster seems not to determin whether images are sRGB or AdobeRGB.

EXIF (used for both JPEG and TIFF) includes several tags related to color space, starting with ColorSpace (sRGB or "other") and then using PrimaryChromaticities (sic) for the "other" color space to match it with the AdobeRGB primaries.

	https://www.jeita.or.jp/cgi-bin/standard_e/list.cgi?cateid=1&subcateid=4

For PNG you need to look at the cHRM chunk to compare primaries:

	https://datatracker.ietf.org/doc/html/rfc2083#page-20

If the file doesn't have this chunk, assume sRGB.

________________________
Michael Sweet

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

[Till Kamppeter]

Thank you very much.

Not having any files in AdobeRGB I have shot a photo in JPEG, setting 
the camera (Olympus PEN F) to AdobeRGB and shot another photo with the 
standard sRGB setting.

The sRGB picture contains "ColorSpace: sRGB" in its EXIF data (section: 
Photograph Information"), as you told, so it can easily be identified as 
such.

The AdobeRGB picture has "ColorSpace: Uncalibrated", so something 
similar to the "Other" which you told, and in the "Image Information" 
section now appears an entry "Primary Chromaticities: 64/100 33/100 
21/100 71/100 15/100 6/100" which are exactly the 6 numbers for Red 
Green, and Blue in the chromaticities table on

https://en.wikipedia.org/wiki/Adobe_RGB_color_space

The 2 numbers for White in this table also appear in the EXIF data, as 
"White Point: 313/1000 329/1000", also under "Image Information".

Note that I did not use the "official" EXIF standard via the link

https://www.jeita.or.jp/cgi-bin/standard_e/list.cgi?cateid=1&subcateid=4

as it seems to be some proprietary format presented in some reader which 
has a Japanese-only UI, even for the English version of the document.

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

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

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

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.

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?

So I am a little bit in doubt how important the support for the 
printer's AdobeRGB is and how best to support it.

    Till


On 28/05/2021 14:59, Michael Sweet wrote:
> Till,
> 
>> On May 27, 2021, at 2:04 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> If I look into the source code of the pclmtoraster filter of cups-filters (cupsfilters/pclmtoraster.cxx) I see that when readin the embedded bitmaps from a PDF file there only occur /DeviceGray, /DeviceRGB, and /DeviceCMYK color spaces. How do I determine whether I have sRGB or AdobeRGB? Vikrant?Ans what is the default/IPP/PWG-standard color space of /DeviceCMYK?
> 
> Assume sRGB/sGray - pclm was intended as a format for entry-level HP laser printers. DeviceCMYK is CUPS_CSPACE_CMYK (no associated profile, always a device color space).
> 
>> Also, if I have images (JPEG, TIFF, PNG, ...) how do I know which coloe space they are? imagetoraster seems not to determin whether images are sRGB or AdobeRGB.
> 
> EXIF (used for both JPEG and TIFF) includes several tags related to color space, starting with ColorSpace (sRGB or "other") and then using PrimaryChromaticities (sic) for the "other" color space to match it with the AdobeRGB primaries.
> 
> 	https://www.jeita.or.jp/cgi-bin/standard_e/list.cgi?cateid=1&subcateid=4
> 
> For PNG you need to look at the cHRM chunk to compare primaries:
> 
> 	https://datatracker.ietf.org/doc/html/rfc2083#page-20
> 
> If the file doesn't have this chunk, assume sRGB.
> 
> ________________________
> Michael Sweet
> 
> 
> 

Re: [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@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

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

[Till Kamppeter]

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?

> 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? To 
support a printer which does not support the input JPEG? Probably the 
imagetoraster() filter function would need to get this facility.

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

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

    Till

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

[Michael Sweet]

Till,

> On May 30, 2021, at 3:56 PM, Till Kamppeter <till.kamppeter@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

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

[Till Kamppeter]

On 30/05/2021 22:53, Michael Sweet wrote:
> 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.
> 

Is this already implemented in CUPS? So if I send a JPEG to CUPS and the 
printer which supports JPEG chokes on my JPEG then CUPS sees the error 
and retries the job in raster (which probably lets the imagetoraster 
filter being used)?

Is this only implemented for JPEG? Or does CUPS go from one 
*cupsfilter(2): line in the PPD to the next until the printer does not 
error any more?

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

Which parameters? Ids it documented somewhere how I can identify PDFs 
(or elements in them) as sRGB or AdobeRGB?

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

OK, but this would defeat the sophisticated color management options of 
digikam and darktable. So I hope that they do not actually use Cairo.

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

This is new as of today? What are the differences to QPDF? QPDF I use 
heavily in cups-filters and I have got some students adding features to it.

    Till

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

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]

Till,

> On May 30, 2021, at 5:50 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 30/05/2021 22:53, Michael Sweet wrote:
>> 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.
> 
> Is this already implemented in CUPS?

Yes, it has been in CUPS for many years now...

> So if I send a JPEG to CUPS and the printer which supports JPEG chokes on my JPEG then CUPS sees the error and retries the job in raster (which probably lets the imagetoraster filter being used)?
> 
> Is this only implemented for JPEG? Or does CUPS go from one *cupsfilter(2): line in the PPD to the next until the printer does not error any more?

This happens for PDF, JPEG, and PNG, and it gets retried once as PWG/Apple raster.

>> ...
>> 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.
> 
> Which parameters? Ids it documented somewhere how I can identify PDFs (or elements in them) as sRGB or AdobeRGB?

The PDF will contain color resources.  AdobeRGB:

/CalRGB<</Gamma[2.2 2.2 2.2]/Matrix[0.7667 0.29734 0.02703 0.18556 0.62736 0.07069 0.18823 0.07529 0.99134]/WhitePoint[0.9505 1 1.089]>>]

Display P3:

[/CalRGB<</Gamma[2.2 2.2 2.2]/Matrix[0.48657 0.2297 0 0.26567 0.69174 0.04511 0.19822 0.07929 1.04394]/WhitePoint[0.9505 1 1.089>>]

sRGB:

[/CalRGB<</Gamma[2.2 2.2 2.2]/Matrix[0.4124 0.2126 0.0193 0.3576 0.715 0.1192 0.1805 0.0722 0.9505]/WhitePoint[0.9505 1 1.089]>>]

As you can see, the only difference is the Matrix value.

>>> ...
>>> 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.
> 
> This is new as of today? What are the differences to QPDF? QPDF I use heavily in cups-filters and I have got some students adding features to it.

They can do similar things, but PDFio is both general-purpose (reading, "rewriting", and writing) and also won't be implementing useless writing features such as linearization and encryption.  I'm also targeting PDFio for enbedded usage.

________________________
Michael Sweet




[-- Attachment #2: Type: text/html, Size: 4712 bytes --]

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

[Michael Sweet]

Till,

> On May 31, 2021, at 7:26 AM, Till Kamppeter <till.kamppeter@canonical.com> wrote:
> ...
> PDF output when printing with darktable dos nowhere contain /calRGB, but it contains DeviceRGB at the beginning of a stream object:

So it isn't embedding the profile used for the image.  Does the file identify Cairo as the producer?

> ...
> This is a PDF generated on a Mac, containing CalRGB but not matching any of the examples you have mentioned:
> ...
> /Producer (Acrobat PDFWriter 3.0 for Power Macintosh)
> ...
> /DefaultGray 15 0 R
> /DefaultRGB  16 0 R
> >>
> endobj
> 15 0 obj
> [/CalGray
> <<
> /WhitePoint [0.9505 1 1.089 ]
> /Gamma 1.8
> >>
> ]
> endobj
> 16 0 obj
> [/CalRGB
> <<
> /WhitePoint [0.9505 1 1.089 ]
> /Gamma [1.8 1.8 1.8 ]
> /Matrix [0.4497 0.2446 0.0252 0.3163 0.672 0.1412 0.1845 0.0833 0.9227 ]
> >>
> ]

So this is a very old version of Acrobat, and the embedded (default/device) color spaces are for Apple's old monitors.

> Similar with a PDF generated on Windows:

Not sure at all what the default colorspace is here - the gamma is inverted in this file and I don't recognize the transform matrix.

> ...
> And this is generated by Ghostscript:

This looks like Apple's Generic RGB color space - similar to sRGB but with a 1.8 gamma.

> ...
> So does this mean that these 4 PDFs are neither sRGB nor AdobeRGB? For me it looks like that your method is rarely applicable.

These files are neither sRGB nor AdobeRGB.  And I'd say your sample size is far too small to make any kind of conclusions (but I suspect anything coming from Cairo on Linux will not be tagged correctly...)

________________________
Michael Sweet

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

[Till Kamppeter]

On 31/05/2021 15:24, Michael Sweet wrote:
> Till,
> 
>> On May 31, 2021, at 7:26 AM, Till Kamppeter <till.kamppeter@canonical.com> wrote:
>> ...
>> PDF output when printing with darktable dos nowhere contain /calRGB, but it contains DeviceRGB at the beginning of a stream object:
> 
> So it isn't embedding the profile used for the image.  Does the file identify Cairo as the producer?
>

This is not Cairo, Cairo does not appear as producer, but darktable itself.

If I print from gedit, I get Cairo-produced PDF which does not contain 
/CalRGB. Each page contains something like:

----------
34 0 obj
<< /Type /Page % 4
    /Parent 1 0 R
    /MediaBox [ 0 0 612 792 ]
    /Contents 36 0 R
    /Group <<
       /Type /Group
       /S /Transparency
       /I true
       /CS /DeviceRGB
    >>
    /Resources 35 0 R
 >>
endobj
----------

>> ...
>> This is a PDF generated on a Mac, containing CalRGB but not matching any of the examples you have mentioned:
>> ...
>> /Producer (Acrobat PDFWriter 3.0 for Power Macintosh)
>> ...
>> /DefaultGray 15 0 R
>> /DefaultRGB  16 0 R
>>>>
>> endobj
>> 15 0 obj
>> [/CalGray
>> <<
>> /WhitePoint [0.9505 1 1.089 ]
>> /Gamma 1.8
>>>>
>> ]
>> endobj
>> 16 0 obj
>> [/CalRGB
>> <<
>> /WhitePoint [0.9505 1 1.089 ]
>> /Gamma [1.8 1.8 1.8 ]
>> /Matrix [0.4497 0.2446 0.0252 0.3163 0.672 0.1412 0.1845 0.0833 0.9227 ]
>>>>
>> ]
> 
> So this is a very old version of Acrobat, and the embedded (default/device) color spaces are for Apple's old monitors.
> 
>> Similar with a PDF generated on Windows:
> 
> Not sure at all what the default colorspace is here - the gamma is inverted in this file and I don't recognize the transform matrix.
> 
>> ...
>> And this is generated by Ghostscript:
> 
> This looks like Apple's Generic RGB color space - similar to sRGB but with a 1.8 gamma.
> 
>> ...
>> So does this mean that these 4 PDFs are neither sRGB nor AdobeRGB? For me it looks like that your method is rarely applicable.
> 
> These files are neither sRGB nor AdobeRGB.  And I'd say your sample size is far too small to make any kind of conclusions (but I suspect anything coming from Cairo on Linux will not be tagged correctly...)

Do you know which Linux applications generate correct PDF files?

    Till

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

[Michael Sweet]

Till,

> On May 31, 2021, at 11:03 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> Do you know which Linux applications generate correct PDF files?

Sorry, I did some quick testing and wasn't able to find a single Linux application that does things properly...  Maybe we can fix that...

________________________
Michael Sweet

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

[Till Kamppeter]

On 31/05/2021 20:13, Michael Sweet wrote:
> Till,
> 
>> On May 31, 2021, at 11:03 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>> ...
>> Do you know which Linux applications generate correct PDF files?
> 
> Sorry, I did some quick testing and wasn't able to find a single Linux application that does things properly...  Maybe we can fix that...

How would you fix that in CUPS/cups-filters?

For me it looks like a bug in the PDF generators in the applications, 
meaning that one has to report this for every PDF generator. Cairo 
probably covers a lot of applications, but for example specialized photo 
applications (darktable, RawTherapee, ...) probably have their own PDF 
generators, and they all have this bug.

It is really a bug as the applications send PDF files where the printing 
system cannot determine which is the color space actually used and so it 
cannot correctly reproduce the colors on a printer and use the most 
suitable of the color spaces which the printer offers.

    Till

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

[Michael Sweet]

Till,

> On May 31, 2021, at 3:38 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> 
> 
> On 31/05/2021 20:13, Michael Sweet wrote:
>> Till,
>>> On May 31, 2021, at 11:03 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>> ...
>>> Do you know which Linux applications generate correct PDF files?
>> Sorry, I did some quick testing and wasn't able to find a single Linux application that does things properly...  Maybe we can fix that...
> 
> How would you fix that in CUPS/cups-filters?

There isn't any way to fix it in CUPS/cups-filters.

> For me it looks like a bug in the PDF generators in the applications, meaning that one has to report this for every PDF generator. Cairo probably covers a lot of applications, but for example specialized photo applications (darktable, RawTherapee, ...) probably have their own PDF generators, and they all have this bug.

So we file bugs and provide a pointer to sample code that supports calibrated and ICC color spaces.

> It is really a bug as the applications send PDF files where the printing system cannot determine which is the color space actually used and so it cannot correctly reproduce the colors on a printer and use the most suitable of the color spaces which the printer offers.

At this point CUPS needs to treat the output color space as the device color space.  Typically sRGB, sometimes AdobeRGB, less commonly a different device RGB/CMYK color space.

________________________
Michael Sweet

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

[Till Kamppeter]

I have now committed my first approach of auto-selection of the color 
space and depth in cups-filters:

Here is the commit:

https://github.com/OpenPrinting/cups-filters/commit/b06d489

The basic principles are:

- Depending on the output format (PWG or Apple Raster) the printer IPP
   attribute pwg-raster-document-type-supported or urf-supported is used
   to determine which color space/color depth combos are available.
- A color space of sGray, sRGB, AdobeRGB, Device... is selected
   depending on input data, presence of a custom ICC profile, desire to
   print in color, gray, or bi-level (print-color-mode job attribute).
- If the requested color space is available it gets selected, otherwise
   the default color space is chosen: For color printing (or if no mono
   color space is available) AdobeRGB if available otherwise sRGB, for
   mono printing sGray.
- Within the selected color space the lowest color depth (usually 8 bit
   per color) is chosen, if print-quality is set to "high" the highest
   color depth (16-bit if available).

My commit implements this only for the ghostscript() filter function 
(gstoraster CUPS filter) for now, but commonly used code is in separater 
library function so other filter functions are easy to update, too.

This is implemented for both using the filter function PPD-less, based 
on printer and job IPP attributes and as CUPS filter with a PPD file 
generated by the PPD generator of libcupsfilters (for example via the 
"driverless" utility) for a driverless IPP printer.

The generated PPD files are appropriately changed, by including both 
pwg-raster-document-type-supported and urf-supported IPP attributes of 
the printer as PPD attributes ("*cupsPwgRasterDocumentTypeSupported" and 
"*cupsUrfSupported") and by the "ColorModel" option now mirroring the 
print-color-mode IPP attribute, listing the choices from 
print-color-mode-supported, and not including pseudo-PostScript code any 
more as these parameters now get auto-selected by the filter. Formerly, 
the PPD generator created one "ColorModel" choice for each color 
space/depth combo for manual selection.

The ghostscript() filter function currently does not pre-check the 
content of incoming PDF files for best choice of color space, the color 
space requested from the color space selector function 
(cupsRasterSetColorSpace() in cupsfilters/raster.c) is always the 
default color space. Only if there is a custom color profilea Device... 
color space is requested.

Ghostscript is called with both "-dUsePDFX3Profile" and 
"-sOutputICCProfile=..." where Ghostscript's standard ICC profiles for 
sGray, sRGB, and AdobeRGB are used if no custom profile is specified.

There is most probably room for improvement, any hints are welcome.

Also more filter functions (...toraster) will be moved over.

    Till


On 07/05/2021 20:52, Till Kamppeter wrote:
> 
> TL;DR: Some doubts about supporting extended color depth and color spaces:
>   - How to discover if a page in a PDF is 8/16-bit color/grayscale
>     sRGB/Adobe RGB?
>   - How important is Adobe RGB for printing? If a printer advertises that
>     it supports it, is it worthwhile for us to support jobs in Adobe RGB?
>   - How is all this influenced by the "print-content-optimize" setting?
> 
> 
> I want to make it possible to make use of the support for extended color 
> spaces of driverless IPP printers (or Printer Applications).
> 
> IPP allows the user to only select from the following color modes for a 
> job (list taken from PAPPL, actually available modes advertised in the
> "print-color-mode-supported" IPP attribute):
> 
>    'auto'               - Automatic color/monochrome print mode
>    'auto-monochrome'    - Automatic monochrome/process mono print mode
>    'bi-level'           - B&W (threshold) print mode
>    'color'              - Full color print mode
>    'monochrome'         - Grayscale print mode using 1 color
>    'process-monochrome' - Grayscale print mode using multiple colors
> 
> On mono/grayscale printers there is no 'auto-monochrome' and 'color'
> 
> Printers support some extended color space modes, at least for raster 
> input, as advertised in the "urf-supported" attribute for Apple Raster, 
> and the "pwg-raster-document-type-supported" attribute for PWG Raster. 
> The extensions are:
> 
>   - 16 bit per color instead of 8 bit per color in color or grayscale
>   - Adobe RGB instead of sRGB in color
> 
> These extensions should be used depending on the input data from the 
> client and depending on the "print-content-optimize" setting for the job.
> 
> Now I am looking into implementing this in cups-filters.
> 
> To control the use of the extensions based on the input data we need to 
> find out the color depth of the input and also if it is perhaps Adobe 
> RGB instead of sRGB.
> 
> For raster input data (Apple Raster or PWG Raster this info should be in 
> the raster header and we should simply take care to keep color space and 
> depth on any needed conversion, only exception is to convert to 
> grayscale or (dithered) bi-level if the user requests it via 
> print-color-mode attribute.
> 
> As the client knows the printer attributes we expect that it only sends 
> raster data of (extended) color spaces which we support.
> 
> More complicated is if for example CUPS receives a PDF job from a user 
> application, as here CUPS has to convert the PDF into the best possible 
> raster format for the printer. If the printer understands PDF, we pass 
> on the input PDF (only apply pdftopdf filter) and assume that the 
> printer to print it in the best possible quality.
> 
> So being left with converting PDF to raster, here we would need to know 
> which color space and color depth the resulting raster data needs to 
> have so that the PDF's content is best reproduced but no unneeded 
> overhead is produced. To do so, we need to know of the color depth and 
> color space of the graphical elements of the PDF to get the maximum one 
> for each page (and naturally we should only produce raster which the 
> printer supports).
> 
> So my question to the PDF experts here (Jay? Vikrant? Sahil?), how can I 
> determine from a page in a PDF file
> 
> - which maximum color depth is needed to reproduce it?
> 
> - is the PDF page sRGB or Adobe RGB?
> 
> For raster-only PDFs (coming from a photo manager/editor or a scanner, 
> or PCLm) it is probably trivial, and one could make this working in 
> pclmtoraster.
> 
> More complex it gets for actual raster graphics. Or does color depth in 
> the vector graphics of PDFs not exist and gets only introduced with 
> rasterization?
> 
> And how relevant is actually Adobe RGB for printing? I assume that ALL 
> driverless IPP printers do sRGB and so if the input file is sRGB one 
> lets get it printed in sRGB.
> 
> But for some reason some printers support printing Adobe RGB (and for 
> the JPEG output of EVERY digital camera you can choose between sRGB and 
> Adobe RGB). So if the input PDF is Adobe RGB we need to discover that 
> and take care that the raster is also Adobe RGB. I hope I am right.
> 
> And how is all this influenced by the setting of "print-content-optimize"?
> 
>     Till
> 
> 
> On 28/04/2021 13:43, Michael Sweet wrote:
>> Till,
>>
>> With IPP you *don't* select color spaces as user options as those are 
>> artifacts of the file format and not part of the job ticket.
>>
>> Realistically, the best thing to do is use the 
>> "print-content-optimize" value ('auto', 'graphic', 'photo', 'text', 
>> 'text-and-graphic') and/or the original document format (e.g. printing 
>> an image means default to photo mode, etc.) and then (if sending 
>> raster data) choosing an appropriate 
>> "pwg-raster-document-type-supported"/"urf-supported" value (which is 
>> where you will find the color spaces and bit depths that the printer 
>> supports). The current CUPS PPD generator uses these to generate 
>> ColorModel choices, which is how we let the user choose a color mode 
>> today.
>>
>> In the future we should hide that implementation detail (maybe exposed 
>> under "expert controls"?) since it is confusing for a lot of users.  
>> Moreover, it is possible for a smart PDF RIP will detect the kind of 
>> colors being used in a PDF document and choose an appropriate raster 
>> color space and bit depth when rendering a page.
>>
>> I know there are going to be people that scream, "I need to have 
>> absolute control over every aspect of my printing!"  But that kind of 
>> control doesn't belong in the printing system or in the main UI - it 
>> belongs in the Printer Application (or printer, in the case of an IPP 
>> Everywhere/AirPrint printer) because those are device 
>> process/calibration settings that are explicitly *not* part of the IPP 
>> model.  IPP has always been about specifying intent (*what* you want) 
>> and not process (*how* to do it).
>>
>>
>>> On Apr 28, 2021, at 4:17 AM, Till Kamppeter 
>>> <till.kamppeter@gmail.com> wrote:
>>>
>>> I have found one problem. For the color modes IPP has only the 
>>> following choices:
>>>
>>> "print-color-mode" = "Print Color Mode";
>>> "print-color-mode.auto" = "Automatic";
>>> "print-color-mode.auto-monochrome" = "Auto Monochrome";
>>> "print-color-mode.bi-level" = "Text";
>>> "print-color-mode.color" = "Color";
>>> "print-color-mode.highlight" = "Highlight";
>>> "print-color-mode.monochrome" = "Monochrome";
>>> "print-color-mode.process-bi-level" = "Process Text";
>>> "print-color-mode.process-monochrome" = "Process Monochrome";
>>>
>>> Apple Raster and PWG Raster support more modes though, especially 
>>> with 16 bit instead of 8 bit color depth, "device" color modes and 
>>> Adobe RGB instead of sRGB. Are there standard strings for these? And 
>>> where do I find them?
>>>
>>>    Till
>>>
>>> On 27/04/2021 20:02, Michael Sweet wrote:
>>>> Till,
>>>> The CUPS repository already contains a nearly-complete set of these, 
>>>> and they came from the IPP Registry project's exported strings from 
>>>> the IANA IPP registry.
>>>>      https://github.com/OpenPrinting/cups/tree/master/locale
>>>>      https://github.com/istopwg/ippregistry/tree/master/localizations
>>>> The PWG maintains a copy of the English strings (I've tried a few 
>>>> times to get localizations for other languages without much success) 
>>>> on their FTP server (also served by HTTP/HTTPS):
>>>>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.pot
>>>>      https://ftp.pwg.org/pub/pwg/ipp/examples/ipp.strings
>>>>> On Apr 27, 2021, at 1:46 PM, Till Kamppeter 
>>>>> <till.kamppeter@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> while I was looking through the code of the PPD file generators in 
>>>>> CUPS and cups-filters for creating CUPS queues for driverless IPP 
>>>>> printers I wa thinking about where the human-readable strings for 
>>>>> the PPD files (and also for print dialogs) come from and whether 
>>>>> one could also generate PPD files translated into non-English 
>>>>> languages.
>>>>>
>>>>> I have also seen that printers supply human-readable strings for 
>>>>> options and choices via the URL listed in the printer-strings-uri 
>>>>> IPP attribute, but these strings are only for the options and 
>>>>> choices which are not IPP or PWG standard.
>>>>>
>>>>> Seeing this I thought that the wide majority of IPP attributes, 
>>>>> options, choices, and properties ar IPP/PWG standardized, and so 
>>>>> they should always be well served by the same human-readable 
>>>>> strings, independent of operating system, desktop, or other client 
>>>>> software being used.
>>>>>
>>>>> So it would be great to have some central repository for these 
>>>>> strings for any operating system and application software to use 
>>>>> when working with IPP printers. Is there something like that? Was 
>>>>> susch a thing already discussed at the PWG? Or is every OS or 
>>>>> application developer supposed to "invent" his own, personal set of 
>>>>> human-readable strings for standard IPP attributes?
>>>>>
>>>>>    Till
>>>>> _______________________________________________
>>>>> Printing-architecture mailing list
>>>>> Printing-architecture@lists.linux-foundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture 
>>>>>
>>>>>
>>>> ________________________
>>>> Michael Sweet
>>>
>>
>> ________________________
>> Michael Sweet
>>
>>
>>