All of lore.kernel.org
 help / color / mirror / Atom feed
From: Till Kamppeter <till.kamppeter@gmail.com>
To: Michael Sweet <msweet@msweet.org>
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, 29 May 2021 21:19:56 +0200	[thread overview]
Message-ID: <320a8f00-338a-8ec8-8019-22f6ecd1d4ec@gmail.com> (raw)
In-Reply-To: <4FDD96B5-A0D7-4CF7-A0E4-4D116FE73607@msweet.org>

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

  reply	other threads:[~2021-05-29 19:19 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
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 [this message]
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=320a8f00-338a-8ec8-8019-22f6ecd1d4ec@gmail.com \
    --to=till.kamppeter@gmail.com \
    --cc=ejb@ql.org \
    --cc=msweet@msweet.org \
    --cc=printing-architecture@lists.linux-foundation.org \
    --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.