@texel/color 1.1.2 → 1.1.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -1
- package/package.json +1 -1
- package/src/gamut.js +4 -2
- package/test/almost-equal.js +0 -15
- package/test/banner.png +0 -0
- package/test/bench-colorjs.js +0 -227
- package/test/bench-culori.js +0 -148
- package/test/bench-node.js +0 -51
- package/test/bench-size.js +0 -12
- package/test/canvas-graph.js +0 -212
- package/test/check-gamut-epsilon.js +0 -136
- package/test/colorjs-fn.js +0 -34
- package/test/example-interpolation.js +0 -107
- package/test/logo.js +0 -112
- package/test/logo.png +0 -0
- package/test/profiles/DisplayP3.icc +0 -0
- package/test/spaces/hsl.js +0 -87
- package/test/spaces/lab.js +0 -60
- package/test/test-colorjs.js +0 -86
- package/test/test-other-spaces.js +0 -115
- package/test/test.js +0 -451
- package/tools/__pycache__/calc_oklab_matrices.cpython-311.pyc +0 -0
- package/tools/calc_oklab_matrices.py +0 -233
- package/tools/print_matrices.py +0 -509
|
@@ -1,233 +0,0 @@
|
|
|
1
|
-
"""
|
|
2
|
-
Calculate `oklab` matrices.
|
|
3
|
-
|
|
4
|
-
Björn Ottosson, in his original calculations, used a different white point than
|
|
5
|
-
what CSS and most other people use. In the CSS repository, he commented on
|
|
6
|
-
how to calculate the M1 matrix using the exact same white point as CSS. He
|
|
7
|
-
provided the initial matrix used in this calculation, which we will call M0.
|
|
8
|
-
https://github.com/w3c/csswg-drafts/issues/6642#issuecomment-945714988.
|
|
9
|
-
This M0 matrix is used to create a precise matrix to convert XYZ to LMS using
|
|
10
|
-
the D65 white point as specified by CSS. Both ColorAide and CSS use the D65
|
|
11
|
-
chromaticity coordinates of `(0.31270, 0.32900)` which is documented and used
|
|
12
|
-
for sRGB as the standard. There are likely implementations unaware that the
|
|
13
|
-
they should, or even how to adapt the Oklab M1 matrix to their white point
|
|
14
|
-
as this is not documented in the author's Oklab blog post, but is buried in a
|
|
15
|
-
CSS repository discussion.
|
|
16
|
-
|
|
17
|
-
Additionally, the documented M2 matrix is specified as 32 bit values, and the
|
|
18
|
-
inverse is calculated directly from the this 32 bit matrix. The forward and
|
|
19
|
-
reverse transform is calculated to perfectly convert 32 bit values, but when
|
|
20
|
-
translating 64 bit values, the transform adds a lot of noise after about 7 - 8
|
|
21
|
-
digits (the precision of 32 bit floats). This is particularly problematic for
|
|
22
|
-
achromatic colors in Oklab and OkLCh and can cause chroma not to resolve to zero.
|
|
23
|
-
|
|
24
|
-
To provide an M2 matrix that works better for 64 bit, we take the inverse M2,
|
|
25
|
-
which provides a perfect transforms to white from Oklab `[1, 0, 0]` in 32 bit
|
|
26
|
-
floating point. We process the matrix as float 32 bit values and emit them as 64
|
|
27
|
-
bit double values, ~17 digit double accuracy. We then calculate the forward
|
|
28
|
-
matrix. This gives us a transform in 64 bit that drives chroma extremely close
|
|
29
|
-
to zero for 64 bit doubles and maintains the same 32 bit precision of up to about
|
|
30
|
-
7 digits, the 32 bit accuracy limit (~7.22).
|
|
31
|
-
|
|
32
|
-
To demonstrate that our 64 bit converted matrices work as we claim and does not
|
|
33
|
-
alter the intent of the values, we can observe by comparing the documented matrices
|
|
34
|
-
(adjusting for our white point).
|
|
35
|
-
|
|
36
|
-
Below we demonstrate by first using the documented 32 bit M2 matrix (adjusting the
|
|
37
|
-
M1 for our white point). This is what most implementations do, though some may not
|
|
38
|
-
properly correct the M1 matrix for their white point. Notice how the lightness for
|
|
39
|
-
white is only accurate up to about 7 digits making the expected value of 1 not very
|
|
40
|
-
accurate. Also notice that a and b do not resolve as close to 0. The a value is
|
|
41
|
-
pretty good, but the b value is substantially worse. Also notice the first 7 digits
|
|
42
|
-
(the 32 bit precision) for red, green, and blue as they will be used for comparison.
|
|
43
|
-
|
|
44
|
-
```
|
|
45
|
-
>>> from coloraide.everything import ColorAll as Color
|
|
46
|
-
>>> import numpy as np
|
|
47
|
-
>>> Color('white').convert('oklab')[:]
|
|
48
|
-
[0.9999999935000001, -1.6653345369377348e-16, 3.729999997759137e-08, 1.0]
|
|
49
|
-
>>> [np.float32(c) for c in Color('red').convert('oklab', norm=False)[:]]
|
|
50
|
-
[0.6279554, 0.22486307, 0.1258463, 1.0]
|
|
51
|
-
>>> [np.float32(c) for c in Color('green').convert('oklab', norm=False)[:]]
|
|
52
|
-
[0.51975185, -0.14030233, 0.107675895, 1.0]
|
|
53
|
-
>>> [np.float32(c) for c in Color('blue').convert('oklab', norm=False)[:]]
|
|
54
|
-
[0.4520137, -0.03245697, -0.31152815, 1.0]
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
When we use our 64 bit adjusted M2 matrix, we now get a precise 1 for lightness
|
|
58
|
-
when converting white and get zero or nearly zero for a and b. When comparing the
|
|
59
|
-
first 7 digits to the previous example we get the same values. Anything after
|
|
60
|
-
~7 digits is not guaranteed to be the same.
|
|
61
|
-
|
|
62
|
-
```
|
|
63
|
-
>>> from coloraide.everything import ColorAll as Color
|
|
64
|
-
>>> import numpy as np
|
|
65
|
-
>>> Color('white').convert('oklab')[:]
|
|
66
|
-
[1.0, -5.551115123125783e-17, 0.0, 1.0]
|
|
67
|
-
>>> [np.float32(c) for c in Color('red').convert('oklab', norm=False)[:]]
|
|
68
|
-
[0.6279554, 0.22486307, 0.12584628, 1.0]
|
|
69
|
-
>>> [np.float32(c) for c in Color('green').convert('oklab', norm=False)[:]]
|
|
70
|
-
[0.51975185, -0.14030233, 0.10767588, 1.0]
|
|
71
|
-
>>> [np.float32(c) for c in Color('blue').convert('oklab', norm=False)[:]]
|
|
72
|
-
[0.45201373, -0.032456975, -0.31152818, 1.0]
|
|
73
|
-
```
|
|
74
|
-
|
|
75
|
-
Okhsl is completely calculated using 32 bit floats as that is how the author
|
|
76
|
-
provided the algorithm, but we can see that when we calculate the new coefficients,
|
|
77
|
-
using our M1 and 64 bit adjusted M2 matrices, that we preserve the 32 precision.
|
|
78
|
-
Anything after ~7 digits is just noise due to the differences in 32 bit and 64 bit.
|
|
79
|
-
|
|
80
|
-
Comparing to the actual values returned using the author's code in his Okhsl and Okhsv
|
|
81
|
-
color pickers:
|
|
82
|
-
|
|
83
|
-
```
|
|
84
|
-
// Okhsl
|
|
85
|
-
> var value = srgb_to_okhsl(255, 255, 255); value[0] *= 360; value
|
|
86
|
-
[89.87556309590242, 0.5582831888483675, 0.9999999923961898]
|
|
87
|
-
> var value = srgb_to_okhsl(255, 0, 0); value[0] *= 360; value
|
|
88
|
-
[29.23388519234263, 1.0000000001433997, 0.5680846525040862]
|
|
89
|
-
> var value = srgb_to_okhsl(0, 255, 0); value[0] *= 360; value
|
|
90
|
-
[142.49533888780996, 0.9999999700728788, 0.8445289645307816]
|
|
91
|
-
> var value = srgb_to_okhsl(0, 0, 255); value[0] *= 360; value
|
|
92
|
-
[264.052020638055, 0.9999999948631134, 0.3665653394260194]
|
|
93
|
-
|
|
94
|
-
// Okhsv
|
|
95
|
-
> var value = srgb_to_okhsv(255, 255, 255); value[0] *= 360; value
|
|
96
|
-
[89.87556309590242, 1.0347523928230576e-7, 1.000000027003774]
|
|
97
|
-
> var value = srgb_to_okhsv(255, 0, 0); value[0] *= 360; value
|
|
98
|
-
[29.23388519234263, 0.9995219692256989, 1.0000000001685625]
|
|
99
|
-
> var value = srgb_to_okhsv(0, 255, 0); value[0] *= 360; value
|
|
100
|
-
[142.49533888780996, 0.9999997210415695, 0.9999999884428648]
|
|
101
|
-
> var value = srgb_to_okhsv(0, 0, 255); value[0] *= 360; value
|
|
102
|
-
[264.052020638055, 0.9999910912349018, 0.9999999646150918]
|
|
103
|
-
```
|
|
104
|
-
|
|
105
|
-
And then ours. Ignoring the authors hue and our hue results for white
|
|
106
|
-
and the oddly high chroma for the author's achromatic white in Okhsl
|
|
107
|
-
(both of which are meaningless in an achromatic color), we can see that
|
|
108
|
-
that we match quite well up to ~7 digits.
|
|
109
|
-
|
|
110
|
-
```
|
|
111
|
-
# Okhsl
|
|
112
|
-
>>> Color('white').convert('okhsl', norm=False)[:]
|
|
113
|
-
[180.0, 0.0, 1.0, 1.0]
|
|
114
|
-
>>> Color('#ff0000').convert('okhsl', norm=False)[:]
|
|
115
|
-
[29.233880279627876, 1.0000001765854427, 0.5680846563197033, 1.0]
|
|
116
|
-
>>> Color('#00ff00').convert('okhsl', norm=False)[:]
|
|
117
|
-
[142.4953450414438, 1.0000000000000009, 0.8445289714936317, 1.0]
|
|
118
|
-
>>> [264.05202261637004, 1.0000000005848086, 0.36656533918708145, 1.0]
|
|
119
|
-
[264.05202261637004, 1.0000000005848086, 0.36656533918708145, 1.0]
|
|
120
|
-
# Okhsv
|
|
121
|
-
>>> Color('white').convert('okhsv', norm=False)[:]
|
|
122
|
-
[180.0, 0.0, 1.0, 1.0]
|
|
123
|
-
>>> Color('#ff0000').convert('okhsv', norm=False)[:]
|
|
124
|
-
[29.233880279627876, 1.0000004019360378, 0.9999999999999994, 1.0]
|
|
125
|
-
>>> Color('#00ff00').convert('okhsv', norm=False)[:]
|
|
126
|
-
[142.4953450414438, 0.9999998662471965, 1.0000000000000004, 1.0]
|
|
127
|
-
>>> Color('#0000ff').convert('okhsv', norm=False)[:]
|
|
128
|
-
[264.05202261637004, 1.000000002300706, 0.9999999999999999, 1.0]
|
|
129
|
-
"""
|
|
130
|
-
import sys
|
|
131
|
-
import os
|
|
132
|
-
import struct
|
|
133
|
-
|
|
134
|
-
sys.path.insert(0, os.getcwd())
|
|
135
|
-
|
|
136
|
-
# import tools.calc_xyz_transform as xyzt # noqa: E402
|
|
137
|
-
from coloraide import util # noqa: E402
|
|
138
|
-
from coloraide import algebra as alg # noqa: E402
|
|
139
|
-
|
|
140
|
-
"""Calculate XYZ conversion matrices."""
|
|
141
|
-
import sys
|
|
142
|
-
import os
|
|
143
|
-
|
|
144
|
-
sys.path.insert(0, os.getcwd())
|
|
145
|
-
|
|
146
|
-
xyzt_white_d65 = util.xy_to_xyz((0.31270, 0.32900))
|
|
147
|
-
xyzt_white_d50 = util.xy_to_xyz((0.34570, 0.35850))
|
|
148
|
-
xyzt_white_aces = util.xy_to_xyz((0.32168, 0.33767))
|
|
149
|
-
|
|
150
|
-
def xyzt_get_matrix(wp, space):
|
|
151
|
-
"""Get the matrices for the specified space."""
|
|
152
|
-
|
|
153
|
-
if space == 'srgb':
|
|
154
|
-
x = [0.64, 0.30, 0.15]
|
|
155
|
-
y = [0.33, 0.60, 0.06]
|
|
156
|
-
elif space == 'display-p3':
|
|
157
|
-
x = [0.68, 0.265, 0.150]
|
|
158
|
-
y = [0.32, 0.69, 0.060]
|
|
159
|
-
elif space == 'rec2020':
|
|
160
|
-
x = [0.708, 0.17, 0.131]
|
|
161
|
-
y = [0.292, 0.797, 0.046]
|
|
162
|
-
elif space == 'a98-rgb':
|
|
163
|
-
x = [0.64, 0.21, 0.15]
|
|
164
|
-
y = [0.33, 0.71, 0.06]
|
|
165
|
-
elif space == 'prophoto-rgb':
|
|
166
|
-
x = [0.7347, 0.1596, 0.0366]
|
|
167
|
-
y = [0.2653, 0.8404, 0.0001]
|
|
168
|
-
elif space == 'aces-ap0':
|
|
169
|
-
x = [0.7347, 0.0, 0.0001]
|
|
170
|
-
y = [0.2653, 1.0, -0.0770]
|
|
171
|
-
elif space == 'aces-ap1':
|
|
172
|
-
x = [0.713, 0.165, 0.128]
|
|
173
|
-
y = [0.293, 0.830, 0.044]
|
|
174
|
-
else:
|
|
175
|
-
raise ValueError
|
|
176
|
-
|
|
177
|
-
m = alg.transpose([util.xy_to_xyz(xy) for xy in zip(x, y)])
|
|
178
|
-
rgb = alg.solve(m, wp)
|
|
179
|
-
rgb2xyz = alg.multiply(m, rgb)
|
|
180
|
-
xyz2rgb = alg.inv(rgb2xyz)
|
|
181
|
-
|
|
182
|
-
return rgb2xyz, xyz2rgb
|
|
183
|
-
|
|
184
|
-
float32 = alg.vectorize(lambda value: struct.unpack('f', struct.pack('f', value))[0])
|
|
185
|
-
|
|
186
|
-
# Calculated using our own `calc_xyz_transform.py`
|
|
187
|
-
RGB_TO_XYZ, XYZ_TO_RGB = xyzt_get_matrix(xyzt_white_d65, 'srgb')
|
|
188
|
-
|
|
189
|
-
# Matrix provided by the author of Oklab to allow for calculating a precise M1 matrix
|
|
190
|
-
# using any white point.
|
|
191
|
-
M0 = [
|
|
192
|
-
[0.77849780, 0.34399940, -0.12249720],
|
|
193
|
-
[0.03303601, 0.93076195, 0.03620204],
|
|
194
|
-
[0.05092917, 0.27933344, 0.66973739]
|
|
195
|
-
]
|
|
196
|
-
|
|
197
|
-
# Calculate XYZ to LMS and LMS to XYZ using our white point.
|
|
198
|
-
XYZ_TO_LMS = alg.divide(M0, alg.outer(alg.matmul(M0, xyzt_white_d65), alg.ones(3)))
|
|
199
|
-
XYZD50_TO_LMS = alg.divide(M0, alg.outer(alg.matmul(M0, xyzt_white_d50), alg.ones(3)))
|
|
200
|
-
|
|
201
|
-
# Calculate the inverse
|
|
202
|
-
LMS_TO_XYZ = alg.inv(XYZ_TO_LMS)
|
|
203
|
-
LMS_TO_XYZD50 = alg.inv(XYZD50_TO_LMS)
|
|
204
|
-
|
|
205
|
-
# Calculate linear sRGB to LMS (used for Okhsl and Okhsv)
|
|
206
|
-
SRGBL_TO_LMS = alg.matmul(XYZ_TO_LMS, RGB_TO_XYZ)
|
|
207
|
-
LMS_TO_SRGBL = alg.inv(SRGBL_TO_LMS)
|
|
208
|
-
|
|
209
|
-
# Oklab specifies the following matrix as M1 along with the inverse.
|
|
210
|
-
# ```
|
|
211
|
-
# LMS3_TO_OKLAB = [
|
|
212
|
-
# [0.2104542553, 0.7936177850, -0.0040720468],
|
|
213
|
-
# [1.9779984951, -2.4285922050, 0.4505937099],
|
|
214
|
-
# [0.0259040371, 0.7827717662, -0.8086757660]
|
|
215
|
-
# ]
|
|
216
|
-
# ```
|
|
217
|
-
# But since the matrix is provided in 32 bit, we are not able to get the
|
|
218
|
-
# proper inverse for `[1, 0, 0]` in 64 bit, even if we calculate the a
|
|
219
|
-
# new 64 bit inverse for the above forward transform. What we need is a
|
|
220
|
-
# proper 64 bit forward and reverse transform.
|
|
221
|
-
#
|
|
222
|
-
# In order to adjust for this, we take documented 32 bit inverse matrix which
|
|
223
|
-
# gives us a perfect translation from Oklab `[1, 0, 0]` to LMS of `[1, 1, 1]`
|
|
224
|
-
# and parse the matrix as float 32 and emit it as 64 bit and then take the inverse.
|
|
225
|
-
OKLAB_TO_LMS3 = float32([
|
|
226
|
-
[1.0, 0.3963377774, 0.2158037573],
|
|
227
|
-
[1.0, -0.1055613458, -0.0638541728],
|
|
228
|
-
[1.0, -0.0894841775, -1.2914855480]
|
|
229
|
-
])
|
|
230
|
-
|
|
231
|
-
# Calculate the inverse
|
|
232
|
-
LMS3_TO_OKLAB = alg.inv(OKLAB_TO_LMS3)
|
|
233
|
-
|