CIEDE2000 implementation in bc

This page presents a reference implementation of the CIEDE2000 color difference formula in bc. If you want to ensure perfect compatibility (to the tenth decimal place) with certain third-party implementations, it may be necessary to modify the comments in the source code; the following link automates this operation for you.

The ΔE2000 function in bc

Let’s consider the more common and academic (Sharma, 2005) of the two formulations.

/* This function written in bc is not affiliated with the CIE (International Commission on Illumination),
and is released into the public domain. It is provided "as is" without any warranty, express or implied. */

m_pi = 0.0

/* The classic CIE ΔE2000 implementation, which operates on two L*a*b* colors, and returns their difference.
"l" ranges from 0 to 100, while "a" and "b" are unbounded and commonly clamped to the range of -128 to 127. */
define ciede_2000(l_1, a_1, b_1, l_2, a_2, b_2) {
	/* Working in Basic Calculator with the CIEDE2000 color-difference formula.
	k_l, k_c, k_h are parametric factors to be adjusted according to
	different viewing parameters such as textures, backgrounds... */
	k_l = 1.0
	k_c = 1.0
	k_h = 1.0
	if (m_pi == 0.0) {
		/* Computing pi ... 3.141592653589793238462643383279502884197169399375105820974945
		with arbitrary precision using Machin’s formula proposed in 1706. */
		m_pi =  16.0 * a(0.2) - 4.0 * a(1.0 / 239.0)
	}
	n = (sqrt(a_1 * a_1 + b_1 * b_1) + sqrt(a_2 * a_2 + b_2 * b_2)) * 0.5
	n = n * n * n * n * n * n * n
	/* A factor involving chroma raised to the power of 7 designed to make
	the influence of chroma on the total color difference more accurate. */
	n = 1.0 + 0.5 * (1.0 - sqrt(n / (n + 6103515625.0)))
	/* Application of the chroma correction factor. */
	c_1 = sqrt(a_1 * a_1 * n * n + b_1 * b_1)
	c_2 = sqrt(a_2 * a_2 * n * n + b_2 * b_2)
	/* Using 14 lines to simulate atan2, as bc does not have this built-in. */
	if (0.0 < a_1) {
		h_1 = a(b_1 / (a_1 * n)) + (b_1 < 0.0) * 2.0 * m_pi
	} else if (a_1 < 0.0) {
		h_1 = a(b_1 / (a_1 * n)) + m_pi
	} else {
		h_1 = m_pi + ((b_1 < 0.0) - (0.0 < b_1)) * 0.5 * m_pi
	}
	if (0.0 < a_2) {
		h_2 = a(b_2 / (a_2 * n)) + (b_2 < 0.0) * 2.0 * m_pi
	} else if (a_2 < 0.0) {
		h_2 = a(b_2 / (a_2 * n)) + m_pi
	} else {
		h_2 = m_pi + ((b_2 < 0.0) - (0.0 < b_2)) * 0.5 * m_pi
	}
	/* The atan2 polyfill (customized) is complete. */
	if (h_2 < h_1) { n = h_1 - h_2; } else { n = h_2 - h_1; }
	/* Cross-implementation consistent rounding. */
	if (m_pi - 0.00000000000001 < n && n < m_pi + 0.00000000000001) { n = m_pi; }
	/* When the hue angles lie in different quadrants, the straightforward
	average can produce a mean that incorrectly suggests a hue angle in
	the wrong quadrant, the next lines handle this issue. */
	h_m = (h_1 + h_2) * 0.5
	h_d = (h_2 - h_1) * 0.5
	if (m_pi < n) {
		h_d = h_d + m_pi
		/* 📜 Sharma’s formulation doesn’t use the next line, but the one after it,
		and these two variants differ by ±0.0003 on the final color differences. */
		h_m = h_m + m_pi
		/* h_m = h_m + ((h_m < m_pi) - (m_pi <= h_m)) * m_pi */
	}
	p = 36.0 * h_m - 55.0 * m_pi
	n = (c_1 + c_2) * 0.5
	n = n * n * n * n * n * n * n
	/* The hue rotation correction term is designed to account for the
	non-linear behavior of hue differences in the blue region. */
	r_t = -2.0 * sqrt(n / (n + 6103515625.0)) \
			* s(m_pi / 3.0 * e(p * p / (-25.0 * m_pi * m_pi)))
	n = (l_1 + l_2) * 0.5
	n = (n - 50.0) * (n - 50.0)
	/* Lightness. */
	l = (l_2 - l_1) / (k_l * (1.0 + 0.015 * n / sqrt(20.0 + n)))
	/* These coefficients adjust the impact of different harmonic
	components on the hue difference calculation. */
	t = 1.0 	+ 0.24 * s(2.0 * h_m + m_pi / 2.0) \
			+ 0.32 * s(3.0 * h_m + 8.0 * m_pi / 15.0) \
			- 0.17 * s(h_m + m_pi / 3.0) \
			- 0.20 * s(4.0 * h_m + 3.0 * m_pi / 20.0)
	n = c_1 + c_2
	/* Hue. */
	h = 2.0 * sqrt(c_1 * c_2) * s(h_d) / (k_h * (1.0 + 0.0075 * n * t))
	/* Chroma. */
	c = (c_2 - c_1) / (k_c * (1.0 + 0.0225 * n))
	/* Returning the square root ensures that dE00 accurately reflects the
	geometric distance in color space, which can range from 0 to around 185. */
	return sqrt(l * l + h * h + c * c + c * h * r_t)
}

/*
  GitHub Project : https://github.com/michel-leonard/ciede2000-color-matching
    Online Tests : https://michel-leonard.github.io/ciede2000-color-matching

   L1 = 30.8   a1 = 22.0   b1 = -4.4
   L2 = 28.1   a2 = 16.4   b2 = 4.3
   CIE ΔE00 = 7.0779305175 (Bruce Lindbloom, Netflix’s VMAF, ...)
   CIE ΔE00 = 7.0779164917 (Gaurav Sharma, OpenJDK, ...)
   Deviation between implementations ≈ 1.4e-5

   See the source code comments for easy switching between these two widely used ΔE*00 implementation variants.
*/

k_l, k_c and k_h parameters

The parameters k_l, k_c and k_h in the CIEDE2000 formula are weighting factors applied to the brightness (ΔL*), chroma (ΔC*) and hue (ΔH*) components respectively. In the source code, they are defined as constants with a default value of 1, corresponding to the standard observation conditions laid down by the International Commission on Illumination (CIE). In practice, you might need to adjust these coefficients to reflect specific conditions: for example, k_l = 2 is sometimes used to give more weight to differences in brightness (a common occurrence in the textile industry), while k_c or k_h can be reduced to increase tolerance for variations in saturation or hue, depending on the requirements. Depending on the context, these coefficients typically range from 0.5 to 2.

Source code accuracy and reliability

The difference between Sharma’s academic formulation and Lindbloom’s simplified formulation does not exceed ±0.0003 on the final ΔE2000. This corresponds to the difference usually measured between two 32-bit implementations and is imperceptible to the human eye. Our 64-bit implementations, all consistent with each other, guarantee at least 10 correct decimal places, so the choice of one formulation over the other is a technical detail. The default formula on this page is the one most often presented in the community, it is slightly easier to vectorize.

How do you convert RGB colors to L*a*b*?

Go to the AWK, C, Dart, Java, JavaScript, Kotlin, Lua, PHP, Python, Ruby or Rust page where such a converter (using D65 illuminant) is already implemented in addition to the color comparison function.

CIELAB value ranges and interpretation of the ΔE2000

In the CIELAB color space, the L* component represents lightness and typically ranges from 0 (black) to 100 (white). The a* and b* components represent color axes: a* goes from green to red, while b* goes from blue to yellow. In practice, a* and b* values usually fall between -128 and +127, although they can slightly exceed these limits depending on the color conversion.

ΔE2000 (CIEDE2000) measures the perceived difference between two colors: 0 means the colors are identical, and higher values (up to around 185 in extreme cases) indicate a larger difference. For example, a ΔE2000 value around 5 means the colors are close, while a value around 15 means they are clearly different.

Example of use in bc

echo 'scale=50;ciede_2000(13.1, 11.9, 3.8, 13.0, 17.6, -4.9)' | bc -l ciede-2000.bc

# Outputs: 7.37458016458016885544127036110301868134320454640263
# As explained in the comments, compliance with Gaurav Sharma would display ...
# ........ 7.37456659946646273510289154231355556542867583609039

Test results

This bc function has been tested with the multi-precision Julia driver designed for this purpose.

CIEDE2000 Verification Summary :
  First Verified Line : 27,-123,101,44,42.0000098,-99,70.204734814936909810694644954670527048474482887
             Duration : 18644.34 s
            Successes : 10000000
               Errors : 0
      Average Delta E : 62.9618
    Average Deviation : 4.0e-38
    Maximum Deviation : 2.2e-35

Files to download

A file below supports arbitrary precision calculations in bc (useful if you’re dealing with ΔE2000 in metrology). Feel free to use these files provided by Michel, even for commercial purposes.

Community

What do you think of this source code or CIEDE2000? Your opinion is important to us! The guestbook already contains 9 messages - including 1 in English. Take a look and share your opinion.