# 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?

• What usage are you planning to do with those values? Clipping them is entirely dependent on that. Sep 4, 2015 at 6:17
• Hmm.. If I understand your question, @KelSolaar, I'm constructing sRGB images for display on common, consumer monitors and mobile devices with normal web browsers, documents, and image file formats. Sep 4, 2015 at 16:22
• Allright, if the end-usage is display, then it makes sense to clip them. Sep 4, 2015 at 19:51

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.

• Oh! Interesting. Sorry, I really should've picked that up from those citations... So when people say that some color spaces have a larger "gamut", does that mean less of the CIE color space is clipped? Sep 4, 2015 at 3:44
• @kdbanman Yes! It means that they can encode a larger volume of the visible spectrum. Sep 4, 2015 at 8:32
• (I freely admit, this is being very pedantic), but astronomically speaking, you have to account for relative velocity between camera and object (i.e., redshift/blueshift). Just colour-managing the photograph without knowing if the camera is approaching or receding, can yield a wide range of colour errors. You'd have to look at emission spectra, and determine the degree of redshift/blueshift, and adjust the colour profile accordingly. After doing that, you have the actual colorimetry, not the gimmick which CIE excersises. Jan 19, 2017 at 0:58

-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?

The values that are outside of the 0..1 range are values that are out of gamut of the target sRGB color space - i.e sRGB can't describe them. So even though -6.173 seems like a huge value to ditch, it needs to be clipped to zero. If I am calculating it correctly, the resulting RGB value after clipping will be 0, 1, 0 (0, 255, 0).