- From: Andrew Somers via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Sep 2021 22:02:44 +0000
- To: public-css-archive@w3.org

Hi Chris @svgeesus > _Currently they are defined (in the definitions for the predefined rgb spaces, and in the sample code) but not in a way that can be easily referenced from other specifications:_ I did eventually find many of them, but.... > _For D65 > in the definition of each predefined rgb space, as xy chromaticity: > White chromaticity 0.31272 0.32903 (D65)_ The pre-calculated matrix for sRGB to XYZ (and the inverse) in the CSS code section appears to be calculated with x y 0.312700 0.329000 Instead of the CIE values that you indicated above, partly why I was wondering as I've been testing some things here, and increasingly notice discrepancies in terms of what the correct values are (not CSS per se, everywhere) ... and I started looking into this a bit more when I ran across a comment you posted on Stack about Bruce's numbers not calculating the same... and poking around I realized that there is ample opportunity to grab "wrong numbers" that "might" have more of an actual effect than the sRGB TRC threshold error that had crept into WCAG 2. Probably not for round trips in the same view since the return error should cancel out. For instance: ASTM E308-01 (BL's source) x 0.3127266150 y 0.3290231300 ICC v4 x 0.3127159070 y 0.3290014810 Naturally if someone is round-tripping in the same view using the same code, it's not likely to matter as the reverse matrix will just undo the error in the forward matrix... but that can still go wrong and lead to inconsistencies... ### Run Time Matrix? And I'm wondering about building the matrix at run time (page load), building a matrix is fairly straight forward, and would only need to run once at load (for non sRGB spaces of course). The advantage is that it's easier to see and verify code by eye a few **xy** coordinates, as opposed to evaluating the bigger and more arcane numbers in a matrix. It also provides a level of future proofing, if there was an exposed method that simply took four pairs of coordinates to create the matrixes, then some arbitrary RGB space could be added at will with minimal effort (this is not considering the CMM portion of this for the moment in this hypothetical). For instance, let's take ProPhoto: > _For D50, in the code, as relative XYZ_ > var white = [0.96422, 1.00000, 0.82521]; // D50 reference white > _In the definition of ProPhoto, as xy chromaticity > White chromaticity 0.345704 0.358540 (D50)_ So that xy of 0.345704 0.358540 calculates to a normalized WP of var white = [ 0.964199252524126, 1.0, 0.824889830981201 ]; // calculated D50 from ProPhoto It's not a big error by itself relative to the pre-calculated WP, only ∆E 0.022 or so, nevertheless it led to this thought: the math to build a matrix and WP is fairly easy, assuming only for non-sRGB spaces, only needs to run at page load for a non-sRGB space. Using constants that are at the "upper root" level of chromaticity coordinates and creating the matrix at runtime for the non-sRGB spaces seems like it could be ideal for flexibility, accuracy, consistency... ? A -- GitHub Notification of comment by Myndex Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6618#issuecomment-921285202 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 16 September 2021 22:02:46 UTC