Broken distinguishable_colors about colors.jl

[axsk]

Reading further I realized that in LCH the luminance is defined to be in [0,100],
so I screwed this up :/
Comparing again Colors.distinguishable_colors(8)

with Color.distinguishable_colors(8)

made me wonder though why yellow is skipped in favour of a third blue (I don't find 5 and 8 so easy to distinguish :/) in the new version...

Well, it's not broken so feel free to close this.

[axsk]

Oh, would we maybe have some space for fixed color palettes like these?

[timholy]

The difference between the old and new is that it performs the computations in LCHab space in the new one; it constantly converts between RGB and LCHab in the old one. There could, of course, be a bug; you could @show the color differences between candidates you like and the ones it chooses, if you feel like diving into this.

[timholy]

I'd be fine with having some fixed palettes. There's a ColorBrewer package already, interestingly. Not really my expertise, so others should chime in.

[axsk]

Correct me if I'm wrong, but increasing the desired number of colors just adds new colors to the palette and doesn't change the already obtained. I wonder if it possible to obtain the really maximally distinguishable colors this way. Shouldn't I have to move all colors when adding a new one?

The simple picture in my head is that of a circle. When choosing n points with maximal distance I divide it into equally large sectors, but this requires changing multiple points when increasing n.

[timholy]

Correct. This package produces the nth distinguishable color as the one "farthest" from the first n-1. It does not reconsider the first n-1 in light of the chosen value for the nth.

Another algorithm would, of course, make a fine contribution. Would be interesting to compare performance.