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
>
>
>
next prev parent 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.