Hello, i really love this concept but i fail to find any sass implementation or working alternative. Have you any clue for how to make this work in plain css via sass? Thanx.

To reproduce:

curl -s https://registry.npmjs.org/hsluv/-/hsluv-0.1.0.tgz | tar tvz
-rwxr-xr-x 1000/1000       462 1970-01-01 01:00 package/package.json
-rwxr-xr-x 1000/1000      2110 1970-01-01 01:00 package/README.md
-rw-r--r-- 1000/1000      9421 1970-01-01 01:00 package/hsluv.js
-rwxr-xr-x 1000/1000      1185 1970-01-01 01:00 package/hsluv.d.ts

Please publish a tarball containing files with a valid date.

For Mac users unfamiliar with Nix, our build system is unapproachable due to #61. We must make it possible for such a user to configure an HSLuv build quickly.

Ideas:

• See if we can use a workaround from https://github.com/NixOS/nix/issues/2925
• Wrap the build in a Dockerfile (bonus - Windows support)
• Vagrant? Something else?

Whatever the solution, it needs to be clearly explained in the README.

I'm attempting to port to typescript.

In running your tests, I am seeing extremely small numeric drift (usually on the order of 10^-15 or smaller.)

I haven't really dug around, but I suspect that Typescript is juggling the math in a way that screws with IEEE numeric precision's edges.

Are deviations that small considered acceptable?

Honestly, I'm more suggesting this because I want to play around with it than because I actually want to use it for a real project. It might be handy in cases where you want to experiment with different hues of not-very-saturated colors.

It'd be neat to have a version of HSL with no chroma distortion at all. I.e., one that only includes a much smaller range of chroma, such that you can't actually access a color with a chroma unattainable with another hue for the same lightness value. It would require limiting the output to a very desaturated range of the visible color spectrum, but it'd be kind of neat to play with, I think.

Actually, now that I think of it, I guess you can attain pretty much the same effect by hovering around CIELCHuv(x,25~60,z).

I wanted to update an older library of mine, husl-harmony, to the newer math, and newer tooling.

I went to look at your implementations list because the Haxe approach isn't convenient under Typescript, to see if there was a native typescript one.

There wasn't, so I wrote one, under the community standard -ts name.

In trying to publish the completed product, I learned that @gfmio already did, and already published under the standard name, but did not get it added to your site.

His and my implementation aren't actually the same, and both have advantages and disadvantages.

As a result I published mine as @stonecypher/hsluv.ts instead of hsluv-ts.

Please consider adding both the hsluv-ts and @stonecypher/hsluv.ts implementations to your list. Thank you.

Here's what it looks like for the color #ff0000, which has an L* value of 53.2371155954294 (you don't have to type a precise L* value to get the visual bug, but I did here to demonstrate a variation of the bug next):

It looks slightly worse if I make it just a bit more precise, with an L* of 53.23711559542936:

And it looks abysmal if I plug in the color #0000ff, which has an L* of 32.3008729039802 (I couldn't find any variations like the 'red squares' found by more precise versions of #ff0000's L* value; all values from 32.3...8017 through 32.3...8033 are identical):

It's possible it breaks for L* values other than 53.2371155954294 and 32.3008729039802 as well, but I can't find any.

I don't know when this started happening, but when I used the site like a year or two ago it didn't happen. I've tested on the Linux version of Firefox, as well as the Linux version of Chrome, and get the same results on both.

In the color picker at http://www.boronine.com/husl/, it would be nice if we could directly edit the numbers next to the “H”, “S”, and “L” labels, in addition to editing them by dragging the circle on the hue-saturation map and by dragging the lightness slider.

The numbers should also be styled like a text box, similar to the current hex code text box

, so that the user knows that they are editable.

Changing the numbers in the HSL text boxes would also change the position of the controls, just like HSL Color Picker does it.

Ideally, you would be able to edit any text box representing the color, including the hex code and the RGB values. For example, if the output hex code is edited to another valid hex code, the color should be updated, and its HUSL HSL values should be displayed in their text boxes, and the controls updated. HSL Color Picker supports this too.

The advantage of allowing direct editing is that it’s easier to type a number that you know you want than to carefully drag the mouse to the correct horizontal or vertical position. I once used the website color picker to generate some colors for a game. I was trying to generate different-hued families of colors with different saturations. When I had written the hex codes for all the light colors, it was a little difficult to move the map circle to the exact same horizontal position to get darker versions of the same hues. If I could have typed “225” into the hue text box, that would have been easier.

It's my understanding that for the standard implementation, HSLuv ranges from [0, 0, 0] to [360, 100, 100]. I thought HPLuv would have the same range, but looking at snapshot-rev4.json I've seen the S value go over 490. The H and L values appear to have the same range as HSLuv.

Why is the HPLuv S value range so large? And what is the max value? I ask this so that I can scale to [0..1] for usage in a library.

complete with tests.

https://github.com/lahwran/pin/commit/9f18fadf62144dc30acf38842a5356a440923e46 (impl), and https://github.com/lahwran/pin/commit/db89dfa431464a97df7074f32745b3af397c050c (which has a bunch of other stuff too, but also tests.)

I did this because it said the java port was unfinished. Also because it was fun.

The standard D65 XYZ values are (0.95047, 1.00000, 1.08883). This is written in Wikipedia and by Bruce Lindbloom (see here and search for D65).

But HSLuv defines them like so:

https://github.com/hsluv/hsluv/blob/005e50b7cf79eff8c62ccfc09a5707692451758e/math/cie.mac#L40

If I remove the rat and run that calculation, the output XYZ values are (0.95045592705167, 1, 1.089057750759878). This is quite a bit off from what I believe are the correct values, and it is throwing off my calculations that use the standard D65 as I defined at the beginning. Here's an example of the difference between what using the standard D65 will output, versus the HSLuv D65:

    hsluv_test.go:98: Testing public methods for test case #ffff00
    hsluv_test.go:67: result: [1.000054 *, 0.999991 *, -0.002083 *] expected: [1 1 0], testing HsluvToRGB with test case #ffff00
    hsluv_test.go:67: result: [85.880145 *, 1.000332 *, 0.971386] expected: [85.87432021817473 1.0000000000007272 0.9713855934179674], testing HsluvFromHex with test case #ffff00
    hsluv_test.go:67: result: [85.880145 *, 1.000332 *, 0.971386] expected: [85.87432021817473 1.0000000000007272 0.9713855934179674], testing HsluvFromRGB with test case #ffff00
    hsluv_test.go:117: Testing internal methods for test case #ffff00
    hsluv_test.go:67: result: [1.000054 *, 0.999991 *, -0.002083 *] expected: [1 1 0], testing convLchRgb with test case #ffff00
    hsluv_test.go:67: result: [0.971386, 1.070642 *, 85.880145 *] expected: [0.9713855934179674 1.0708560884692067 85.87432021817473], testing convRgbLch with test case #ffff00
    hsluv_test.go:67: result: [0.971386, 0.076918 *, 1.067875 *] expected: [0.9713855934179674 0.07704219177275 1.06808111250898], testing convXyzLuv with test case #ffff00
    hsluv_test.go:67: result: [0.769989 *, 0.927808, 0.138372 *] expected: [0.76997513864982 0.92780768463926 0.13852559851021098], testing convLuvXyz with test case #ffff00

The D65 values affect these variables:

https://github.com/hsluv/hsluv/blob/005e50b7cf79eff8c62ccfc09a5707692451758e/math/cie.mac#L48-L49

Which goes on to affect everything else.

I believe this could all be fixed by manually setting the [ref_X, ref_Y, ref_Z] variables to (0.95047, 1.00000, 1.08883). I know that I am quite inexperienced with color theory though, and so I'd appreciate learning if I'm wrong here.

For now I will specify a custom white reference for HSLuv calculations only.

It would be really nice if, while updating the color code text box in the bottom left, the value also got copied to the clipboard. Since very few paint applications provide an hsluv color picker I end up using the website a lot just for color picking.

But the workflow is a bit tedious: pick color on the website, click on the textbox, select all the text, copy, go back to my painting app, click on whatever color input I have, select all text, paste.

Having the website copy the colors to the clipboard automatically would make things a bit less cumbersome.

If the automatic behavior is undesired, then perhaps there could be a checkbox for enabling or disabling the behaviour.

How do I find the most similar color to a certain color in a set of colors? Is euclidean distance a decent way to do this? e.g. sqrt((ΔH)**2+(ΔS)**2+(ΔL)**2)

If not, would euclidean distance be decent when looking for the closest color within a certain Hue? e.g. sqrt((ΔS)**2+(ΔL)**2)

New screens support colour spaces wider than sRGB.

E.g. CSS will be supporting multiple such colour spaces: https://www.w3.org/TR/css-color-4/#icc-colors

Strictly speaking, HSLuv is limited to sRGB because its constants are plugged into its equations: https://github.com/hsluv/hsluv/blob/master/math/cie.mac#L10

Of course, for most practical purposes one can simply take the RGB output of HSLuv and plug it into a wide-gamut RGB colour space.

Maybe this is really all we need. In which case we should document that on the website and/or README.

Maybe we want more "proper" wide gamut support. This would be quite an undertaking that I would personally not attempt right now, but I will keep this issue open for discussion.

The author of the project is an expert programmer but a color science dilettante. If you have ever read a color science book from cover to cover, you are qualified to rewrite all website to make sure terminology is correct.

The website also links to an old blog post of mine: https://www.boronine.com/2012/03/26/Color-Spaces-for-Human-Beings/

It would be valuable to integrate the information contained in the blog post into https://www.hsluv.org somehow.

This has been reported here: https://github.com/hsluv/hsluv/issues/37

And more recently on Twitter.

I want to keep the demo as clean as possible. Perhaps we can add a checkbox like this:

[ ] pastel