Roku Developer Program

[squirreltown]

Well i don't know from pretty code or even actual, you know - math like EnTerr, but the Barbaric Coding™ way to pull a random light color would be

bottom = 180
color = bottom + rnd( 255-bottom)

[Romans_I_XVI]

"squirreltown" wrote:
Barbaric Coding™

Lol

[dev42]

"squirreltown" wrote:
Well i don't know from pretty code or even actual, you know - math like EnTerr, but the Barbaric Coding™ way to pull a random light color would be

bottom = 180
color = bottom + rnd( 255-bottom)

what exactly is bottom? Surely I'm missing something. Because wouldn't we want to be able to have [255,0,0] etc?

"EnTerr" wrote:

"dev42" wrote:
... but to be able to have random colors that aren't too dark. I couldn't figure out how to do that in RGB.... easily. errr with pretty code! Yeah, that's it.

1. Define
   

   lightness = 0.3*R + 0.6*G + 0.1*B



2. Make sure `lightness` is above some threshold (say 0.5)


3. Rejoyce!

Actually there are 101 ways to do that, for example you can use max(R, G, B), R+G+B, R^2+G^2+B^2, min(R,G,B) + max(R,G,B) etc

Credit goes to @SquirrelTown, who draw my attention to the concept of "lightness", which made me read little on it.

My head already hurts! Make it stop. Make it stop! 😛 But for the sake of actually learning this... where does "lightness" fit into RGB? Is it just one check against a randomly generated color and it if doesn't past muster just regenerate another color?

As y'all can tell, I'm not up to snuff in Color Theory.... so, what's the general opinion about using HSV over RGB?

@ EnTerr - Now that you got me thinking, I'm sure a new more informed google search will yield a ROYGBIV gradient using RGB, huh?

[squirreltown]

"dev42" wrote:

what exactly is bottom? Surely I'm missing something. Because wouldn't we want to be able to have [255,0,0] etc?

Sheesh, all the cool kids use shorthand. O is dark, 255 is light , so just limit the colors to light ones.

         colorarray=[ 255, 180 , 255, 180, 255, 180]
			ecolor = []
			ecolor[0]=colorarray[1]+rnd(colorarray[0]-colorarray[1])
			ecolor[1]=colorarray[3]+rnd(colorarray[2]-colorarray[3])
			ecolor[2]=colorarray[5]+rnd(colorarray[4]-colorarray[5])
			return ecolor

[EnTerr]

"dev42" wrote:

"EnTerr" wrote:
Define

lightness = 0.3*R + 0.6*G + 0.1*B

...

My head already hurts! Make it stop. Make it stop! 😛 But for the sake of actually learning this... where does "lightness" fit into RGB? Is it just one check against a randomly generated color and it if doesn't past muster just regenerate another color?

However you please. But let's say you don't want to get loopy but want a bright color, 0.5 < lightness <= 1. Let's take R and B purely random and bracket G:
0.5 < 0.3*R + 0.6*g + 0.1*B <= 1
0.5 - 0.3*R - 0.1*B < 0.6*g <= 1 - 0.3*R - 0.1*B
(5 - 3*R - 1*B)/10 / 0.6 < g <= (10 - 3*R - 1*B)/10 /0.6
(5 - 3*R - B)/6 < g <= (10 - 3*R - B)/6
Hence

R = rnd(256) - 1
B = rnd(256) - 1
minG = (5*255 - 3*R - B)/6: maxG = (10*255 - 3*R - B)/6
if maxG > 255 then maxG = 255
G = minG + rnd(maxG - minG) - 1

Yeah... you know what? Better "check against a randomly generated color and it if doesn't pass muster just regenerate another color" ;).
"Practicality beats purity"

[dev42]

I'm starting to get EnTerr's math... solve the equation -- in this case the Green component -- to guarantee a color with the desired lightness value.

Now, per the OP topic / TheEndless' comment... which method is better?

[EnTerr]

"dev42" wrote:
I'm starting to get EnTerr's math... solve the equation -- in this case the Green component -- to guarantee a color with the desired lightness value.

Shouldn't it be "solve the inequations"? 😄
But seriously, your stochastic method is better. With cut-off value of 0.5 on average will take only 2 tries and the likelihood of mistake in code is very, very low. Where my inequations may break if you say change the minimum lightness cut-off value to something below 0.4 (i think), it will start throwing negative G-s.

Now, per the OP topic / TheEndless' comment... which method is better?

All and none. Depends on what you need/want. Computers/video do RGB. Humans fare better with HSL/HSV, apparently. Read here https://en.wikipedia.org/wiki/HSL_and_H ... _principle for more. Ignore math, see images on the side - if HSL bi-cone or HSV cone seem more humane for choosing color than RGB cube, you can use that. They all convert to each other, it's not like one covers more colors than the others and includes say, octarine*

(*) If you haven't already, you must read Pratchett.

[Romans_I_XVI]

@Dev42 - I just used that declaring integer % trick to fix another piece of code I have 😄 . I was fading out transparency, sometimes it worked right and sometimes it gave weird results. Declaring integers while doing the math fixed it 😛 .

[dev42]

"Romans_I_XVI" wrote:
@Dev42 - I just used that declaring integer % trick to fix another piece of code I have 😄 . I was fading out transparency, sometimes it worked right and sometimes it gave weird results. Declaring integers while doing the math fixed it 😛 .

Awesome. Glad to be of help!