Converting RGB to HLS and back
Question:
I’m using python’s colorsys library to convert RGB color values to HLS. Just to verify, I tried converting back to RGB and got a different value back. I can understand minor differences because of precision issues, but these values are significantly different.
Here’s my code:
import colorsys
r=192
g=64
b=1
hlsval = colorsys.rgb_to_hls(r,g,b)
rgbval=colorsys.hls_to_rgb(hlsval[0],hlsval[1],hlsval[2])
print hlsval, rgbval
Output:
(0.16666666666666666, 96.5, -1.0) (191.99999999999994, 192.0, 1.0)
The green value is off by over 200%
I tried some other values, and every time one of the components is off by a significant amount. Am I missing something?
Answers:
Your values are way, way outside the bounds of the colorspace:
From the docs:
Coordinates in all of these color spaces are floating point values… In all other spaces [than YIQ], the coordinates are all between 0 and 1.
I’m guessing you’re expecting them to be byte values between 0 and 255? Just divide by 255 first:
r, g, b = 192, 64, 1
r, g, b = [x/255.0 for x in r, g, b]
h, l, s = colorsys.rgb_to_hls(r, g, b)
r, g, b = colorsys.hls_to_rgb(h, l, s)
r, g, b = [x*255.0 for x in r, g, b]
print r, g, b
This will give you:
192.0 64.0 1.0
If you want to understand why you get such ridiculous errors when you go way outside the bounds of the colorspace.
Well, first, read the two documents linked from the docs to understand why values outside the colorspace are meaningless, and why you’re asking it to generate values to impossible constraints. Then, to figure out exactly why it fails in the way it does instead of some other way, you need to know which algorithm it’s using—which is pretty easy, since the docs link to the source code, which is pure Python and pretty readable.
(PS, I can imagine what 9650% lightness might look like, but I’m curious about -100% saturation. Probably something Lovecraftian.)
I’m using python’s colorsys library to convert RGB color values to HLS. Just to verify, I tried converting back to RGB and got a different value back. I can understand minor differences because of precision issues, but these values are significantly different.
Here’s my code:
import colorsys
r=192
g=64
b=1
hlsval = colorsys.rgb_to_hls(r,g,b)
rgbval=colorsys.hls_to_rgb(hlsval[0],hlsval[1],hlsval[2])
print hlsval, rgbval
Output:
(0.16666666666666666, 96.5, -1.0) (191.99999999999994, 192.0, 1.0)
The green value is off by over 200%
I tried some other values, and every time one of the components is off by a significant amount. Am I missing something?
Your values are way, way outside the bounds of the colorspace:
From the docs:
Coordinates in all of these color spaces are floating point values… In all other spaces [than YIQ], the coordinates are all between 0 and 1.
I’m guessing you’re expecting them to be byte values between 0 and 255? Just divide by 255 first:
r, g, b = 192, 64, 1
r, g, b = [x/255.0 for x in r, g, b]
h, l, s = colorsys.rgb_to_hls(r, g, b)
r, g, b = colorsys.hls_to_rgb(h, l, s)
r, g, b = [x*255.0 for x in r, g, b]
print r, g, b
This will give you:
192.0 64.0 1.0
If you want to understand why you get such ridiculous errors when you go way outside the bounds of the colorspace.
Well, first, read the two documents linked from the docs to understand why values outside the colorspace are meaningless, and why you’re asking it to generate values to impossible constraints. Then, to figure out exactly why it fails in the way it does instead of some other way, you need to know which algorithm it’s using—which is pretty easy, since the docs link to the source code, which is pure Python and pretty readable.
(PS, I can imagine what 9650% lightness might look like, but I’m curious about -100% saturation. Probably something Lovecraftian.)