Arbitrary generation of unique colors?

Question

I use a graphics package that can draw color lines (255,255,255). So basically I do (Random.Next (0,255), Random.Next (0,255), Random.Next (0,255)) to generate color every time a line is added.

This is all good and good, but sometimes I get colors that look very similar, which makes it difficult for the user to recognize which data matches which string.

Is there a smarter way to generate random and unique colors in the format (255,255,255)?

Answer 1

The best option is to typically generate a random hue and convert the hue to RGB color using HSL or HSV color (with that hue). Using a random “shade” instead of a random color, you will get much more variations in your colors. You can also randomize other components (saturation / value, etc.) if you need even more options.

See Wikipedia for details on working with colors using HSV / HSL , including converting HSV to RGB .

Answer 2

Check "color distance"

Assuming RGB is the XYZ coordinate, calculate the 3D distance. If the color is at least N from all previously generated colors, try again.

N is the value you decide.

Answer 3

Assuming the hue difference is a measure of the Euclidean distance between the coordinates, you can
1. Remember the previous color generated (a, b, c)
2. make sure that the next generated (x, y, z) is at least more than half the maximum possible distance
those. sqrt [(ax) ^ 2 + (by) ^ 2 + (cz) ^ 2]> 1/2 sqrt (3 * 255 ^ 2)
3. Continue to generate random triplets until you get one that satisfies the above. If 1/2 is not enough, try 2/3, etc. strong text

Answer 4

A very simple solution can be to use more different levels, for example, when using ((Random.Next(0, 32) * 8) % 256) . Perhaps the comparison table can be used to skip existing colors.

Answer 5

Regarding uniqueness, look here .

For clearer color differences, you can try not to allow all possible values ​​from 0 to 255, but only a few steps, for example. 0-32-64-96-128-160-192-224-255, so you get a little contrast.

Answer 6

I wrote a utility function once to do this.

The idea was to linearize the RGB space in the 1D [0, 1] interval. For example, execute (R + G * 256 + B * 256 * 256) / (256 ^ 3 * 256 ^ 2 + 256).

Then, every time you need a new color, you separate the interval generated by the previous selections in 2. You select the first color as 0.0 in the new space, the second as 1.0, the third as 0.5, then 0.25, then 0.75 and so on. This view ensures that if you create multiple colors, they have maximum “separation” (although they are not measured in terms of hue). As you generate more and more colors, they usually come close to the one created earlier, but always observe the principle of maximum separation.

Once you have the value [0, 1], you use the inverse function (the triplet of functions actually) to return to RGB.

In the base implementation, you get white and black as the first two colors. If you want something else, once you have generated your "input" value [0, 1], you can rotate it, say, third, within the same interval.

This works very well and behaves deterministically (without an unlimited number of attempts).

Answer 7

Is there any reason for randomizing the colors, and not for putting them in a fixed sequence? I would suggest that you use an index that increases with each color. Use constant (possibly maximum) saturation for your colors; lightness will be frac (indexconst1) and hue be frac (indexconst2). I'm not sure how best to compute const1 and const2; which to some extent will depend on how many points you have.