Random RGB values that average to N; or, Pointlessness and Probability(kevingal.com)
kevingal.com
Random RGB values that average to N; or, Pointlessness and Probability
https://kevingal.com/blog/rgb-average.html
3 comments
Cool! I love projects involving colour, because they always have nice visualisations. Would you mind explaining your project in more detail? I'm intrigued by your site! Not sure if it's supposed to be interactive because I'm on mobile.
I haven't looked too much into the general case. You could consider a tuple (R1, R2, ..., Rn) and compute the probability distributions one at a time for R1, R2, etc. I don't want to get sucked into the exact details of how to do that, but I think it would involve some head-wrecking combinatorics in a loop. Then you could do the same for G and B.
Like you implied, this would be slow if you did it 1000s of times. That's why I pre-computed the R probability distribution in my code, which unfortunately would not be applicable to the general case because there would be too many possible distributions (exponential) to pre-compute. To generate 1 set of RGBs, however, I think it would be fine.
Alternatively, you could try a non-combinatorics interpretation. The folks on Reddit (thread linked in the article) suggested a geometric interpretation of the problem, which might work better.
There's also the approach I suggested at the end of my article: compute the number of possible tuples that average to A (one-off combinatorics), generate an index k between 1 and this number, then pass k to a magic function f that spits out the kth tuple. I'm just not sure what f would look like, hehe. It could be a recursive function. Not sure how to write f without having to do the same probability / combinatorics as before. Or looping through all possible tuples (yikes).
I haven't looked too much into the general case. You could consider a tuple (R1, R2, ..., Rn) and compute the probability distributions one at a time for R1, R2, etc. I don't want to get sucked into the exact details of how to do that, but I think it would involve some head-wrecking combinatorics in a loop. Then you could do the same for G and B.
Like you implied, this would be slow if you did it 1000s of times. That's why I pre-computed the R probability distribution in my code, which unfortunately would not be applicable to the general case because there would be too many possible distributions (exponential) to pre-compute. To generate 1 set of RGBs, however, I think it would be fine.
Alternatively, you could try a non-combinatorics interpretation. The folks on Reddit (thread linked in the article) suggested a geometric interpretation of the problem, which might work better.
There's also the approach I suggested at the end of my article: compute the number of possible tuples that average to A (one-off combinatorics), generate an index k between 1 and this number, then pass k to a magic function f that spits out the kth tuple. I'm just not sure what f would look like, hehe. It could be a recursive function. Not sure how to write f without having to do the same probability / combinatorics as before. Or looping through all possible tuples (yikes).
Thank you for your reply :)
When "entering" a pixel by pressing E, the pixel "above", which the user entered through should assume the average of all the pixels below. I thought it would be interesting to have the 16x16 pixels in the lower level diverge from the color of the pixel above when first visited, but they'd still have to average to the original color.
I googled a bit more but couldn't find any solutions, existing libraries or algorithms i could implement.
Maybe I'll try again in a few years, I'll keep the site running in the meanwhile :)
When "entering" a pixel by pressing E, the pixel "above", which the user entered through should assume the average of all the pixels below. I thought it would be interesting to have the 16x16 pixels in the lower level diverge from the color of the pixel above when first visited, but they'd still have to average to the original color.
I googled a bit more but couldn't find any solutions, existing libraries or algorithms i could implement.
Maybe I'll try again in a few years, I'll keep the site running in the meanwhile :)
Edit: Yes, it seems to, instead of generating and summing over RGB, it would be over all the R, G and B values separately.
Edit2: Hmmm, if the number of RGB values is large, the combinatorics involved seem to make it computationally infeasible...
[0] https://qewasd.com/