Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: I Made JavaScript Color Conversion Library for LCH/Lab/XYZ/RGB/Hex/HSL (github.com)
55 points by semantictags 12 days ago | hide | past | web | favorite | 19 comments





This is actually pretty interesting to me, as I maintain a popular JS library [1] that depends on Chroma.js (similar lib to yours), and that dependency outweighs my first party code more than 3:1.

Do you have any plans to add interpolation functionality to ac-colors?

[1] https://github.com/qrohlf/trianglify


Yeah, I was looking at chroma.js a day or two back and thinking “you call it ‘t̶i̶n̶y̶ small-ish’ [0]!? This thing is 40KB, 14KB gzipped [1], that’s by no means small!”

I’d expect such a library to be way smaller (I dunno, but less than 10KB/4KB), and preferably support tree-shaking so that I can just pick out the hcl() function, for example, if that’s all I want.

[0]: https://github.com/gka/chroma.js

[1]: https://bundlephobia.com/result?p=chroma-js


I don't know why it should be tiny, given what it's trying to do. Multiple kilobytes are dedicated to CSS color names and ColorBrewer scales, which don't compress well.

At the end of the source there's a section where you can comment out lines which should remove sections of the code when compressing it.


I do now :)

Maybe I'm blind, but I don't see any handling of out-of-gamut colors? At the very minimum I'd expect some naive min/max clipping to avoid negative RGB components.

Also no mention of what kind of RGB it is. From the xyzToRgb function it seems to be[1] sRGB but that should be mentioned, and also consistent throughout the library (in case it isn't).

[1]: http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix....


Negative numbers are not really an issue, quite the opposite because they are necessary for invertibility of most of the computations. We almost never ever clip values in Colour (https://github.com/colour-science/colour) and leave that responsibility to the user. One exception is conversion to Hexadecimal where if you don't do ensure the values are in the range [0, 1], you will induce the user in error: https://github.com/colour-science/colour/issues/584#issuecom...

> leave that responsibility to the user

I think it would be better to have a function in the library that does this. Then it can be extended to allow for more clever things than a simple min/max clamp.


Gamut mapping is not an easy thing though!

That is true :)

Color is a great example of how "low-order" approximations are very useful, and how quickly it can get very hard once you want to go a bit beyond that.


Has anyone here used the Python "Colour" library?

They've got pretty extensive and awesome documentation. I discovered it a couple of months ago.

https://github.com/colour-science/colour


Thanks for mentioning Colour! We are still on very long alpha since over half a decade but we are getting there. We have 3 students helping us for GSoC this year!

https://twitter.com/colour_science/status/125826870601631744...


Hi. I'm the maintainer of https://npmjs.org/package/color and https://npmjs.org/package/color-convert.

Curious what your library does differently aside from API design. `color-convert` has been around for years and has supported all of these algorithms plus more - and it does a BFS search to convert between models that do not have an explicitly written conversion algorithm.

I'm not one to say "don't do this", but I'm generally pretty against re-inventing the wheel if there's something to be improved upon.


Nice! Constructive feedback:

Comments!

My advice would be to add comments to the code. Comments shouldn't repeat the code, but e.g. describe what it's doing, or provide links to where the formulas come from and what they mean. It's also helpful to document overall code structure (where do I go to find something?).

Formatting!

And to run it through code quality tools. A lot of minor styling issues. It could use more new lines (esp. between functions).

These sorts of things might seem minor, but they matter if you're applying for a job. A lot of people will give a cursory glance at your code repos to see if everything looks reasonable or if there's anything insane. These sorts of surface features make a disproportionate difference.

Plus, they really do help. A lot of your users might not know what LAB colors are, or how exactly HSV is computed.


Thanks for the feedback! Improving the documentation is definitely one of my priorities, but I hadn't thought of documenting the overall structure. Do you have any suggestions for how best to do that?

Usually, in the README, I describe what the major files are. For something this simple, it's usually just one paragraph.

"The source code is in `index.js`. In order to build the minified version, run `[command]`. [description of what `index.js.min` is, and how it compares to `dist/ac-colors-min.js`] [Maybe short description of other travis commands used during development]"

Basically, imagine you're running into this repo having never looked at it before. What do you want to know?

From there, you can go one level deeper, and document `index.js`. It's not rocket science, but it is helpful. For example, I have no idea what `256colors.js` is, or how it's used for testing. That should be either a comment at the top of the file, or in the README (depending on how important the file is).

When you go into `index.js`, it's nice to have an overview of what's what in the file, and how it's structured. I like when docs are build from files, actually (so instead of all of this in `README.md`, you have that in comments in code, and build to something like `README.md`). I also like having clearly documented inputs and outputs.

I also really recommend blank lines between functions. This is especially true if you have blank lines within functions. lchabString, lchab, and the first part of rgbtoHsl fuse into one big code paragraph right now.

I wouldn't necessarily take what I say as how you ought to do it -- that's a question of style, and how I solve these problems. Take it more as a problem statement and example solution.


Is there any way to do ICC profile transformations in js?

Is the RGB sRGB with all the EOTS stuff built-in?

That stuff is tricky.


I think you mean EOTF (electro-optical transfer function)? Or am I just unfamiliar with EOTS?

yeah, eotf. my bad.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: