Questions about profiles, alpha and miscellaneous

[gmcusaro]

I spent time studying all the documentation and various discussions. I have below some questions on different topics. I apologize if I should have separated them into multiple threads, I preferred to avoid spam. My doubts and questions refer to the version APCA-W3.

---

1. About alpha value in this your post on StackOverflow. Today we can say that the function alphaBlend is a solution or the solution?

function alphaBlend (rgbaFG=[0,0,0,0.6], rgbBG=[0,0,0], isInt = true )
// alpha = 0.6 for  example

1.1 The default background value is rgbBG=[0,0,0]. Wouldn't it be better to [255,255,255] as the default? Today dark mode (google material etc..) is never pure black, instead in light mode it is almost always pure white and I think it happens often.

1.2 About comment on alpha:

Only foreground has alpha of 0.0 to 1.0

We assume that the alpha component is also expected. What happens when click to swap like your demo inverting foreground with background? Now the background value has the alpha component and obviously you don't know the real background.

1.3 About comment on gamma:

This blends using gamma encoded space (standard)

Should a gamma value be used based on the profile used? 2.35 for adobeRGB, 2.4 for displayP3 and sRGB etc...

---

2. Considering 6 profiles + XYZ that will be supported in the future, see the draft CSS Color Module Level 4 and color() function in detail.

2.1 sRGB and sRGB-linear.
I believe it is the developer's job to adjust the non-linear sRGB values ** before ** running the functionsRGBtoY. Right?

function sRGBtoY (rgb = [0,0,0])

This divides the values by 255 Math.pow(chan/255.0, mainTRC). In the future, RGB values with a range of 0-1 will be used more because it is more precise with wider profiles. Can it be useful to use Regex or another way to check the range type and always convert integers to decimals?

2.2 About ProPhoto you wrote:

"That said I have long objected to it for use in web content because it can not be a display profile."

I'm totally agree!

2.3 Function for Rec.2020 e XYZ today are missing or like ProPhoto do you think they are not to be taken into consideration?

---

3. Very interesting your answer on all caps. Are there notes about differences between sans-serif and serif? Now, is this topic irrelevant and is enough to check the x-height ratio with an increment to satisfy the value at 0.52?

You wrote (on Times New Roman - serif):

For instance, Times New Roman has an x-height ratio of 0.45, so it needs to be increased about 16% in size.

---

4. About sRco sGco sBco and values xW yW K xR yR xG yG xB yB used in every function

As xW and yW (white point D65 CIE 1931 2° I think ) you used 0.312720 and 0.329030.
On Wikipedia I found different values: x: 0.31271 and y: 0.32902.

The temperature is the same (CCT K) 6504.
(For the future it would be useful to test the CIE 1964 10° values ​​as well or add an option?)

What sources are used for xW, yW and for the x and y RGB chromatic coordinates?
Even most important what functions has been used to calculate sRco - sGco - sBco? I found only calculated values.

---

5. Finally some curiosities about your demo.
   What does the score 4 on left represent? In this beta what are the details of the scores from 1 to 5?

🚫 is clear. N values have a different font (sans serif and serif). Does it have any meaning and what do they indicate?

Thanks in advance for your time! 🙏

[Myndex]

Hi Giovanni @gmcusaro

I spent time studying all the documentation and various discussions. I have below some questions on different topics. I apologize if I should have separated them into multiple threads, I preferred to avoid spam.

One thread is good, everything is related.

1. About alpha value in this your post on StackOverflow. Today we can say that the function alphaBlend is a solution or the solution?

alphaBlend is just the standard CSS alpha function.

1.1 The default background value is rgbBG=[0,0,0]. Wouldn't it be better to [255,255,255] as the default? Today dark mode (google material etc..) is never pure black, instead in light mode it is almost always pure white and I think it happens often.

If both colors are not present it probably should be a failure, possibly the best default would be [160,160,160] as that's about the middle contrast point. For more on this see my article and related CodePen "Lets Flip For Color"

1.2 We assume that the alpha component is also expected. What happens when click to swap like your demo inverting foreground with background? Now the background value has the alpha component and obviously you don't know the real background.

Well the online tool currently doesn't support alpha at all. It's an open question as to how a tool maker might want to handle this, my position is always so long as the inputs and the results are clear, in other words so that the user knows that the tool is using Alpha in the calculation.

1.3 About comment on gamma:

This blends using gamma encoded space (standard)
Should a gamma value be used based on the profile used? 2.35 for adobeRGB, 2.4 for displayP3 and sRGB etc...

No, what is meant is, as in the CSS version of alpha blend, there is no linearization of the colors before the blending occurs.

And importantly don't take the listed gamma values in the sRGBtoY as canonical as they are only for the purpose of the overall math of emulating real world monitor conditions as viewed by a human, and should not be utilized for any other form of signal processing.

---

2. Considering 6 profiles + XYZ ....
   2.1 sRGB and sRGB-linear. I believe it is the developer's job to adjust the non-linear sRGB values ** before ** running the functionsRGBtoY. Right?

No, sRGBtoY assumes the standard sRGB TRC ("gamma") encoded values ONLY.

sRGB-linear is just rec709/sRGB primaries with a 1.0 gamma, it is not a normal monitor setting. More on real world monitors in a moment.

function sRGBtoY (rgb = [0,0,0]) This divides the values by 255 Math.pow(chan/255.0, mainTRC). In the future, RGB values with a range of 0-1 will be used more because it is more precise with wider profiles. Can it be useful to use Regex or another way to check the range type and always convert integers to decimals?

In the future, the values are 0.0-255.0 per CSS level 4 (last I checked) this is being doen for backwards compatibility as I understand it.
....but Apple is presently 0.0-1.0 for P3... so,... the best I can say is I am following developments in these other standards, and will continue to align to them.

Things like range checking are a part of colorParsley(), which uses extensive regex for not just range but type checking.

2.2 About ProPhoto you wrote

"That said I have long objected to it for use in web content because it can not be a display profile."
I'm totally agree!

👍 I think of the web as a delivery pipeline, and therefore the intrinsically supported spaces should be delivery spaces, meaning spaces that can be realized in actual reality.

2.3 Function for Rec.2020 e XYZ today are missing or like ProPhoto do you think they are not to be taken into consideration?

So here, Rec2020 defines a realizable monitor, and is definitely in the pipeline, as is rec2100 and other HDR types, though these pose new issues.

XYZ is not a realizable colorspace, BUT it is the "hub" of color spaces if you will, but by itself lacks the information needed to predict human perceptual contrast. There's lot I could write about the nuances of matrix-in & matrix-out of XYZ, and the effect of intended system gamma gain on actual system performance. The upshot is, we should be calculating contrast only for the specific space that is being used by the viewer.

3_. Very interesting your answer on all caps. Are there notes about differences between sans-serif and serif? Now, is this topic irrelevant and is enough to check the x-height ratio with an increment to satisfy the value at 0.52?_

I'm sorry I don't understand your question? Also, just FYI, I'm moving toward making the "base" x-height 0.5.

4. About sRco sGco sBco and values xW yW K xR yR xG yG xB yB used in every function
As xW and yW (white point D65 CIE 1931 2° I think ) you used 0.312720 and 0.329030. On Wikipedia I found different values: x: 0.31271 and y: 0.32902.

Wikipedia's all over the place... the values I used are the canonical from CIE 15:2004 3rd Edition ISBN 3 901 906 33 9

At various times you may be seeing some variation of the ASTM values, or earlier CIE values, or ... something.

I may very well revert to CSS level 4 values, and make up the differences elsewhere....

The temperature is the same (CCT K) 6504. (For the future it would be useful to test the CIE 1964 10° values ​​as well or add an option?)

I don't think so, APCA is all about readability contrast, reading occurs in the central foveal area and so that's where contrast calculations are focused right now. I do have other technologies that are developed not released that address things like Central field loss and blue light interference for those that have to read in the periphery. Those will not be a part of any W3 release of APCA, as the editors of WCAG 3 told me that they don't want any "new" science incorporated into any standards.

What sources are used for xW, yW and for the x and y RGB chromatic coordinates? Even most important what functions has been used to calculate sRco - sGco - sBco? I found only calculated values.

See above. Also, for calculations, I will eventually be folding them into my SeeLab project, but you can find the needed math at Bruce Lindbloom's: http://brucelindbloom.com

5. Finally some curiosities about your demo.
What does the score 4 on left represent? In this beta what are the details of the scores from 1 to 5?

An early version is described in detail here, but currently status in terms of the total WCAG 3 is unknown. ALSO this page has not been updated to the new math.

🚫 is clear. N values have a different font (sans serif and serif). Does it have any meaning and what do they indicate?

Hmmm... the "meaning" is that your browser is not downloading the required fonts correctly. Can you send be your concole log for the page please?

Thank you!

[gmcusaro]

Thanks for all the answers I took some time to read everything carefully and do some calculations.

In the future, the values are 0.0-255.0 per CSS level 4 (last I checked) this is being done for backwards compatibility as I understand it.
....but Apple is presently 0.0-1.0 for P3... so,... the best I can say is I am following developments in these other standards, and will continue to align to them.

I refer in detail to the color function. It use only colors in the 0-1 range regardless of the specified color profile example color(a98-rgb 0.964 0.763 0.787).

I'm sorry I don't understand your question? Also, just FYI, I'm moving toward making the "base" x-height 0.5.

Sorry my English is bad... I know! 😅 Is the difference between serif and sans-serif an element to keep in consideration for the contrast calc? Like different font weights, can make sense the difference between these two font categories?

Wikipedia's all over the place... the values I used are the canonical from CIE 15:2004 3rd Edition ISBN 3 901 906 33 9

Yeah! Wikipedia is not always reliable. I hope I have used the right document, but I have not been able to find all the illuminants and often values with a few decimals.

I will eventually be folding them into my SeeLab project, but you can find the needed math at Bruce Lindbloom's: http://brucelindbloom.com

About math at Bruce Lindbloom's, is this the formula xyz -> xyY you are referring to?

Is this your source of x y for primitive RGB values?

Here you can find a table (see even my screenshot). Working spaces highlighted in yellow needed adaptation.
Let's consider for example ProPhoto RGB, only because the white point has not been converted because it is already D50. If we look at the x y coordinates of ProPhotoRGB.icc (downloaded from color.org) they are not the same (see image).
Now, on ours displays, the .icc .icm files saved in our systems by default, or installed by Photoshop see Lindbloom, render colors.
I think we should refer to these and not to the values of a site that is certainly authoritative but not infallible.
I even tried to do a conversion of x y sRGB (highlighted in yellow) from D65 to D50 using the Bradford transform. I didn't get the same values. If these data are incorrect, nothing will be correct in the contrast calculations. I'm doing it wrong?

For completeness I computed the normalized primary matrix and its inverse directly at full machine precision from sRGB- (After other tests, even conversions between white points also don't seem very accurate.).

Regardless of the values, even the calculation of the inverse matrix alone often doesn't seem completely correct.
I read that you have already commented something about it.

Hmmm... the "meaning" is that your browser is not downloading the required fonts correctly. Can you send be your concole log for the page please?

I used Safari 15.2 on macOS Montery 12.1 (21C52). On Google Chrome 98.0.4758.80 it looks ok.
Here console.txt

Thanks again for your time! 🙏

[Myndex]

Hi @gmcusaro

Is the difference between serif and sans-serif an element to keep in consideration for the contrast calc? Like different font weights, can make sense the difference between these two font categories?

Yes, font type and glyph design all have a market impact on contrasting readability in various ways. We have not yet specific guidelines other than equalizing factors such as x height and letter spacing.

About math at Bruce Lindbloom's, is this the formula xyz -_> _xyY you are referring to?
Is this your source of x y for primitive RGB values?

No, see: http://www.brucelindbloom.com/Eqn_RGB_XYZ_Matrix.html

Here you can find a table (see even my screenshot). Working spaces highlighted in yellow needed adaptation. Let's consider for example ProPhoto RGB, only because the white point has not been converted because it is already D50.

Why are you using D50?

I used Safari 15.2 on macOS Montery 12.1 (21C52). On Google Chrome 98.0.4758.80 it looks ok. Here console.txt

Thank you so much for your Console log… So you're saying this only happens on safari not chrome? I need to look into this thank you.

[gmcusaro]

Hi @Myndex ,

No, see: http://www.brucelindbloom.com/Eqn_RGB_XYZ_Matrix.html

I was referring to the formula for calculating xyY from xyz see below.

Why are you using D50?

You are right! The values must stay with the white point D65.
In apca-w3.js, func sRGBtoY there are these values:

// xW	yW	K	xR	yR	xG	yG	xB	yB
// 0.312720	0.329030	6504	0.640	0.330	0.300	0.600	0.150	0.060

Ok, for xW and yW maybe there is a bit of confusion with a plethora of white point.

About xR - yR - xG - yG - xB - yB, these values where do they come from? brucelindbloom.com?

If I use a color like color(a98-rgb 0.964 0.763 0.787) (func color() CSS4) these values xR - yR - xG - yG - xB - yB must be those of Adobe RGB and not sRGB. It's correct?

To calculate the Y of xyY did you use this formula? If not which one?

Thank you so much for your Console log… So you're saying this only happens on safari not chrome? I need to look into this thank you.

It is confirmed only with Safari!