ColorDistance[], ColorConvert[]

[ghost]

implements ColorDistance[], ColorConvert[] and accompanying color spaces like LABColor[]. Values computed (through ColorConvert[] or ColorDistance[]) should always be identical to MMA within the first few digits at least.

Fixes current behaviour that always added alpha channels to colors, i.e. turning RGBColor[1, 0, 0] into RGBColor[1, 0, 0, 1] instantly. Alpha values now only occur if they are specified.

[ghost]

I just realized I should rework this in a more general way, in order to use the color conversion functions for Image[] as well, in order to get rid of the skimage dependency there and switch to PIL instead.

[wolfv]

Or maybe Pillow instead of PIL?

[sn6uv]

@poke1024 What's the status of this? It looks finished to me but I thought I should check with you before merging.

[ghost]

I'm done with it, it's the best solution I can come up with. My main goals were that there's no code duplication of the color conversion stuff for numpy and non-numpy cases and that numerical results are near or identical to MMA. Would be happy to work on Image[] based on this.

[ghost]

rebased on current master and ready to merge

[ghost]

Have no idea why the PyPy build is marked as fail, it ends with OK.

[sn6uv]

The PyPy test is failing when running the unittests, i.e. setup.py test:

======================================================================

ERROR: testConversions (test_color.ColorTest)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "/home/travis/build/mathics/Mathics/test/test_color.py", line 252, in testConversions

    c = components[:3]

NotImplementedError: settting a slice of a PySequence_Fast is not supported

[ghost]

I fear I broke Travis for good now. It's rebased and still no Travis info.

[sn6uv]

Travis is having some issues today: link to details. Might be related to that. I've closed and opened which seems to have triggered a build.

[sn6uv]

What about conversions that require intermediate transformations. E.g. LCH -> LAB -> XYZ -> RGB -> HSB. Is it worth formulating this as a graph search problem?

[ghost]

LCH -> LAB -> XYZ -> RGB -> HSB would be handled by flow using RGB as proxy (first if case) and then converting LCH to RGB and RGB to HSB. The code is a mess though, and I'll redo this with a simple and properly precomputed graph route table.

The underlying graph is beautiful, with RGB and XYZ being the central conversion hubs: