[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


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 

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 


Other related posts: