RGB, HSV, and HSL color conversion algorithms in JavaScript

color-conversion-algorithms.js

/**
 * 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 ];
}

+1 seeking license

+1 license plz

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

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).

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.

Someone correct me if I'm wrong, but I believe hsvToRgb() is incorrect. Example:

hsvToRgb( .074, 1, 1 ) = r:255, g:113, b:0 when it should be r:195, g:255, b:0

About license, the docs tell that comes from an adaption of algorithms in Wikipedia. The texts under Wikipedia are covered by Creative Commons Attribution-ShareAlike 3.0 which give you the right to distribute adaptations only under the same license so this code must be under it too.

But, yes, better if the author adds it clearly.

This doesn't really work. I just implemented the wikipedia algorithm as is and it works:
https://gist.github.com/vahidk/05184faf3d92a0aa1b46aeaa93b07786

@isbyerley, came here to say the same thing. I think there's a mistake in the hsvToRgb. Here's my version:

function rgbFromHSV(h,s,v) {
  /**
   * I: An array of three elements hue (h) ∈ [0, 360], and saturation (s) and value (v) which are ∈ [0, 1]
   * O: An array of red (r), green (g), blue (b), all ∈ [0, 255]
   * Derived from https://en.wikipedia.org/wiki/HSL_and_HSV
   * This stackexchange was the clearest derivation I found to reimplement https://cs.stackexchange.com/questions/64549/convert-hsv-to-rgb-colors
   */

  hprime = h / 60;
  const c = v * s;
  const x = c * (1 - Math.abs(hprime % 2 - 1)); 
  const m = v - c;
  let r, g, b;
  if (!hprime) {r = 0; g = 0; b = 0; }
  if (hprime >= 0 && hprime < 1) { r = c; g = x; b = 0}
  if (hprime >= 1 && hprime < 2) { r = x; g = c; b = 0}
  if (hprime >= 2 && hprime < 3) { r = 0; g = c; b = x}
  if (hprime >= 3 && hprime < 4) { r = 0; g = x; b = c}
  if (hprime >= 4 && hprime < 5) { r = x; g = 0; b = c}
  if (hprime >= 5 && hprime < 6) { r = c; g = 0; b = x}
  
  r = Math.round( (r + m)* 255);
  g = Math.round( (g + m)* 255);
  b = Math.round( (b + m)* 255);

  return [r, g, b]
}

+1, used this for a coding bootcamp assignment, with attribution

This minified variation takes integer r,g,b values (0 to 255) and returns an object of integers (°,%,%) like {h:360, s:100, l:50} :

function rgbToHsl(a,r,e){a/=255,r/=255,e/=255;var t,h,n=Math.max(a,r,e),s=Math.min(a,r,e),c=(n+s)/2;if(n==s)t=h=0;else{var o=n-s;switch(h=.5<c?o/(2-n-s):o/(n+s),n){case a:t=(r-e)/o+(r<e?6:0);break;case r:t=(e-a)/o+2;break;case e:t=(a-r)/o+4}t/=6}return{h:Math.round(360*t),s:Math.round(100*h),l:Math.round(100*c)}}

If you have been looking for a variation that converts RGB to HSV with the hue ranging from 0 to 360 instead of 0 to 1, and the saturation and value ranging from 0 to 100, I have adapted this function, with this range re-mapping algorithm.

function mapMinMax(value,oldMin,oldMax,newMin, newMax) {
  return  (newMax-newMin)*(value-oldMin)/(oldMax-oldMin)+newMin;
}

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;
    }

    h = mapMinMax(h,0,1,0,360);
    return [h, s * 100, v * 100];
}

working with css string here did:

const _rgbToHsl = rgbStr => {
  const [r, g, b] = rgbStr.slice(4, -1).split(',').map(Number)
  const max = Math.max(r, g, b)
  const min = Math.min(r, g, b)
  const l = Math.floor((max + min) / ((0xff * 2) / 100))

  if (max === min) return [0, 0, l]
  const d = max - min
  const s = Math.floor((d / (l > 50 ? 0xff * 2 - max - min : max + min)) * 100)

  if (max === r) return [Math.floor(((g - b) / d + (g < b && 6)) * 60), s, l]
  return max === g
    ? [Math.floor(((b - r) / d + 2) * 60), s, l]
    : [Math.floor(((r - g) / d + 4) * 60), s, l]
}

It takes a css rgb string and returns parts in a css ready scale.

I got results similar to chrome conversion.

RGB, HSL, XYZ, LAB, LCH color conversion algorithms (ES6 Modules)
https://gist.github.com/avisek/eadfbe7a7a169b1001a2d3affc21052e

@isbyerley, came here to say the same thing. I think there's a mistake in the hsvToRgb. Here's my version:

function rgbFromHSV(h,s,v) {
  /**
   * I: An array of three elements hue (h) ∈ [0, 360], and saturation (s) and value (v) which are ∈ [0, 1]
   * O: An array of red (r), green (g), blue (b), all ∈ [0, 255]
   * Derived from https://en.wikipedia.org/wiki/HSL_and_HSV
   * This stackexchange was the clearest derivation I found to reimplement https://cs.stackexchange.com/questions/64549/convert-hsv-to-rgb-colors
   */

  hprime = h / 60;
  const c = v * s;
  const x = c * (1 - Math.abs(hprime % 2 - 1)); 
  const m = v - c;
  let r, g, b;
  if (!hprime) {r = 0; g = 0; b = 0; }
  if (hprime >= 0 && hprime < 1) { r = c; g = x; b = 0}
  if (hprime >= 1 && hprime < 2) { r = x; g = c; b = 0}
  if (hprime >= 2 && hprime < 3) { r = 0; g = c; b = x}
  if (hprime >= 3 && hprime < 4) { r = 0; g = x; b = c}
  if (hprime >= 4 && hprime < 5) { r = x; g = 0; b = c}
  if (hprime >= 5 && hprime < 6) { r = c; g = 0; b = x}
  
  r = Math.round( (r + m)* 255);
  g = Math.round( (g + m)* 255);
  b = Math.round( (b + m)* 255);

  return [r, g, b]
}

if h is equal to 360 this code shows NaN because you are not checking hprime for value 6 (360/60 = 6)
if (hprime >= 5 && hprime <= 6) { r = c; g = 0; b = x} "hprime <= 6" instead of "hprime < 6" fixes it

It does work, but it is not good to do the comparison of floating point Number values as you do in your switch. If it works in your case, this is only a potentially unreliable special case. You could figure out the three cases of your switch before your /= expressions. With minimal modifications of your code, it would look like

const rgbToHsl = (r, g, b, a) => {
        let [r, g, b, a] = rgba;
        let max = Math.max(r, g, b), min = Math.min(r, g, b);
        const componentCase = max == r ? 0 : (max == g ? 1 : 2); // is max r g or b?
        r /= 255, g /= 255, b /= 255, min /= 255, max /= 255;
        let h, s, l = (max + min) / 2;
        if (max == min) {
            h = s = 0; // achromatic
        } else {
            let d = max - min;
            s = l > 0.5 ? d / (2 - max - min) : d / (max + min);
            switch (componentCase) {
                case 0: h = (g - b) / d + (g < b ? 6 : 0); break;
                case 1: h = (b - r) / d + 2; break;
                case 2: h = (r - g) / d + 4; break;
            }
            h /= 6;
        }
        return [h, s, l, a];
};

Also, note that you should use const or let, but not var, to avoid the known risks related to the obsolete var.
Then, it is not nice that you accept separate r, g, and b on input but the function returns an array. Why RGB should be different from HSL? Note the line let [r, g, b, a] = rgba.

Finally, it is good to have the alpha channel as well. This work is done for the use in CSS, where the alpha channel is generally used everywhere.

Here's a version of hslToRgb for Clojure (and ClojureScript and whatever Clojure implementation):

(defn hsl->rgb [h s l]
  (let [hue->rgb (fn hue->rgb
                   [p q t]
                   (let [t (if (< t 0) (inc t) t)
                         t (if (> t 1) (dec t) t)]
                     (cond
                       (< t (/ 1 6)) (+ p (* (* (- q p) 6) t))
                       (< t (/ 1 2)) q
                       (< t (/ 2 3)) (+ p (* (* (- q p) (- (/ 2 3) t)) 6))
                       :else p)))
        [r g b] (if (= s 0)
                  [l l l]
                  (let [q (if (< l 0.5) (* l (+ 1 s)) (- (+ l s) (* l s)))
                        p (- (* 2 l) q)]
                    [(hue->rgb p q (+ h (/ 1 3))) (hue->rgb p q h) (hue->rgb p q (- h (/ 1 3)))]))]
    [(* r 255) (* g 255) (* b 255)]))

(comment
  (hsl->rgb (/ 120 256) 1.0 0.5)
  ;; => [0 255 207.18750000000003]
  :rcf)

It's a straight port. There may be dragons such as boxed math and things? I haven't considered.

Thank you, Peter!

Here's a version of hslToRgb for Clojure (and ClojureScript and whatever Clojure implementation):