ColorData["VisibleSpectrum"] is wrong?

Question

Bug introduced in 10.0 or earlier and fixed in 11.1

---

I am trying to visualize the visible spectrum using the built-in ColorData["VisibleSpectrum"] function which "colors based on light wavelength in nanometers". But I get wrong results for well-known pure colors. For example the yellow color has wavelength of 570–590 nm but ColorData["VisibleSpectrum"][580] returns green:

Is it a bug? How to visualize the visible spectrum in Mathematica correctly?

Answer 1

(too long for a comment)

Plot[{ColorData["VisibleSpectrum"][x][[1]],
      ColorData["VisibleSpectrum"][x][[2]],
      ColorData["VisibleSpectrum"][x][[3]]}, {x, 380, 750}, PlotStyle -> {Red, Green, Blue}]

It doesn't seem that you'll be able to obtain Yellow (RGBColor[1, 1, 0]) from ColorData["VisibleSpectrum"]; unfortunately, the docs say nothing about how they're blending the colors to produce "VisibleSpectrum".

---

Addendum:

Just to make this post less useless, here's a Mathematica implementation of Bruton's conversion algorithm:

brutonIntensity = Interpolation[{{380, 3/10}, {420, 1}, {700, 1}, {780, 3/10}},
                                InterpolationOrder -> 1];

brutonLambda[x_, γ_: 4/5] := Map[N[brutonIntensity[x] #]^γ &, 
    Blend[{{0, Magenta}, {3/20, Blue}, {11/40, Cyan}, {13/40, Green}, {1/2, Yellow},
           {53/80, Red}, {1, Red}}, Rescale[x, {380, 780}]]] /;
    380 <= x <= 780 && 0 < γ <= 1

Here's a gradient plot:

and an RGB component plot:

For converting wavelengths to CIE xyz coordinates, see this thread; the current version of Mathematica now has built-in (but undocumented) functionality for the CIE CMFs. Alternatively, I also posted serviceable approximations of the CMFs as well in there.

Answer 2

Update

Mathematica 10 introduced ChromaticityPlot which provides internal evidence of a discrepancy. Consider:

ChromaticityPlot[
 {"RGB", ColorData["VisibleSpectrum"] /@ {570, 600, 700}}, 
 Appearance -> {"VisibleSpectrum", "Wavelengths" -> True},
 BaseStyle -> PointSize[0.03]
]

Clearly the three values are offset from the labeled wavelengths along the perimeter. The position of ColorData["VisibleSpectrum"][700] can be explained by the fact that gamut is compressed. Based on the positioning I propose that the other values along that edge were offset by a similar degree resulting in the distortion of color that is the topic of discussion.

If you would to use the data embedded in ChromaticityPlot in place of ColorData["VisibleSpectrum"] please see:

• A better "VisibleSpectrum" function?

---

That's a good question. There does seem to be a considerable discrepancy versus the 1931 CIE diagram:

GraphicsGrid @ List @ Table[
   Graphics @ {ColorData["VisibleSpectrum"][i], Disk[], White, Text[i]},
   {i, 380, 700, 10}
]

Perhaps there was a miscalculation made in reducing the very large CIE color space values to sRGB triplets? sRGB, the standard display space, is the inset triangle below:

Answer 3

I just had a look at the colours as they are produced on my screen. I have been working with lasers for many (30+) years and can assure you that a 591nm laser line is fairly yellow, around 635nm is fairly red and 488nm appears as cyan, which resembles the colours of the disks well. Are you sure you are not confusing the wavelength of the maximum of black body radiation and its apparent colour with that of single lines? A perfect match of the numbers is not required but their ratios should be close.

With[{colors = {
    {Yellow, ColorData["VisibleSpectrum"][591]}, 
    {Cyan, ColorData["VisibleSpectrum"][488]}, 
    {Red, ColorData["VisibleSpectrum"][635]}}
    },
    ({#, Graphics[{#, Disk[]}] & /@ #} & /@ colors)~Flatten~1 // Grid
]

Answer 4

This is a bug (or an imperfection) of ColorData["VisibleSpectrum"].

Others have delved into its root, but in my answer I simply will make it clear by a comparison with an experimental, known single wavelength color^[1]: sodium’s D-line at 589.0 nm.

Here is Mathematica’s idea of the color of this wavelength, using default settings (no color profile conversion applied, default MMA settings on my MacBook Pro, Mac OS X 10.8.2):

Anyone who has observed the sodium D-line during as a student will know that it doesn't have that greenish hue seen above. Now, here are spectroscopic observations of this same color, for those who have never seen it:

• Fabry-Perot interferometer

  

• Michelson interferometer

  

In conclusion: sure, color conversions are tricky… but here, Mathematica is well outside the margin of error :)

 

 

 

---

[1] Well, almost single color… the two lines are not that far apart.

Answer 5

One hypothesis:

If mathematica's using this set of formulae to convert from XYZ to RGB:

//This is coming from www.easyrgb.com

var_X = X / 100        //X from 0 to  95.047      (Observer = 2°, Illuminant = D65)
var_Y = Y / 100        //Y from 0 to 100.000
var_Z = Z / 100        //Z from 0 to 108.883

var_R = var_X *  3.2406 + var_Y * -1.5372 + var_Z * -0.4986
var_G = var_X * -0.9689 + var_Y *  1.8758 + var_Z *  0.0415
var_B = var_X *  0.0557 + var_Y * -0.2040 + var_Z *  1.0570

if ( var_R > 0.0031308 ) var_R = 1.055 * ( var_R ^ ( 1 / 2.4 ) ) - 0.055
else                     var_R = 12.92 * var_R
if ( var_G > 0.0031308 ) var_G = 1.055 * ( var_G ^ ( 1 / 2.4 ) ) - 0.055
else                     var_G = 12.92 * var_G
if ( var_B > 0.0031308 ) var_B = 1.055 * ( var_B ^ ( 1 / 2.4 ) ) - 0.055
else                     var_B = 12.92 * var_B

R = var_R * 255
G = var_G * 255
B = var_B * 255 

AND, if their algorithm tries to normalize the result to have the highest R or G or B value to be equal to 255

AND, if any RGB value below 0 is simply ignored and set to 0

THEN, 570 nm having the CIE xy coordinates:

x = 0.4441
y = 0.5547

Should give, after following these rules, the XYZ values:

X = 72.77  // this is proportionnal to Y
Y = 90.89  // this is to give the value 255 to the G value
Z = 0.2    // this is proportionnal to Y (and extremely low!)

These values give the following rounded RGB values at gamma = 2.4

R = 230
G = 255
B = - 471

Of course, if you cut the - 471 and replace it with 0, that makes quite a difference, let's see what CIE L*a*b* basic delta E color difference formulae will say (the delta E is just the Cartesian distance between 2 points in the CIE L*a*b* colorspace)

We call C the original conversion an C' the 'minus-cut' value

C    L*= 96.367
     a*= -26.924
     b*= 163.337

C'   L*= 95.305
     a*= -31.712
     b*= 92.307

The delta E is:

D = sqrt((96.367-95.305)^2+(-26.924+31.712)^2+(163.337-92.307)^2)

D = -71.199   (!!!!)

Knowing that a delta E superior to 1~2 is supposed to be perceptible, we see that here the color difference is supposed to be HUGE

One can argue that a color difference formula applied in this context might not be appropriated, and be right thinking so, but it is still a good illustration of what cutting negative values will produce...

Strangely, the software from EasyRGB is giving the following values, which are more yellowish:

R = 250.46
G = 255
B = 0

Couldn't find why...

**

EDIT:

Anyway,

Never forget that fact that it is simply impossible to display any spectral color on a screen!

Spectral colors in RGB will produce Red/Green/Blue values above 255 or below 0, When it's RED = 380 or -600, the difference between what's displayed and what it should be is SIGNIFICANT.

A better way I know to render the color spectra on a computer screen is to compute a mixture of white light + spectral colors, like this guy Nick Spiker did:

The principle is: white light is added until the negative values become positive or 0 and until the RGB values are below or equal to 255

This rendering gives you a visual result which is close to what spectral lights viewed in daylight conditions look like, and it is more exact than anything else I.M.Opinion.

EDIT 2 Example:

You can download Mr Pointer's material-colors gamut data here: http://www.cis.rit.edu/mcsl/online/cie.php

This database is my source for the CIE x,y coordinates of the spctral colors at a resolution of 1 nm (the spectrum locus)

The most simple way to render spectra + white light at the maximal saturation (or highest chroma) level is pick a white light (either illuminant D75, D65, D50, or C, or anything else you have at your disposal...)

I take D65, which has normalized CIE XYZ coordinates:

X = 95.047
Y = 100
Z = 108.883

Then I take all the xy coordinates of the spectrum locus and I transform them in normalized XYZ with the Y value given by the Y colorimetric function multiplied by the D65 curve (so this is the D65 spectrum), and normalized at: Ymax = Y 555nm = 100

Finally, I average the two values (XYZ D65)*a and (XYZ locus)*b, with a, b being weighted such as the RGB conversion of the result will have: min R or/and min G or/and min B = 0 and max R or/and max G or/and max B = 255

That's the basic idea

Answer 6

The code in the article linked by Alexey produces something similar to this (gradient plot inspired by J.M.'s comment) :

Note though that the description of the code does not seem consistent too me, so I had to change it in some places to get this result. Still I hope that I transcribed it more or less correctly. (I wouldn't use this for scientific purposes though!)

The code that creates the above figure is given below.

rgbSpec[x_] := 
RGBColor@@Piecewise[{
 {{19/100 + 19/3000 (410 - x), 0, 1 - 6/300 (410 - x)}, 380 <= x < 410}, 
 {{19/3000 (440 - x), 0, 1}, 410 <= x < 440},
 {{0, 1 - (490 - x)/50, 1}, 440 <= x < 490},
 {{0, 1, (510 - x)/20}, 490 <= x < 510},
 {{1 - (580 - x)/70, 1, 0},510 <= x < 580},
 {{1, (640 - x)/60, 0}, 580 <= x < 640},
 {{1, 0, 0}, 640 <= x < 700},
 {{35/100 + 65/8000 (780 - x), 0, 0}, 700 <= x <= 780}}]

(*rgb components*)
Plot[{rgbSpec[x][[1]], rgbSpec[x][[2]], rgbSpec[x][[3]]}, {x,380,780}, PlotStyle -> {Red, Green, Blue}, PlotRange -> All, Frame -> True]

(*gradient plot*)
DensityPlot[x, {x, 380, 780}, {y, 0, 1}, ColorFunction -> (rgbSpec[#] &), ColorFunctionScaling -> False,AspectRatio -> 1/10, FrameTicks -> {{None, None}, {Automatic, None}},Frame -> Automatic, PlotRangePadding -> None]

(If someone actually bothers to check, feel free to correct any mistakes!)