Color generation algorithm
-
Here's my problem: I want to display a pie chart (using the awesome Zedgraph library available on CodeProject), but I don't know in advance how many slices it will have. It can be 5, it can be 25. Of course, I could define a hundred or so color constants, but that is not very elegant. I've searched on Google for a color generation algorithm that would generate a random set of reasonably contrasting colors, but I can't find anything. Anybody has seen anything like this? If you have or know of some source code, in any language, that would be great, C# preferred. For an example of how it should work, see Excel, no matter how many slices you add (within reason), it generates different colors for each slice. Thanks, Roel
-
Here's my problem: I want to display a pie chart (using the awesome Zedgraph library available on CodeProject), but I don't know in advance how many slices it will have. It can be 5, it can be 25. Of course, I could define a hundred or so color constants, but that is not very elegant. I've searched on Google for a color generation algorithm that would generate a random set of reasonably contrasting colors, but I can't find anything. Anybody has seen anything like this? If you have or know of some source code, in any language, that would be great, C# preferred. For an example of how it should work, see Excel, no matter how many slices you add (within reason), it generates different colors for each slice. Thanks, Roel
I actually think your best way would be to create a cyclic ordered list of about 16 colors: c1->c2-> ..., c20 ->c1 ... where each color is nicely contrasted with the one in front of it (I think any real totally non color-constant based method could create high contrast colors, but would have a hard time making them be attractive). Then you could either just keep cycling between the colors as you create boxes (and checking that the first bar color generated is high contrast with the last, which will be adjacent pie pieces), or you could tweak the r, g, and b values of each color by adding a plus or minus 3 or something to each value. Basically, I just don't think that people can at all easily tell between more than about 20 colors the way you need them to for your app. (as an experiment if you reply to this, check out the list of emoticons you can choose from - almost all are in the orange/redish side of the spectrum. How many of those do you think you could really easily tell the difference between if you we looking for pieces in a pie? 4 maybe? So if you have 4 for each of red, yellow, green, blue, you need 16 constants). So point is that after any hypothetical algorithm you're describing generates 16 or 20 colors or so, it'll be tough to start telling new colors apart from old. Therefore making a list of 20 color values, *hand-picked* to look particularly good together, is likely the best way to go. If you want to add a little variety to the 20 colors, I would say take the rgb triplet of each color "generaed" and add a random number in the [-j, j] range, where j is some number you'll have to figure out empirically based on what works best. That'd be likely to be best of both worlds, I think.
-
I actually think your best way would be to create a cyclic ordered list of about 16 colors: c1->c2-> ..., c20 ->c1 ... where each color is nicely contrasted with the one in front of it (I think any real totally non color-constant based method could create high contrast colors, but would have a hard time making them be attractive). Then you could either just keep cycling between the colors as you create boxes (and checking that the first bar color generated is high contrast with the last, which will be adjacent pie pieces), or you could tweak the r, g, and b values of each color by adding a plus or minus 3 or something to each value. Basically, I just don't think that people can at all easily tell between more than about 20 colors the way you need them to for your app. (as an experiment if you reply to this, check out the list of emoticons you can choose from - almost all are in the orange/redish side of the spectrum. How many of those do you think you could really easily tell the difference between if you we looking for pieces in a pie? 4 maybe? So if you have 4 for each of red, yellow, green, blue, you need 16 constants). So point is that after any hypothetical algorithm you're describing generates 16 or 20 colors or so, it'll be tough to start telling new colors apart from old. Therefore making a list of 20 color values, *hand-picked* to look particularly good together, is likely the best way to go. If you want to add a little variety to the 20 colors, I would say take the rgb triplet of each color "generaed" and add a random number in the [-j, j] range, where j is some number you'll have to figure out empirically based on what works best. That'd be likely to be best of both worlds, I think.