- From: Phil Green <green@colourspace.demon.co.uk>
- Date: Sun, 3 Sep 2017 20:56:27 +0200
- To: public-colorweb@w3.org
Hi Pierre, Peter Tristimulus normalization is a convention used in colour management where Y=1 for the white point. If you omit this step you will get some strange numbers when applying the component transfer function. The sRGB encoding is defined by IEC as having a black point of Y=0, but this is not expected to be achieved on any real display viewed in the sRGB viewing enviroment of 64 lux illuminance. The purpose of the 0.2 cd/m2 black point luminance of the reference display is to provide a practical recommendation for exchanging colorimetry between different real media, where if you assume a black point of zero cd/m2 you can end up with effects such as clipping. However, the ICC v2 sRGB profile sRGB2014.icc (available from http://www.color.org/srgbprofiles.xalter#v2) is fully compatible with the IEC specification, as amended in 2014. Phil Green ICC Technical Secretary On 03/09/2017 20:26, Pierre-Anthony Lemieux wrote: > Hi Peter, > > As mentioned in Ref. 1, "These equations are not provided in IEC > 61966-2-1, and are an additional interpretation provided in this > document." > > There is no justification for these equations, and I would therefore > disregard them until someone provides one :) > > Best, > > -- Pierre > > On Sun, Sep 3, 2017 at 11:18 AM, Peter Occil <poccil14@gmail.com> wrote: >> That is actually only the case once XYZ is "normalized", so that Y = 0 is >> the (sRGB) black point and Y = 1 is the white point. >> >> However, the document I previously linked to (which is actually from the ICC >> and at ref. 1), at section A.6, suggests that XYZ values are normalized >> taking into account the veiling glare luminance ("black point" luminance) >> (in addition to the white point luminance), rather than taking into account >> just the white point luminance, which I presumed was the case until now. >> (Note that each of the two normalizations will result in a different meaning >> for Y = 0.) Hence my question on what luminance (either 0 or 0.2 cd/m^2) >> sRGB's "black point" is. >> >> Ref. 1. http://www.color.org/chardata/rgb/sRGB.pdf >> >> >> >> On 09/03/2017 01:00 PM, Pierre-Anthony Lemieux wrote: >>>> Is it true that the "sRGB black point" (what sRGB defines as black) has >>>> a luminance of 0.2 cd/m^2 (absolute Y = 0.2) >>>> rather than 0 cd/m^2 (absolute Y = 0, the start of the absolute XYZ >>>> scale)? >>> ISO 61966-2-1 [1] specifies that [X Y Z] = [0 0 0] yields [R G B] = >>> [0 0 0] (see equation 8). >>> >>> Furthermore, quantized 8-bit R8 = 255 R' , where R' is non-linear R, >>> (see equation 4) >>> >>> and R' = 12.92 R when R' < 0.04045. (see equation 5) >>> >>> ... so R8 = 0 when [X Y Z] = [0 0 0] , with the same reasoning >>> applying to G8 and B8. >>> >>> Let me know if I got this wrong. >>> >>> Best, >>> >>> -- Pierre >>> >>> [1] https://webstore.iec.ch/publication/6169 >>> >>> On Sun, Sep 3, 2017 at 5:05 AM, Peter Occil <poccil14@gmail.com> wrote: >>>> While I'm at it, that document contains a very questionable statement >>>> about >>>> the "black point" of sRGB, suggesting that the "black point" has a >>>> "veiling >>>> glare luminance" of 0.2 cd/m^2 (and indeed that suggestion appears >>>> further >>>> in some of the formulas in that document). Is it true that the "sRGB >>>> black >>>> point" (what sRGB defines as black) has a luminance of 0.2 cd/m^2 >>>> (absolute >>>> Y = 0.2) rather than 0 cd/m^2 (absolute Y = 0, the start of the absolute >>>> XYZ >>>> scale)? >>>> >>>> >>>> >>>> On 09/02/2017 03:28 PM, Peter Occil wrote: >>>>> I'm aware of the following document posted on the W3C Web site: >>>>> >>>>> https://www.w3.org/Graphics/Color/srgb >>>>> >>>>> I find it very useful as a reference, but: Where did this document come >>>>> from? Who were its authors? When was it posted? I couldn't find it >>>>> linked >>>>> anywhere on the W3C site except on a mailing list message (ref. 1). >>>>> >>>>> Ref. 1. https://lists.w3.org/Archives/Public/www-style/2016Sep/0061.html >>>>> > . >
Received on Sunday, 3 September 2017 19:37:05 UTC