APCA constants - consistent naming

[svgeesus]

(I would raise an issue on the constants in WCAG 3, but they haven't been added yet until https://github.com/w3c/silver/pull/570 is merged)

The problem

The Current APCA Constants ( 0.0.98G - W3 last changed Feb 15, 2021 ) lists constants, but gives no equations.

The APCA Base Math (sRGB) lists constants and equations, but the names used are not the same and the set of constants is not exactly equivalent.

When implementing, I mainly used the value of the constants to check equivalence (which kind of defeats the point of named constants) but clearly this fails if two constants have the same value and the mapping is not immediately obvious.

Correspondences

The correspondences seem to be:

Constant	Value	Base Math
exponents
mainTRC	2.4	no name
normBG	0.56	no name
normTXT	0.57	no name
revTXT	0.62	no name
revBG	0.65	no name
colorSpace
sRco	0.2126729	no name
sGco	0.7151522	no name
sBco	0.0721750	no name
clamp
blkThrs	0.022	Bthresh
blkClmp	1.414	Bexp
loClip	0.1	Pout
deltaYmin	0.0005	Pin
scalers
scaleBoW	1.14	Rscale
loBoWoffset	0.027	Woffset
scaleWoB	1.14	Rscale
loWoBoffset	0.027	Woffset

Suggested fixes

1. Give the un-named constants names
2. Change B_exp to B_clmp, or otherwise make the correspondence obvious
3. Either change P_out to something like Clip_low, or change loClip to Pout
4. Either change P_in to something like deltaY_min, or change deltaYmin to Pin
5. Either decide that the WoB and BoW scalers and offsets might be different, and thus mint new names for use in base math (like BoW_scale, WoB_scale, BoW_offset, WoB_offset )or decide that they will be the same going forward and mint just two new names for the constants, like scale and offset.

Also

In addition, please be aware that the chosen 5-digit chromaticity values for D65 differ slightly from the 4-digit ones used in CSS Color 4 (the latter being changed several times, although we finally went for the 4-digit ones throughout for consistency with the defining color space specifications) and also that the matrix coefficients for RGB to Y also differ from both CSS and the sRGB specification. The CSS ones were calculated from first principles and agree with the sRGB standard ones when rounded to 8 significant figures.

[Myndex]

If I understand it, just the consistency between the code and the LaTeX svg? I probably should just lose the LaTeX as it's probably more confusing than helpful.

The constants in the LaTeX are intentionally different, as it originated at a time when the code was changing rapidly including variable names etc. The LaTeX does not really serve a purpose anymore as I think of it. It would probably be best at this point to create a pseudocode, or just show the basic JS.

Regarding PR #213 or #570 (or the #568 which I closed to make #570, trying to figure out why they are not being merged, and not getting any answers) Most recently I was told that that entire page would be deleted so that it was no longer something linked to, which is probably ideal.

Regarding the D65 and the chromaticity coefficients: I am using the BruceLindbloom ones also intentionally, as there was some experimentation in the past regarding the coefficients relating to certain impairments, and I wanted it to be easily recognizable that they were different.

But as discussed in other threads, those will change as I align things to the CSS 4 values for all of the standard "CIE/IEC" stuff.

[svgeesus]

The constants in the LaTeX are intentionally different, as it originated at a time when the code was changing rapidly including variable names etc. The LaTeX does not really serve a purpose anymore as I think of it. It would probably be best at this point to create a pseudocode, or just show the basic JS.

As long as the equations are clearly documented such that they can be independently implemented.

[Myndex]

I am working on organizing and cleaning up documentation, and streamlining it to improve access and understanding.