search

boronine / colorspaces.js

A tiny jQuery and node.js library for manipulating colors. Also works as a stylus plugin.
MIT License
121 stars 8 forks source link

Negative value in hex #1

Closed aaronpeterson closed 12 years ago

aaronpeterson commented 12 years ago

Not sure if this is expected behavior but it doesn't occur with the previous version of colorspaces I was using. If anyone has a sec, the example is here which links from the master branch: http://jsfiddle.net/aaron/YZSZ7/

Awesome tool you've made here and been using it for months.

boronine commented 12 years ago

Hi Aaron, just confirmed what you reported. In earlier versions when converting to sRGB I would force the resulting R, G and B values into the 0..1 range. This is what the tool that I used for reference does.

This behavior is somewhat easier to work with but it is fundamentally wrong. CIELCH(50, 60, 100) simply does not exist in the sRGB color space, and if I wanted to find the closest color that does, there are better ways to do it than simply forcing blue to be 0.

Currently, colorspaces.js is supposed to throw an error when you attempt to do something like this.The negative hex value is a bug, I'll fix it within the next couple of days.

I'm glad you're finding my project useful!

aaronpeterson commented 12 years ago

Incredibly useful! I think what you're saying is that the impossible values would simply zero out? Still, visually it worked and was quite useful. The project I'm working on very much relies on extracting a hue (from rgb) and deriving varying lightness and saturation. What seems to make CIELCH useful in this sense is that the adjustments to lightness and saturation are consistent regardless of hue. I was thrilled to see you still working on the project last week when I was looking for an objective-c version...something I thought would be easy to find but is indeed not! I may try to (blindly) convert your js into a category for UIColor in objective-c/cocoa.

boronine commented 12 years ago

Hi Aaron, just pushed an update to get rid of validation, instead offering is_visible and is_displayable methods.

I think you have a little misunderstanding of the CIELCH color space. If you were to plot x as hue and y as chroma (with some fixed lightness), on a 360x100 rectangle you'll see that unlike HSL, CIELCH won't fill up the entire area. Instead, you'll see that certain hues have a lower maximum saturation than others. It seems intuitive to expect every hue to have a full range of saturation, but this intuition is based on our experience with HSL, which was basically designed to be geometrically simple (as opposed to perceptually uniform).

Picture a bright yellow. Now imagine that it's slowly turning darker and darker. Notice how it's becoming less and less saturated? This is because a dark saturated yellow does not exist for us humans, it is impossible. A dark saturated red? Sure. But not yellow. As it turns out, the way we see color is pretty complicated!

At some point I might add a function to return the range of saturation for a given lightness and hue, but meanwhile it is pretty hard to use my project for color generation.

EDIT: By the way, those colorful examples are gone from the documentation page for this very reason. Turns out that some of the colors I was getting did not actually exist and the only reason they showed up is because I forced RGB values into a 0..1 range. The stuff I wrote about above I realized pretty late into the project :)