On 02/16/2014 07:07 PM, Graeme Gill wrote: > Elle Stone wrote: >> How should the following two quotes from the V2 version of the ICC >> specifications that is linked to on the color.org specifications page >> (http://color.org/icc_specs2.xalter) be interpreted? > > Hi, > this is an old chestnut. I'm not sure how many more > times I'm prepared to repeat all the ins and outs.
This topic may be an old chestnut to many or most of you, but it's new to me and maybe to at least a few other people. Based on reading the specs and looking at profiles, I just assumed - without even realizing that I was making an assumption - that first there was V2 with the media white point which stored the profile color space source white point information, and then there was V4 and V2-according-to-V4 with the media white point which is always the D50 illuminant, which seems to make the media white point irrelevant as the source white point information is now in the chromatic adaptation matrix and the media white point matches the illuminant. And I assumed everyone always used the Bradford transformation as that is what the currect specification strongly urges profile makers to use. But obviously the actual situation was and is a lot more complicated and trial-and-error than my simplistic assumptions. Now I know a little better. Clearly specifications alone only provide hints at the actual people and events behind evolving ICC profile color management. So thanks very much! for taking the time to put together a historical "these were and are the problems and possible solutions" perspective. I'm reading and rereading! Elle >> A.3.1.1 MediaWhitePoint Tag >> The mediaWhitePointTag contains CIE 1931 XYZ colorimetry of the white >> point of the actual medium. If the viewer completely adapts to the white >> point of the medium (as is often the case with monitors) this tag should >> be set to Xi, Yi, Zi (the PCS white point). If chromatic adaptation is >> being applied to the PCS val-ues, the adaptation should be applied to >> the mediaWhitePointTag values as well. > > This section is present only in the V2.4 specifications. By definition it > can't > change anything that has come before, which means that the vast bulk of ICC > V2 CMM > implementations and profiles precede it, and cannot be expected to conform to > it, > even if it was regarded as being canonical, which is doubtful, given that is > in > an annex rather than the spec. proper, and goes against a great deal of > previous practice, utility, and basic logic. > > There is some irony in such a fundamental point being ambiguous in ICCV2, > given that ICC was derived from the Apple ColorSync format, which (I gather) > was originally a display only format. To a degree this may be explained by > the appearance that the print profile (cLUT) support seems to have been > mostly added in, rather than fully integrated into the spec., so > perhaps the explanation is that the print profiles added the idea of > absolute colorimetry and a media white point, and the assumption was > that display profiles would continue to work in the same undocumented > way that they had done in ColorSync. Those of us not privy to the > "way things have always been done in ColorSync", instead had to interpret > the ICC spec. as written, and deal with various ambiguities, as well > as industry "best practice" in regard to chromatic adaptation. > > One of the odd things about the ICC format is that it uses a > "wrong Von Kries" chromatic adaption matrix for the media white > to PCS adapted white transformation. I've yet to hear any convincing > technical justification for this, and it is a key problem in dealing > with display profiles withing the ICC framework. > > The white point shift for a print profile is typically very small, > so the visual error between "wrong" and "right" Von Kries > is typically insignificant (although less so for tinted media), while > the error for D65 to D50 cannot be so easily overlooked. So it is no > surprise that those faced with the task of creating useful ICCV2 > display profiles adapted the ICC specifications as best they could. There > are two basic approaches, one being to hide the chromatic adaption > completely, and claim that the display profile has a D50 white point. > This results in an ICC profile in which there is no means of > recovering the underlying device behavior, or using it for soft proofing > in a pure ICC workflow. The other is to put the actual display white point > into the media white point tag, just like a print profile, and use an > appropriate chromatic adaptation transform to adapt to PCS D50. > This results in an ICC profile in which the the underlying device behavior > can be recovered, and it can also be used for soft proofing in a pure > ICC workflow. The problem with this approach is that the chromatic > transform matrix used is different to the one specified by the ICC spec. > None the less, the the latter approach is the one that the sRGB and AdobeRGB > profiles take. Given the prominence of both of these profiles, as well > as the well documented means used to create the sRGB profile, as > well as the strong technical reasoning behind using this approach, > it is a tragedy in my opinion that the ICC didn't resolve this problem > by simply adding a new (optional) tag to specify the chromatic adaptation > matrix to be used for media white to/from PCS D50 in place of the > default "Wrong Von Kries". > > Instead for ICCV4 they added an additional chromatic adaptation matrix > tag (the chad tag) for the purposes of documenting any illuminant white > point transformation, and specify that display profiles are to lie about > their media white point. This means that, using a standard CMM with the > usual 4 intent selections, you can't recover the instrument readings or > use the display profile for soft proofing. > > This whole approach flies in the face of logic. For print media > the illuminant is independent of the media itself, so it's quite > logical to specify that the media be evaluated and measured > under a given illuminant spectrum such as D50, and if this > is not possible, to allow for a separate chromatic transformation > (the chad tag) between the actual illuminant used and the standard > illuminant. The remaining chromatic transform is then a (usually a > small one) from the actual media under D50 to PCS D50. > > A display on the other hand has an "illuminant" that is physically > inseparable from the "media". So it is nonsense to apply a chromatic > adaption from it's media white to D50 as if it were a change > in illumination, since a change of illumination is physically impossible. > >> My understanding of V2 ICC profiles is that there are two ways to >> specify a V2 ICC profile's source white point: >> 1. You can either put the source white point in the media white point >> tag (for example D65 for sRGB). >> 2. Or you can put the ICC D50 illuminant values in the media white point >> tag and include a chad tag that gives the chromatic adaptation matrix >> from the source white point to the ICC D50 illuminant. > > The chad tag was a latter addition, so there are V2 display profiles > that do 2. without containing a chad tag. > >> An alternative interpretation of the quote from Annex A is that for at >> least some ICC profiles, perhaps including the D65 sRGB profile, the >> media white point tag should *always* read D50 even for V2 sRGB profiles. > > The reality is that this annex section was added extremely late in > the piece, and doesn't at all represent the reality of ICCV2 display > profiles - witness sRGB and AdobeRGB. > >> Does the quote from Annex A: >> >> 1. Apply specifically to sRGB, because sRGB is (sometimes) used as a >> monitor profile? And if the quote does apply to sRGB, does this mean >> that V2 sRGB profiles that have the sRGB D65 XYZ values in the media >> white point tag actually violate the (or perhaps some particular version >> of the) V2 ICC specifications? > > It can't possibly apply to the Microsoft/HP sRGB profile, because it was > issued well after the profile was created and widely distributed. > >> 2. Apply to *any* ICC profile that has 'mntr' in the header, which would >> include AdobeRGB1998 and ProPhotoRGB? > > See above. You can't magically make all existing profiles and CMM conform > to a retrospective change in the existing practice. > >> 3. Apply only to the particular device ICC profile that is being used as >> the display device profile in a particular color-managed workflow? > > See above. > >> 4. Some other case? > > My advice would be to apply it in no situation for ICC V2 profiles, unless > you are prepared to somehow guess or can determine that an ICC V2 profile > uses the V4 scheme of things. The presence of a chad tag and a D50 media > white point may be a reasonable guess, but this isn't guaranteed, because > there was a long period of confusion even after the introduction of the > chad tag to V2, so there may well be profiles out there in which the chad tag > represents the transformation from the display white point to PCS D50, > rather than from display white point to "D50 illuminant". > >> In whatever cases where the quote from Annex A might apply, is it >> suggestive (can be done, but not mandated) or normative (must be done or >> else the profile violates the V2 ICC specifications)? > > See above. I would ignore it as merely an attempt to re-write history. > > The approach I've taken in Argyll and icclib is a more pragmatic one, that > recognizes the reality of the wide spread sRGB and AdobeRGB profiles, > industry best practice in regard to chromatic transformations, and > the importance of the ICC profile being a representation of the basic, > measurable device behavior. I'm simply using a proper chromatic > adaptation transform instead of the "Wrong Von Kries". This means > that it properly complements the one used in sRGB and AdobeRGB, so > that soft proofing and recovery of the measurement values is possible > using absolute colorimetric, while having minimal impact on interoperability > of print profiles, because most media has a very small white point shift, > while vastly improving the chromatic transform appearance for display profiles > and tinted media by the application of a better chromatic white point > transformation. > > This approach sacrifices a small measure of interoperability > between CMM's in an area that was already fraught with incompatibility, for > much better utility and compatibility with widely used profiles, as well > as better visual performance. > > ICC v4 poses a number of problems in conforming to the "wrong Von Kries" > media white point transform, as well as the "display profiles shall be > chromatically transformed to D50" specification, even if it is less > ambiguous than V2. > > An approach that I've considered is: > > 1) Make the CMM "absolute colorimetric" intent undo the chad tag effect > for display profiles. > > 2) For any profile that has a media white != D50: > > * Transform the profile data from relative to absolute using "Wrong Von > Kries" > as per the ICC spec. > > * Create a new relative colorimetric etc. intent data by forward > transforming > the absolute data using a proper chromatic transformation. > > The latter is fraught with issues about aligning any other auxiliary data with > the change in relative/perceptual/saturation values, so it is also tempting > to simply use the same approach as V2, and use a proper chromatic adaption > transform rather than "Wrong Von Kries". > > Graeme Gill. > ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
