purescript-contrib/purescript-colors

Support wider gamuts & device-independent colors

Opened this issue · 3 comments

toastal commented

-- | - Colors outside the sRGB gamut which cannot be displayed on a typical
-- | computer screen can not be represented by Color.

This ain't true anymore. DCI-P3 is quite common on phones and increasingly in monitors and laptops (such as my own). CSS4 opened up to color gamuts beyond sRGB https://www.w3.org/TR/css-color-4/#icc-colors. By choosing a device-independent color representation without gamma correction or color space clipping, device-dependent colors could be derived.

I would then suggest doing something like using CIELAB which W3 shows as the underlying color representation and convert to sRGB, P3, et.al. when needed. Alternatively LCH is another reasonable default.

Because LCH is both perceptually uniform and chroma-preserving, and because the axes correspond to easily understood attributes of a color, LCH is a good choice for color manipulation.

This would likely be a very breaking change, but I think is 100% necessary as it frees the library from color spaces. As it is, this is not a general-purpose library if colors are limited to sRGB.

If I'm missing something, please inform me.

sharkdp commented

-- | - Colors outside the sRGB gamut which cannot be displayed on a typical
-- | computer screen can not be represented by Color.

This ain't true anymore. DCI-P3 is quite common on phones and increasingly in monitors and laptops (such as my own). CSS4 opened up to color gamuts beyond sRGB https://www.w3.org/TR/css-color-4/#icc-colors. By choosing a device-independent color representation without gamma correction or color space clipping, device-dependent colors could be derived.

I would then suggest doing something like using CIELAB which W3 shows as the underlying color representation and convert to sRGB, P3, et.al. when needed. Alternatively LCH is another reasonable default.

Fully agreed. This library already supports CIELAB and LCh... but it's unnecessarily limited to the sRGB gamut.

This would likely be a very breaking change,

Right. Unfortunately, the Color datatype publicly exposes the default representation. I could also imagine that we would run into a few floating point inaccuracy problems when switching to another default representation.

Note1: I'm not actively using this library anymore so I'm almost certainly not going to work on this myself.
Note2: Since writing this library, I have started another project (in Rust) that 'suffers' from a similar problem (see e.g. sharkdp/pastel#108)

toastal commented

Gotcha. Perhaps if I have some cycles, I'll come back and look at this. I only understand this at a higher level (photography), but not the math behind it (though it'd be good to learn).

I'm currently looking library for a task (related to the PR) -- and luckily the task will 100% be within sRGB.

  • 👍1