HCT ( from Google Material 3)

[qinyiyao]

https://material.io/blog/science-of-color-design
https://github.com/material-foundation/material-color-utilities

[NateBaldwinDesign]

HCT is just CAM16 with lightness from LAB (which should already be very comparable). I would almost rather see CAM16 implemented over HCT as it is not clearly explained the benefits or purpose of its creation over the existing scientific color appearance model.

[Artoria2e5]

See also material-foundation/material-color-utilities#112 -- my question-issue about why they decided to use the Lab lightness instead of what CAM16 already has. In any case, you can't do HCT without CAM16.

[danburzo]

I think a bit of the rationale is described here: WCAG defines the contrast ratio based on the Y in XYZ, and L* is a perceptually linear mapping of Y that has the interesting property that a constant ΔL* produces a relatively constant contrast ratio between the colors, regardless of L*. So it does indeed look like ΔL* = 50 reliably produces a contrast ratio greater than 4.5 to 1:

(For brevity, I’ve omitted the linear part of CIELAB transfer function and used x => x ** 3)

I’m curious, however, whether the J in CAM16-UCS has similar properties. If it doesn’t, that would explain their choice.

[danburzo]

Thanks for submitting the idea, @qinyiyao. I've kept some bookmarks for HCT but didn't have the chance to catch up with them. I agree with @NateBaldwinDesign — if anything, if CAM16 is implemented, support for HCT is a couple of functions away.

I haven't done a close reading on CAM16 and its uniform color space (CAM16-UCS), but skimming the paper I was reluctant about tackling it, since culori's API doesn't really have a concept of color space parameters — CIELAB under the D50 illuminant (lab) is implemented separately from CIELAB under the D65 illuminant (lab65), etc. So probably CAM16-UCS would similarly need to be pinned down to certain viewing conditions if it were to to be used in all the ways the color spaces are used throughout the API.

[Artoria2e5]

I think the UCS already pins down viewing conditions. https://github.com/colour-science/colour/blob/develop/colour/models/cam16_ucs.py, function XYZ_to_CAM16UCS takes nothing but XYZ.

[danburzo]

The XYZ_to_CAM16UCS function is a partial application of XYZ_to_UCS_Li2017 that fixes the coefficients for deriving the various related color spaces — UCS (uniform color space) vs. SCD (small color differences) vs. LCD (large color differences). The viewing conditions can be configured when invoking the function or left to their defaults:

https://github.com/colour-science/colour/blob/8c090f93384b4a397f96aa47df1db5dca1a3e99d/colour/appearance/ciecam02.py#L163C1-L171C2

[Artoria2e5]

The picture seems very suspect. It's almost like HCT was interpolated in a hue-curve-following fashion, while the Oklab and CAM16 are interpolated in Euclidean space, ignoring the cylindrical transforms everyone knows about. That's apples to oranges, blatant cheating.

// The pic does this
interpolate(['blue', 'red'], 'hct')  // not implemented, this feature request
interpolate(['blue', 'red'], 'oklab')
interpolate(['blue', 'red'], 'cam16-ucs-jab')  // not implemented
// instead of this
interpolate(['blue', 'red'], 'oklch')
interpolate(['blue', 'red'], 'cam16-ucs-jch')  // not implemented

Oh no, it comes straight from the original blog post! https://material.io/blog/science-of-color-design

[danburzo]

Yes, I think a really good question to answer is whether HCT performs significantly better than Oklch.

[qinyiyao]

Very sus indeed. I just found this additional comparison image: https://krita-artists.org/t/a-new-color-space/40242/4

Lossy compression aside, it doesn't look that much different.

[danburzo]

Link to the related CAM16 discussion, which is a prerequisite for HCT support.

• CAM16 / CAT16 / CAM16-UCS #133

It remains to be seen if explicit HCT support belongs to the library or is better suited as a (small) userland module.