ENH: add XKCD colorname -> hex mapping

[tacaswell]

This still needs

• smoke test
• what's new/api changes documentation (re-use table from xkcd color names #4383 )
• sort out how to make this configurable

Doing this naively with an rcparam is tricky because rcsetup import colors which is imported by __init__.

We could :

• provide some helper functions in color
• provide all the X11 names prefixed with 'X11_' so you could be sure to get that if you wanted it
• do some crazy local imports + hasattr checks

closes #4383

[tacaswell]

There are 100+ test failures from this (which is more like 30-40 unique tests once the pdf/png/svg sets are taken into account) where one of the overlapping colors is used. I am inclined to change the tests to use the 'short' colors which will still have the highest priority.

[efiring]

Minimizing test image replacements this way sounds fine to me.

[tacaswell]

I noticed that there was a lot of missed overlap in color names due to xkcd having space in their names. Fixing that, they basically all clash (cyan, white, and black are the same)

[mdboom]

Having so many clashes doesn't really bother me. (i.e. having lots of clashes vs. a few clashes feels like the same about of problem in my mind).

I agree with Eric -- fixing the test source code to force use of the old colors is way preferable over a mass regeneration of images for a sort of "unimportant" (unlikely to uncover bugs) reason.

[tacaswell]

I had not realized initially that the X11 names are also the HTML / CSS
names. I think that is a pretty strong argument for defaulting to those
names over the XKCD names.

On Mon, Jan 4, 2016 at 10:24 AM Michael Droettboom notifications@github.com
wrote:

Having so many clashes doesn't really bother me. (i.e. having lots of
clashes vs. a few clashes feels like the same about of problem in my mind).

I agree with Eric -- fixing the test source code to force use of the old
colors is way preferable over a mass regeneration of images for a sort of
"unimportant" (unlikely to uncover bugs) reason.

—
Reply to this email directly or view it on GitHub
#5775 (comment)
.

[tacaswell]

The current round of failures is caused by floats not round-tripping to rbg floats, ex

In [15]: import matplotlib.colors as mc

In [16]: mc.hex2color(mc.rgb2hex((0, .5, 0)))
Out[16]: (0.0, 0.5019607843137255, 0.0)

In [17]: mc.hex2color(mc.rgb2hex((0, .75, 0.75)))
Out[17]: (0.0, 0.7490196078431373, 0.7490196078431373)

and in my attempt to simplify handling of the single letter mappings I converted the hard-coded tuples to hard-coded hex values. This is what is causing the tiny differences. Interestingly, I think this mean 'g', 'y', 'm' have always been slightly different than their named counterparts.

[mdboom]

I think all we need to ensure is that the precision of the hex numbers (8-bits per plane) is retained. Most of our displays can't display more precision than that anyway.

assert mc.rgb2hex(mc.hex2color(color)) == color

should hold true. But the inverse doesn't really matter.

[tacaswell]

I suspect the failed tests where cases where anti-aliasing was involved and 1 bit got changed.

[tacaswell]

In [116]: ll = [str(i) for i in range(10)] + ['a', 'b', 'c', 'd', 'e', 'f']

In [117]: h = map(lambda x: '#'+''.join(x), itertools.product(*([ll] * 6)))

In [118]: import matplotlib.colors as mc

In [119]: for _ in h:
   .....:     assert _ == mc.rgb2hex(mc.hex2color(_))
   .....: 

This completes sucessfully, but take too long to run to be worth putting in the test suite.

[WeatherGod]

Yes, 'g', 'y' and 'm' have always been slightly different. I don't know the
full reasons, but it has been that way for as long as I can remember.

On Mon, Jan 18, 2016 at 8:46 PM, Thomas A Caswell notifications@github.com
wrote:

In [116]: ll = [str(i) for i in range(10)] + ['a', 'b', 'c', 'd', 'e', 'f']

In [117]: h = map(lambda x: '#'+''.join(x), itertools.product(*([ll] * 6)))

In [118]: import matplotlib.colors as mc

In [119]: for _ in h:
.....: assert _ == mc.rgb2hex(mc.hex2color(_))
.....:

This completes sucessfully, but take too long to run to be worth putting
in the test suite.

—
Reply to this email directly or view it on GitHub
#5775 (comment)
.