[argyllcms] Re: wtpt/chad in input V2 sRGB profiles from color.org
- From: Roger Breton <graxx@xxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sun, 05 Aug 2012 13:50:26 -0400
Well,
Incorporating an sRGB profile in an image file makes sense, in my opinion,
regardless of where the image is to be consumed.
That is a matter of color management policy:
Reason #1 is the profile does not add much storage to the size of the image.
Reason #2 is that is a very good reminder of what the correct appearance of
color in the image.
Reason #3 is if the image is opened in a non-CMS aware application then it will
not be color-managed but if it opened in a CMS-aware application then, provided
the application is set to honor embedded profiles, the image will be displayed
in a correct color appearance.
To me that is a winning proposition. For CMYK profiles, I remember long and
heated debate about storage on the ColorSync List but in these days of ample
Terabyte storage, size of profiles adding the size of images ought not to be an
argument in my opinion.
For these reasons, I personally always embed profiles.
Best / Roger
-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx] On
Behalf Of Alexey Blinov
Sent: August-05-12 1:00 PM
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: wtpt/chad in input V2 sRGB profiles from color.org
Graeme, I'd like to summarize "for dummie" out here.
Since sRGB assumes the display at D65, and V2 profiles from color.org use D50,
they are not supposed to be used as input sRGB profiles. That is, the kind of
profiles that specify meaning ("units") of an RGB number triple in an image
file.
Instead, they are provided partly for a specific soft-proofing scenario with a
dumb CMM.
For input sRGB profile, one must use a profile from some reliable source (like
argyll/ref/sRGB.icm). But incorporating input sRGB profile in an image file is
pointless because all the consumer software already assumes such correct sRGB
profile.
Right?
Other related posts:
