this is interesting. i'm in the middle of developing a service that will provide graphical hashes for information like this. the idea is sketched out here - http://www.acooke.org/hash-icons.html - and i am about 75% of the way through coding an appengine service. if anyone is interested, please email me at andrew@acooke.org (i'm thinking of charging a dollar a month to cover basic costs; first month free to try things out).
i just meant that rather than using the hash as a direct source of randomness, and generating the image from that, it is easier to use the hash to seed a random number generator and use the random numbers from the generator.
maybe it's obvious, but at first i was trying to use the hash directly, and kept being constrained by the amount of available data.
but if you do that in a security-aware context (originally this was for hashing user names, so security was not an issue) you need to worry about how much state the random number generator has. it has to be large enough to cover the minimum of (all distinguishable images, original hash). so if you had a random number with a byte of state, then that would be no good (unless the image was a single grey-scale pixel).
> i was trying to use the hash directly, and kept being constrained by the amount of available data.
Too much data from the hash? It seems like a 256-bit SHA-2 hash could map 1:1 onto a 16x16 pixel icon, giving you 24-bits of color depth per pixel to encode each hash bit in a non-ugly way.
