views:

110

answers:

5

I would like to create a color generator based on random numbers, which might differ just slightly, but I need colors to be easily recognizable from each other. I was thinking about generation then in a rgb format which would be probably easiest. I'm afraid simply multiplying given arguments wouldn't do very well. What algorithm do you suggest using? Also, second generated color should not be the same as previous one, but I don't want to store them - nor multiplying with (micro)time would do well since the scripts' parts are usually faster.

A: 

For a true random number generator, have a look here. I'm sure you can bound it within a range of numbers too.

Tony
I'm pretty sure that for generating colors, there's no need to resort to "true random numbers".
Eclipse
Interesting. This is hardly what I was asking for, however it solves my problem pretty easily when I was forced to think it over again. Thanks, I guess : )
Mikulas Dite
A: 

Let me sugest this:

Create a pseudo aleatory number algorythm (Type Google to find thowsands) and create an array with the colors.

You didn't specified the language, byt anyway you can have something like:

colors = [0xFF0000, 0x00FF00, 0x0000FF]

Red, Green and Blue

And you can have something like:

position = fn_random();

draw(colors[position]);

Hope it's what you are looking for...

Let me know!!

Jean Paul
Well someone comented bad... but you could use the pseudo number generator to create the 3 parts of the color,,, each pseudo generator to create numbers between 0 and 255...Learn people some simulation basics... pseudo aleatory number generators!!
Jean Paul
+1  A: 

There are 255*255*255 possible combination of colors that you can do if you generate a random number for each value of RBG.

I wouldn't be afraid of color collision, but if you want to make sure that there will be no collisions whatsoever you will need to record the previous color.

This simple pseudo code illustrates how to avoid some necessary comparisons

if red is not equals previous_red then
  if blue is not equals previous_blue then
    if green is not equals previous_green then
      use this color
else
  generate again
Diones
A: 

Not an answer, but just to share a nice picture of xkcd: alt text

It's not easy to model what constitutes "easily recognizable colors". The euclidean distance of the R,G,B components of a color is a rough measure, but the human eye is not an RGB color receptor! E.g. if a pair of colors has some euclidean distance between them, and another pair of colors have the exact distance between them, you don't really know whether each pair color is equally distinguishable, unless you see them!

Dimitris Andreou
+2  A: 

If you wanted truly random colors, then generating the same color 10 times in a row would be acceptable. To get values that are perceived as random, you have to strip out true randomness.

The easiest way to do this is probably with a cycling index into a list of colors. Say you pick web colors, a list of 216 colors. Each time you want a new color, add a random number to the index, wrapping as needed. To prevent getting the same color, limit random numbers to less than the number of colors.

colorIndex = ( colorIndex + ( random() % 100 ) + 1 ) % 216;

If you do not want a lookup table, then generate HSB colors but limit the hue to part of the circle that does not include the previous color. If the previous hue was 60 degrees, then pick the next hue above 90 or below 30 degrees, for example. You probably want to limit the saturation and brightness to be above 50% or so.

drawnonward