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

[Solomon Peachy <pizza@shaftnet.org>]

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