All of lore.kernel.org
 help / color / mirror / Atom feed
From: Solomon Peachy <pizza@shaftnet.org>
To: Till Kamppeter <till.kamppeter@gmail.com>
Cc: "printing-architecture@lists.linux-foundation.org"
	<printing-architecture@lists.linux-foundation.org>,
	Jay Berkenbilt <ejb@ql.org>, Vikrant Malik <vikrant@iitk.ac.in>
Subject: Re: [Printing-architecture] Make use of extended color spaces on IPP printers
Date: Sat, 8 May 2021 19:52:18 -0400	[thread overview]
Message-ID: <YJckMlum0aC3moQO@shaftnet.org> (raw)
In-Reply-To: <fdd1654d-8dd6-9eb8-e41d-dcf786c559d1@gmail.com>

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

  parent reply	other threads:[~2021-05-08 23:52 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 17:46 [Printing-architecture] Human-readable strings for standard IPP options/choices/attributes/propertirs Till Kamppeter
2021-04-27 18:02 ` Michael Sweet
2021-04-27 18:10   ` Till Kamppeter
2021-04-28  8:17   ` Till Kamppeter
2021-04-28 11:43     ` Michael Sweet
2021-05-07 18:52       ` [Printing-architecture] Make use of extended color spaces on IPP printers Till Kamppeter
2021-05-07 19:53         ` Michael Sweet
2021-05-07 22:11           ` Till Kamppeter
2021-05-08  0:04             ` Michael Sweet
2021-05-08 23:52             ` Solomon Peachy [this message]
2021-05-09  1:24               ` Michael Sweet
2021-05-09  2:24                 ` Solomon Peachy
2021-05-09  2:54                   ` Michael Sweet
2021-05-09  8:20                     ` Till Kamppeter
2021-05-09 13:41                       ` Michael Sweet
2021-05-09 14:03                         ` Solomon Peachy
2021-05-09 20:32                           ` Michael Sweet
2021-05-09 19:26                         ` Till Kamppeter
2021-05-09 20:34                           ` Michael Sweet
2021-05-09 20:43                             ` Till Kamppeter
2021-05-09 21:03                               ` Michael Sweet
2021-05-08 22:45           ` Till Kamppeter
2021-05-09  1:38             ` Solomon Peachy
2021-05-09  9:20               ` Till Kamppeter
2021-05-09 13:49                 ` Michael Sweet
2021-05-09 20:14                   ` Till Kamppeter
2021-05-09 20:55                     ` Michael Sweet
2021-05-09 21:31                       ` Till Kamppeter
2021-05-10  1:08                         ` Michael Sweet
2021-05-27 18:04                   ` Till Kamppeter
2021-05-27 19:04                     ` Solomon Peachy
2021-05-28 12:59                     ` Michael Sweet
2021-05-29 19:19                       ` Till Kamppeter
2021-05-29 22:32                         ` Michael Sweet
2021-05-30 19:56                           ` Till Kamppeter
2021-05-30 20:53                             ` Michael Sweet
2021-05-30 21:50                               ` Till Kamppeter
2021-05-31  3:12                                 ` Michael Sweet
     [not found]                                   ` <d5082b23-8eb7-be84-db5c-42bdde3ba5ac@canonical.com>
2021-05-31 13:24                                     ` Michael Sweet
2021-05-31 15:03                                       ` Till Kamppeter
2021-05-31 18:13                                         ` Michael Sweet
2021-05-31 19:38                                           ` Till Kamppeter
2021-06-01  0:54                                             ` Michael Sweet
2021-05-25 17:43         ` Till Kamppeter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YJckMlum0aC3moQO@shaftnet.org \
    --to=pizza@shaftnet.org \
    --cc=ejb@ql.org \
    --cc=printing-architecture@lists.linux-foundation.org \
    --cc=till.kamppeter@gmail.com \
    --cc=vikrant@iitk.ac.in \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.