elementh / random_color

⚙️🎨 Rust crate for generating random attractive colors

Hello there 👋

random_color's Issues

Compatibility with palette

• Provide methods to export RandomColor as palette structs.
• Use palette::named

Let the caller choose the random number generator.

Functions and methods that use random numbers should probably have a signature like fn pick_brightness<R: Rng>(&self, rng: &mut R, ...) and then it should call rng.gen_range.

It should provide convenience methods that use some default so specifying a Rng doesn't becomes mandatory.

I think the `seed` function broken

random_color/src/lib.rs

Lines 223 to 228 in 433c62b

	Some(seed) => {
	// do with float
	let seed = (seed * 9301 + 49297) % 233280;
	let mut rnd = seed / 233280;
	(min + rnd * (max - min))
	}

Like in the comment, the calculation should be done with float type, but instead, the code always do calculation with integer type. So the value of rnd in line 226 is always 0, so the generated random number is always min.

Also, the multiplication in line 225 could cause the result to overflow which will panic the program.

::to_hex does not pad single digit hex with leading zero

Consider using fill/alignment feature here: https://doc.rust-lang.org/std/fmt/#fillalignment

to_rgb_array should return [u8;3] instead of [u32;3]

RGB values are always in range of 0-255, so it would make more sense to return [u8; 3]. This would make it also easier to pass the returned color to other APIs / crates that expect u8 values.

random alpha documentation

I was looking through the code and spotted that random alpha values are generated if alpha is None. Currently the only way to do that to use struct initialization like so:

let color = Color {
    alpha: None,
    ..Color::new()
};

I think this functionality should be noted in the documentation somewhere.

I expected ::to_hex to be #rrggbb but it is #hhssbb

I'm fairly certain must users would expect rgb as well. it is what the browser uses as well

https://www.w3schools.com/colors/colors_hexadecimal.asp

Rng.gen_range called with low >= high

It's look's like where is a problem with this function. In some case min and max are equal and gen_range create a exception.

fn random_within(&self, mut min: i32, mut max: i32) -> i32 {
        if min > max {
            std::mem::swap(&mut min, &mut max);
        }
        match self.seed {
            None => rand::thread_rng().gen_range(min, max),
            Some(seed) => {
                // do with float
                let seed = (seed * 9301 + 49297) % 233280;
                let mut rnd = seed / 233280;
                (min + rnd * (max - min))
            }
        }
}

Reusing a pre-seeded instance should return new colors

I'm creating an instance with a .seed(0) because I want to get random colors, but I want the sequence to be consistent between reruns. This is what seed is usually leveraged for in regular PRNGs.

However, in random_color instance it seems it creates a new random number generator on every call, which means that it will always return the same color on subsequent invocations.

Example:

let mut random_color = RandomColor::new();
random_color.seed(0);

let color1 = random_color.to_rgb_array();
let color2 = random_color.to_rgb_array(); // returns same as color1
let color3 = random_color.to_rgb_array(); // same again
...

thread 'main' panicked at 'Rng.gen_range called with low >= high'

Inside of random_within, there is no guarantee that min is < max and that's a requirement for rand::Rng::gen_range.

So, a random call to random_color has a chance of a panic.

Feature request: Make color_dictionary module public

It would be nice to have more control over what colors are being generated. Right now, this is impossible without access to the module containing ColorDictionary type.

Seed values greater than ~230k cause thread panicked at 'attempt to multiply with overflow'

extern crate random_color;
use random_color::{Color, Luminosity, RandomColor};
fn main() {
let color = RandomColor::new()
.hue(Color::Blue) // Optional
.luminosity(Luminosity::Light) // Optional
.seed(260_000) // Optional
.to_rgb_array(); //
}

Causes a panic in random_within. I'm very new to rust so I'm not exactly sure the best way to handle this. usize might be large enough type for the random_within calculations that any i32 passed into the function will not cause an overflow.

Thanks for the library