Repository navigation
matplotlib.colors rgb2hex is not the right inverse of hex2color #18574
Description
>>> matplotlib.__version__
'3.3.2'
>>> from matplotlib.colors import rgb2hex, hex2color
>>> rgb_color = (0.5, 0.5, 0.9)
>>> hex2color(rgb2hex(rgb_color))
(0.5019607843137255, 0.5019607843137255, 0.9019607843137255)
It should return (0.5, 0.5, 0.9).
As it seems the additive factor it is always the same, it should be a matter of subtracting 0.0019607843137255 from the three channels.
Thanks!
P.S. the inverse composition works as expected:
>>> rgb2hex(hex2color( '#808080'))
'#808080'
Activity
[-]matplotlib.colors rgb2hex and hex2color are not bijective.[/-][+]matplotlib.colors rgb2hex is not the right inverse of hex2color[/+]SebastianoF commentedon Sep 25, 2020
(Also renaming hex2color to hex2rgb for a next major release would simplify the interface)
jklymak commentedon Sep 25, 2020
What happens if you run that through twice? Does the error accumulate or is it steady?
tacaswell commentedon Sep 25, 2020
It is stable after the first round-trip:
I think that this is unavoidable because in hex we only have 256 possible values where as floats we have many more (in theory infinite, in practice "a lot" due to the limitations of floating point). Hence, when we go from float -> hex many float values will convert to the same hex value, but when we go back to float we can only map to one value, thus we get the miss-match when we try to round-trip.
If you start from hex you are mapping one integer value into the reals and then mapping 1 float value back to int so it is invertable.
In #6382 we added more consistently named functions (see https://matplotlib.org/api/colors_api.html#functions) but did not remove the old ones because we did not think that the possibility of breaking users code was worth the simplification.
I am going to close this issue as there is nothing we can do about float -> int -> float round tripping being lossey and we already have clearer names available.