Matrix-based extensibility

[svgeesus]

Should we provide conveniences for matrix-based color spaces? Otherwise users need to supply their own matrix multiply (and possibly matrix invert).

Generalized libraries will be heavier in weight, while colorspace conversion just needs 3 x 1 and 3 x 3 multiply, and 3 x 3 invert.

[svgeesus]

In other words, to register a custom RGB colorspace: instead of computing off to the side the toXYZ and fromXYZ matrices, which requires access to a matrix multiply and matrix invert, the user would supply the red,green,blue and white chromaticities and the API would do the calculations and register the result.

The user would still need to provide functions to do the linearization and the gamma-encoding

[LeaVerou]

One problem is the Web Platform does not have a standard Matrix object. There’s DOMMatrix but that covers a very specific use case.
So if we add something like this, we'd need to accept matrices as an array of arrays (like in Color.js).

Also, it's pretty easy to write a helper that does this, so I'm not sure it has a place in the native API, at least in L1.

[svgeesus]

we'd need to accept matrices as an array of arrays (like in Color.js)

Yes. I meant matrix-based in distinction to lookup-based (like CMYK colorspace definitions).