white balance - What should I do with negative values when computing sRGB colors from spectra?

This question is from the computational side of things. Maybe some of you computational photography folks can help me out.

If I have a normalized CIE XYZ tristimulus vector like this one:

(x, y, z)  =  (0.2, 0.7, 0.1)

and I follow the sRGB derivation process as on wikipedia, w3's spec, or right here on photo.SE, I get the following value for the pre-gamma corrected r:

r = 3.2406 * x   - 1.5372 * y   - 0.4986 * z
  = 3.2406 * 0.2 - 1.5372 * 0.7 - 0.4986 * 0.1
  = -0.47778

Since this value is less than 0.0031308, scale it by 12.92 to get the final gamma-corrected R value:

R = 12.92 * r
  = 12.92 * -0.47778
  = -6.173

Now, wikipedia states the following about this final gamma-corrected value, and the corresponding G and B values not shown here

These gamma-corrected values are in the range 0 to 1. If values in the range 0 to 255 are required, e.g. for video display or 8-bit graphics, the usual technique is to multiply by 255 and round to an integer.

-6.173 is definitely not within the range 0 to 1. Am I doing something wrong? If not, what should I do with such a value?

Answer

You are not clipping the intermediate RGB values.

From the sRGB Wikipedia article you linked to,

The intermediate parameters R, G and B for in-gamut colors are defined to be in the range [0,1], ... The linear RGB values are usually clipped to that range, with display white represented as (1,1,1)

From the W3C sRGB spec you linked to,

... XYZ are normalised such that Y=1 for the reference white and values of RGB outside of 0-1 are clipped.

Note that your (x,y) values are just about polar opposite from red, in the green region in the upper left of the CIE color space chromaticity diagram. Effectively, you are "so far away from red", it's almost like "negative red". Clip the R value: in sRGB, your red emphatically will be zero.