As part of the Mentored Sprints at PyCon US, Marielle wrote some property-based tests [1] for the colorsys module [2], which found two bugs.


Taking a YIQ color, converting to RGB, and back to YIQ can result in the Y coordinate varying by more 0.1 (where [0, 1] is the range of possible values).
For example: (0.0 1.0 2.2204460492503136e-16) -> RGB -> (0.0 1.1102230246251568e-16 1.0)

Taking an RGB color and converting though HSV-RBG-HSV can result in very different saturation values - up to having S1==0 and S2==1.
For example: (0.0 1.0 2.2204460492503136e-16) -> RGB -> (0.0 1.1102230246251568e-16 1.0)


You can reproduce additional examples and get error bounds from [3].


[1] https://pyfound.blogspot.com/2020/05/property-based-testing-for-python.html
[2] https://docs.python.org/3/library/colorsys.html
[3] https://github.com/Zac-HD/stdlib-property-tests/pull/13

See https://bugs.python.org/issue14323

It is correct. Colorspaces for RGB an YIQ are different. Not all RGB colors can be represented in YIQ and vice versa. For YIQ color (0, 1, 0) you need RGB color (0.9468822170900693, -0.27478764629897834, -1.1085450346420322), but the G and B components are out of the range [0, 1]. So yiq_to_rgb() returns the closes RGB color to the original code, and it is (0.9468822170900693, 0, 0). It is the best that you can get.