When generating graphs and showing different sets of data it usually a good idea to difference the sets by color. So one line is red and the next is green and so on. The problem is then that when the number of datasets is unknown one needs to randomly generate these colors and often they end up very close to each other (green, light green for example).
Any ideas on how this could be solved and how it would be possibler to generate distinctly different colors?
I'd be great if any examples (feel free to just discuss the problem and solution without examples if you find that easier) were in C# and RGB based colors.
I think the HSV (or HSL) space has more opportunities here. If you don't mind the extra conversion, it's pretty easy to go through all the colors by just rotating the Hue value. If that's not enough, you can change the Saturation/Value/Lightness values and go through the rotation again. Or, you can always shift the Hue values or change your "stepping" angle and rotate more times.
I needed the same functionality, in a simple form.
What I needed was to generate as unique as possible colors from an an increasing index value.
Here is the code, in C# (Any other language implementation should be very similar)
The mechanism is very simple
A pattern of color_writers get generated from indexA values from 0 to 7.
For indices < 8, those colors are = color_writer[indexA] * 255.
For indices between 8 and 15, those colors are = color_writer[indexA] * 255 + (color_writer[indexA+1]) * 127
For indices between 16 and 23, those colors are = color_writer[indexA] * 255 + (color_writer[indexA+1]) * 127 + (color_writer[indexA+2]) * 63
And so on:
Note: To avoid generating bright and hard to see colors (in this example: yellow on white background) you can modify it with a recursive loop:
There's a flaw in the previous RGB solutions. They don't take advantage of the whole color space since they use a color value and 0 for the channels:
Instead they should be using all the possible color values to generate mixed colors that can have up to 3 different values across the color channels:
Using the full color space you can generate more distinct colors. For example, if you have 4 values per channel, then 4*4*4=64 colors can be generated. With the other scheme, only 4*7+1=29 colors can be generated.
If you want N colors, then the number of values per channel required is: ceil(cube_root(N))
With that, you can then determine the possible (0-255 range) values (python):
Then you can iterate over the RGB colors (this is not recommended):
Nested loops will work, but are not recommended since it will favor the blue channel and the resulting colors will not have enough red (N will most likely be less than the number of all possible color values).
You can create a better algorithm for the loops where each channel is treated equally and more distinct color values are favored over small ones.
I have a solution, but didn't want to post it since it isn't the easiest to understand or efficient. But, you can view the solution if you really want to.
Here is a sample of 64 generated colors: 64 colors
To implement a variation list where by your colors go, 255 then use all possibilities of that up, then add 0 and all RGB patterns with those two values. Then add 128 and all RGB combinations with those. Then 64. Then 192. Etc.
In Java,
This will produce patterns of that type infinitely (2^24) into the future. However, after a hundred or so spots you likely won't see much of a difference between a color with 0 or 32 in the blue's place.
You might be better off normalizing this into a different color space. LAB color space for example with the L,A,B values normalized and converted. So the distinctness of the color is pushed through something more akin to the human eye.
getElement() reverses the endian of an 8 bit number, and starts counting from -1 rather than 0 (masking with 255). So it goes 255,0,127,192,64,... as the number grows it moves less and less significant bits, subdividing the number.
getPattern() determines what the most significant element in the pattern should be (it's the cube root). Then proceeds to break down the 3N²+3N+1 different patterns that involve that most significant element.
This algorithm will produce (first 128 values):
Read left to right, top to bottom. 729 colors (9³). So all the patterns up to n = 9. You'll notice the speed at which they start to clash. There's only so many WRGBCYMK variations. And this solution, while clever basically only does different shades of primary colors.
Much of the clashing is due to green and how similar most greens look to most people. The demand that each be maximally different at start rather than just different enough to not be the same color. And basic flaws in the idea resulting in primary colors patterns, and identical hues.
Using CIELab2000 Color Space and Distance Routine to randomly select and try 10k different colors and find the maximally-distant minimum-distance from previous colors, (pretty much the definition of the request) avoids clashing longer than the above solution:
Which could be just called a static list for the Easy Way. It took an hour and a half to generate 729 entries:
Using brute force to (testing all 16,777,216 RGB colors through CIELab Delta2000 / Starting with black) produces a series. Which starts to clash at around 26 but could make it to 30 or 40 with visual inspection and manual dropping (which can't be done with a computer). So doing the absolute maximum one can programmatically only makes a couple dozen distinct colors. A discrete list is your best bet. You will get more discrete colors with a list than you would programmatically. The easy way is the best solution, start mixing and matching with other ways to alter your data than color.
Update: I continued this for about a month so, at 1024 brute force.
You have three colour channels 0 to 255 R, G and B.
First go through
Then go through
Then divide by 2 => 128 and start again:
Divide by 2 => 64
Next time add 64 to 128 => 192
follow the pattern.
Straightforward to program and gives you fairly distinct colours.
EDIT: Request for code sample
Also - adding in the additional pattern as below if gray is an acceptable colour:
There are a number of ways you can handle generating these in code.
The Easy Way
If you can guarantee that you will never need more than a fixed number of colours, just generate an array of colours following this pattern and use those:
The Hard Way
If you don't know how many colours you are going to need, the code below will generate up to 896 colours using this pattern. (896 = 256 * 7 / 2) 256 is the colour space per channel, we have 7 patterns and we stop before we get to colours separated by only 1 colour value.
I've probably made harder work of this code than I needed to. First, there is an intensity generator which starts at 255, then generates the values as per the pattern described above. The pattern generator just loops through the seven colour patterns.
I have put up a page online for procedurally generating visually distinct colors:
http://phrogz.net/css/distinct-colors.html
Unlike other answers here that evenly step across RGB or HSV space (where there is a nonlinear relationship between the axis values and the perceptual differences), my page uses the standard CMI(I:c) color distance algorithm to prevent two colors from being too visually close.
The final tab of the page allows you to sort the values in several ways, and then interleave them (ordered shuffle) so that you get very distinct colors placed next to one another.
As of this writing, it only works well in Chrome and Safari, with a shim for Firefox; it uses HTML5 range input sliders in the interface, which IE9 and Firefox do not yet support natively.