search

drwpow / better-color-tools

Better color tools for JS, TS, and Sass. Supports Oklab and CSS Color Module 4.
https://better-color-tools.pages.dev/
MIT License
78 stars 7 forks source link

Switch to internal value type with P3 support? #39

Open swernerx opened 1 year ago

swernerx commented 1 year ago

Thanks for the awesome library. Having a very pragmatic approach combined with a nice to use API: congrats!

Unfortunately there is one issue I experienced when working with "deeper" colors e.g.

oklch(76.28% 0.18 82.0399)

This is outside of the sRGB spectrum. The library seems fine for a starting point for doing calculations on sRGB values but I wish there would be an option to keep an extended color format internally and only fallback to sRGB if required e.g. by calling the methods on the from return object.

This is a nice color picker showing how it might be done better: https://oklch.com/#76.28,0.18,82.0399,100 - doing all processing on the extended color space and showing a fallback value where needed.

drwpow commented 1 year ago

This is a great suggestion, and something I’ve been thinking about doing. This library was written before OKLAB/OKLCH were even added to the CSS Color Module 4 spec, and before browsers had experimental support for expanded color spaces (other than Safari’s P3 support). So sRGB was fine at the time, but it’s exciting to see the rapid change in web support for expanded color gamuts (which Evil Martians, creators of oklch.com, have had a huge part in advocating for).

This library keeps track of colors as sRGB currently, so swapping to another colorspace (e.g. XYZ) would require a rewrite. But it wouldn’t be a substantial change as it would basically just mean delaying calculations until sRGB is specifically requested as you suggested. And because the web is rapidly moving past the sRGB gamut, this change makes sense long-term. I think I originally didn’t start that way because a) sRGB was sufficient a couple years ago, and b) I wanted to keep this footprint tiny / I didn’t want this to balloon into a “do-everything” color library of which there are several good ones already.

So all that said, maybe this could pave the way to a 1.0 release, which may include a few other breaking changes, but for the better. And the API would stay minimal and easy-to-use.

swernerx commented 1 year ago

The question than is also what the best internal value type would be... e.g. what type supports all human-noticable accents to allow dealing with P3, Rec2020 and others in the future.

drwpow commented 1 year ago

The question than is also what the best internal value type would be... e.g. what type supports all human-noticable accents to allow dealing with P3, Rec2020 and others in the future.

XYZ is the defacto “universal” colorspace because it was created to encompass all human-perceivable color, beyond what any RGB monitor can reproduce. So that’s probably the answer. Most color science libraries use XYZ space under-the-hood. And there’s a transform to/from XYZ to everything out there because it’s a standard.

Again, maybe a mistake on my part not doing that in the beginning; it just seemed like overkill. But now, it feels like the right move.