Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
RGB, HSV, and HSL color conversion algorithms in JavaScript
/**
* Converts an RGB color value to HSL. Conversion formula
* adapted from http://en.wikipedia.org/wiki/HSL_color_space.
* Assumes r, g, and b are contained in the set [0, 255] and
* returns h, s, and l in the set [0, 1].
*
* @param Number r The red color value
* @param Number g The green color value
* @param Number b The blue color value
* @return Array The HSL representation
*/
function rgbToHsl(r, g, b) {
r /= 255, g /= 255, b /= 255;
var max = Math.max(r, g, b), min = Math.min(r, g, b);
var h, s, l = (max + min) / 2;
if (max == min) {
h = s = 0; // achromatic
} else {
var d = max - min;
s = l > 0.5 ? d / (2 - max - min) : d / (max + min);
switch (max) {
case r: h = (g - b) / d + (g < b ? 6 : 0); break;
case g: h = (b - r) / d + 2; break;
case b: h = (r - g) / d + 4; break;
}
h /= 6;
}
return [ h, s, l ];
}
/**
* Converts an HSL color value to RGB. Conversion formula
* adapted from http://en.wikipedia.org/wiki/HSL_color_space.
* Assumes h, s, and l are contained in the set [0, 1] and
* returns r, g, and b in the set [0, 255].
*
* @param Number h The hue
* @param Number s The saturation
* @param Number l The lightness
* @return Array The RGB representation
*/
function hslToRgb(h, s, l) {
var r, g, b;
if (s == 0) {
r = g = b = l; // achromatic
} else {
function hue2rgb(p, q, t) {
if (t < 0) t += 1;
if (t > 1) t -= 1;
if (t < 1/6) return p + (q - p) * 6 * t;
if (t < 1/2) return q;
if (t < 2/3) return p + (q - p) * (2/3 - t) * 6;
return p;
}
var q = l < 0.5 ? l * (1 + s) : l + s - l * s;
var p = 2 * l - q;
r = hue2rgb(p, q, h + 1/3);
g = hue2rgb(p, q, h);
b = hue2rgb(p, q, h - 1/3);
}
return [ r * 255, g * 255, b * 255 ];
}
/**
* Converts an RGB color value to HSV. Conversion formula
* adapted from http://en.wikipedia.org/wiki/HSV_color_space.
* Assumes r, g, and b are contained in the set [0, 255] and
* returns h, s, and v in the set [0, 1].
*
* @param Number r The red color value
* @param Number g The green color value
* @param Number b The blue color value
* @return Array The HSV representation
*/
function rgbToHsv(r, g, b) {
r /= 255, g /= 255, b /= 255;
var max = Math.max(r, g, b), min = Math.min(r, g, b);
var h, s, v = max;
var d = max - min;
s = max == 0 ? 0 : d / max;
if (max == min) {
h = 0; // achromatic
} else {
switch (max) {
case r: h = (g - b) / d + (g < b ? 6 : 0); break;
case g: h = (b - r) / d + 2; break;
case b: h = (r - g) / d + 4; break;
}
h /= 6;
}
return [ h, s, v ];
}
/**
* Converts an HSV color value to RGB. Conversion formula
* adapted from http://en.wikipedia.org/wiki/HSV_color_space.
* Assumes h, s, and v are contained in the set [0, 1] and
* returns r, g, and b in the set [0, 255].
*
* @param Number h The hue
* @param Number s The saturation
* @param Number v The value
* @return Array The RGB representation
*/
function hsvToRgb(h, s, v) {
var r, g, b;
var i = Math.floor(h * 6);
var f = h * 6 - i;
var p = v * (1 - s);
var q = v * (1 - f * s);
var t = v * (1 - (1 - f) * s);
switch (i % 6) {
case 0: r = v, g = t, b = p; break;
case 1: r = q, g = v, b = p; break;
case 2: r = p, g = v, b = t; break;
case 3: r = p, g = q, b = v; break;
case 4: r = t, g = p, b = v; break;
case 5: r = v, g = p, b = q; break;
}
return [ r * 255, g * 255, b * 255 ];
}

@mjackson Would it be possible for you to attach a free software license to this or release it to the public domain? (short read: http://blog.codinghorror.com/pick-a-license-any-license/)

pygy commented Sep 9, 2015

Indeed it would be nice to see a license attached to these routines. Other folks have borrowed them without further toughts, but I'd rather have an official permission to do so.

+1

m314 commented Oct 17, 2016

ststeiger commented May 30, 2017

+1
but hslToRgb(h, s, l)==> return [Math.round(r * 255), Math.round(g * 255), Math.round(b * 255)];
RGB uses integers.
Or perhaps more correctly

MAX
(
      MIN
      (
             255
           , Round(r*255)
      )
      ,0
)

etc.

so

function hslToRgb(h, s, l)
{
    var r, g, b;

    if (s == 0)
    {
        r = g = b = l; // achromatic
    }
    else
    {
        function hue2rgb(p, q, t)
        {
            if (t < 0) t += 1;
            if (t > 1) t -= 1;
            if (t < 1 / 6) return p + (q - p) * 6 * t;
            if (t < 1 / 2) return q;
            if (t < 2 / 3) return p + (q - p) * (2 / 3 - t) * 6;
            return p;
        }

        var q = l < 0.5 ? l * (1 + s) : l + s - l * s;
        var p = 2 * l - q;

        r = hue2rgb(p, q, h + 1 / 3);
        g = hue2rgb(p, q, h);
        b = hue2rgb(p, q, h - 1 / 3);
    }

    return [
         Math.max(0, Math.min(Math.round(r * 255), 255)) 
        ,Math.max(0, Math.min(Math.round(g * 255), 255)) 
        ,Math.max(0, Math.min(Math.round(b * 255), 255)) 
    ];
}

pathurs commented Aug 3, 2017

@ststeiger

To be most accurate, you would times by 256, not 255, then Math.floor.

the set of 0-255 is actually out of 256. If you times by 255, then you will not be as accurate as possible. the same way you could get a percentage by using 99 instead of 100, it's very close, but not correct.

Math.round means that only < 0.5 and >= 254.5 would become the minimum and maximum.
This would mean that, if the numbers were randomized, there's half the chance of getting 0 or 255, than there is to getting any other number.

Therefore:

Math.max(Math.min(red * 256, 255), 0)

sparr commented Oct 8, 2017

Also seeking licensing for this code.

+1 seeking license

Hello,

I tried hslToRgb() but it didn't work correctly.
this.hslToRgb(200,1,0.7)
Result:
(3) [102, 102, 102]

The correct result should be: rgb(102, 204, 255)
Do you have any idea why?

I'm running on Chrome 62.

Thanks.

agriffis commented Nov 8, 2017

@strawherotk The input parameters to hslToRgb should be in the range [0, 1]

+1 seeking license

+1 license plz

Why you are using range [0, 1] for hue? More usable is [0, 359]

verdy-p commented Jan 30, 2018

I do agree that Hur is usually given in degrees (including in CSS/SVG with the "hsl()" or "hsla()" color specifier) in range [0,360), in fact modulo 360 so that 360 is equivalent to 0 on the color circle, rather than as a fraction of the unity segment [0,1), in fact modulo 1 so that 1 is equivalent to 0 on the color circle.

Saturation and lightness may be given as a fraction of unity but is usuall in percents (so multiplied by 100) in range [0,100]

Rounding HSL values to integers should also NOT be done (you should keep at least one decimal to preserve the precision of RGB values, or you can increase the value ranges by rounding Hue in range [0, 3600) modulo 3600, and rounding saturation and lightness in range [0,1000]

Note that for the inverse conversion from HL to RGB, multiplying by 256 with floor() is correct, but you still need to "clamp" the result to [0,255] because you may eventually get tiny negative fraction values floored to -1, and values equal to or higher than 256 (with a tiny positive fraction difference) floored to 256 for an initial lightness=100% (this does not occur when converting white, or plain red, or plain green or plain blue, i.e. with saturation=0, but occurs for some HSL color input saturated at 100% when the input hue is not an exact multiple of 120 degrees). If you don't clamp the RGB value results, you may find some components floored to -1 or to 256 (this depends on the precision of the input HSL and how it was initially rounded to units of degrees and percents, or units of decidegrees and perthousands).

Also don't use HSL "normalized" to [0,255], it has not enough precision. The minimum needed precision of HSL to keep the precision of RGB components in [0,255] is with:

  • hue normalized to the integer range [0,384] (where 384 means the same as 0),
  • saturation normalized to [0,511] and lightness only can be normalized to [0,255] and only of HSL is rounded (not floored). This means that HSL values will require 3 more bits (27 bits in total) to represent the same space as 24-bit RGB.

Finally note that RGB is not necessarily an integer, it is just a convention used on displays, but 3D renderers represent sRGB colors with at least 32 bits, i.e. 11 bits for green, 10 bits for blue and 1 spare bit (possibly used for a 1-bit transparency channel), or using 32 bit floats per component, to avoid loss of precision to compute intermediate shaders (most shaders prefer working in another colorspace than sRGB, notably YUV and RSV, similar to HSL, or NTSC,, or CIE*Lab because shades and cloud effects are more accurate). There are even now video modes and hardware HDMI interfaces whose native back buffer is 48 bit, not using sRGB as its base colorspace (this also works better to improve the complex color rendering of many LCD and TFT panels, which use technics light dynamic contrast, and tuning gamma curve, L-to-D and D-to-L response time, motion compensation, white temperature, and offseting the black level to adapt to input cable or to lifecycles of the backlighting and remanence of liquid crystals by varying the frequency of inversion for the polarisation of the LCD layer; displays use now complex conversion algorithms and a basic 24 bit sRGB input has not enough precision to do that, so such digital input is immediately converted to a native 48 bit input with the sRGB "linear" gamma curve inverted to reflect the real gamma intended, and then it this space is immediately "rotated" by a matrix to match the actual pigments used in filters of subpixels; this transform is done internally by a programmed chip within the display which can take many other inputs to tune it, including user preferences on the display itself, or info about the original colorspace of a video via a protocol on the HDMI or DVI interface itself; there are so many parameters now that all this cannot be safely computed in 24-bit only without severe degradation and very undesirable effects, like moiré, flickering, or color fringes along contrasted borders)

The 32-bit sRGB photographic and video encoding is now the interchange norm of the industry, but more often now it becomes 48-bit sRGB to support 32-bit YUV input with high fidelity and the professional DCAMs use at least 48-bit encoding internally for all its processing, with 16 bit per color subpixel to compensate all possible tunings and effects: with 48 bit you can do lot of transforms with fast rounding, where the generated moiré, flickering or color fringes will still be completely invisible to all human eyes; the 48 bit working space also will keep a working margin near 0 and 100% lightness so that costly clamping can be avoided in all intermediate computations; the TV and DVD standards reserved the values 0-15 and 240-255 in sRGB for this purpose and also for composite analog TV signals, but this is now becoming obsolete as it reduced the usable color gamut and even MPEG4 and HDMI no longer need this compression of the color space and even the sRGB transform does not respect the correct gamma at low values, producing false colors, flickering, banding and moiré within dark areas or shadows of images, or everywhere in thin regular textures like tissues, or along oblique lines on sportive pitches like tennis, or artificial "plaques" on the skin of people faces: some display will attempt to correct these defects from known video sources, but this works better if the photo or video sources comes with the specification of its initial colorspace and colorspace transforms and compression already applied: this info requires more precision than just the 24-bit sRGB input to correct these defects).

verdy-p commented Jan 30, 2018

Finally note that the first algorithm is perfectly correct : it is written in Javascript using the "number" type for each component whose precision is a 64-bit IEEE double-precision floatting point: this keeps all the precision needed (its 56-bit mantissa is 7 times the precision of the 8-bit input), so it does not need ANY use of Math.round() or Math.floor(). It is made externally when needed, so it does not have to "denormalize" the output to another limited range than [0, 1].

The comment saying "to be more accurate, multiply by 256 then floor" is then completely false: it would actually make the accuracy WORSE than what it gives now (dropping 48 bits of precision in each component to keep only 8 with some arbitrary rounding limit asssuming a symetric use of all integer values oin 0-255, while in fact msot videos and photo use "rounding", not flooring, to range 16-240, where clamping is not even necessary to suppress the values 1-15 and 241-254, and where 0 and 255 values are also NOT used in 24-bit sRGB input).

Would you guys consider HSL or HSV better for conversion to humanly sensible text via conditions (a la pale dark blue etc) rather than choosing specific color names via proximity comparisons? I currently do both, but most exact color names are incomprehensible to the intended audience, so I need something simpler ("what the heck is mauve?" etc). In the first case currently via HSL, with ranges for each attribute + some special conditions for black, white, gray etc, currently lacking distinction of brown, pink etc common color names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment