17 comments

[ 0.23 ms ] story [ 54.8 ms ] thread
This is mostly a port of the code on https://www.easyrgb.com/en/math.php but I have added a few extras.

What I use it for is:

* RGB - easy to guess what values to use to make a color

* HSL - easy to change the hue of a color

* Lab - lets you compare colors

* Named color - lets you know the name of a color

Nope: it's LAB that lets you change the color, without affecting luminance. HSL makes it easy to change a meaningless parameter that is called "hue". Changes in H that keep SL constant affect the perceived lightness of the color.
Thanks for clarifying that. Much respect to anyone that understands this stuff.
For more advanced needs there is Colourful .NET [1].

[1] https://github.com/tompazourek/Colourful

Oh dang, I wish I had seen that, lol. It doesn't look like theirs does named colors though *clings to relevance. Thanks for posting that.
It also misses HSV and HSL. And a ton of other things if you aim for completeness. Not long ago I was tempted to write my own library but stepped away from it after a few days of research into colorimetry and realizing how deep that rabbit hole is.
The focus here seems to be on perceptually relevant representations, plus RGB (hardware-relevant).

HSV is just a rearrangement of RGB for improved color picking dialog boxes, not for any serious computation with color.

I just mentioned them because they are in the ops library but not Colourful .NET, not because they are especially important. In the end all color spaces and color representations are just means to represent electromagnetic spectra, most of the time only a subset and most of the time lumping together different spectra into equivalence classes. And they all have their uses, they all make certain things easy and other things hard.
It's funny how you learn about colors in Kindergarten and think you pretty much go it. Then you go to program with them and instantly get hit with intense math.
(comment deleted)
The builtin System.Drawing.Color namespace already contains much of what you have in regards to colors to and from names.

There are a lot of helpful methods available.

Color foo = Color.FromArgb(int); int foo = Color.ToArgb(); Color foo = Color.FromName("CornflowerBlue");

Color itself also exposes .IsKnownColor and .IsNamedColor

That only works if it's the exact color. If you're one bit off it won't know.
In the past I used to build this stuff in silicon .... just a quick note it's quite common in the real world to get incoming values that are out of gamut (the results of compressing and decompressing data for example) - you need to pin your final values to 0-255 in the cases where they are < 0 or > 255 otherwise they tend to wrap, you also need to carry that extra bit of precision through your math (not such an issue with FP) to make sure you can detect this
It's doable without extra precision. SSE2 have some instructions operating on saturated integers, i.e. numbers stick to min/max instead of wrapping.
internally the hardware that's doing this for you has to carry that extra precision (in a carry bit usually) in order to do this - it may not be architecturally visible but it has to be there
> it has to be there

No it doesn't. For example, for single bit of precision, saturated addition is bitwise or, saturated subtraction is bitwise andnot. Obviously, the electronic doing these bitwise operations do not use any extra bits. Similarly, for higher count of bits, the electronic doing the math may or may not have that extra precision.

Lab has the cool effect that you can smoothly change the luminance of a particular color in steps (usually scale is 0-100), where each step has an equal perception of change to the user.

Very useful when making gradients.

I used this for my MSc thesis project :)