@Aardvajk: It appears logical to me - If I only caclulate one random number between 0 (oh, I might increase the - no need for pitch-black images) and 256^1024 it is much more likely to hit a"good" image then if I asigend 1024 random numbers per image. Latter looks like some kind of generic noise texture. Always. Maybe because of the way how rand() works, but if I generate one randon double between 0.0 and 1.0 and multiply it with 256^1024, I imagine I get better results. Or am I wrong?

@way2lazy2care: As I said, 1024 rnd ops per image is just too much. Encoding it even makes it easier to keep a database of which Images I already genereated. Memory intensive nevertheless, but a lot more conviently (at least to me).

Well I know that double has not that high range. I might fix that by substracting a bias values between 0 and 255^3 or something, and by alway generating 1000 images (random number + i) or something.

By images that make sense, I mean anything that reminds of something. Maybe a deformed low-res head of something that
could be a human being. An icon of a game we know. A possible icon for a game. Some generic gui element like a close button. You get the idea? I am aware that it is unlikely. But using one random instead of x may give me something like this if I for example create 1000 images like this every day and check them.

As I said, this has no professional use rather than to prove that my idea works. My main idea was the in a image like 640*480 with 16mio colors, you can depict everything. Just everything that ever existed, or didn't exist. So by choosing the write value for the whole image, you would get a certain picture. I underestimated the amount of possible images, but with 32x32 256 colours, it should be fine..

My thoughts about the double was just that from 0.0 to 1.0 would contain every picture possible. Of course I don't know how 64 bit (ah, even more, I'd use unsigned - this is going to give some precision, isn't it?) and so choosing enough values would give me some results. There is a lot of space for "errors", +-256^2 would, except worst case where a lot of pixels are set to 255, stillt produce the same image, just two pixels messed up. I could even try to increment a 0.0 double by really small values 100 times per frame (if performance is good enough) and pause if the thing starts to look like something. You know, I don't even plan to use these images (unless I get a really, really cool one), but even if I get an image that looks kinda loke a coin, I'd be really really glad I could even use it e.g. as a screensaver and make it run whenever I don't use my pc.. Nevertheless. Thanks for the advices! I totally agree that using greyscale images would be a good idea if my color implementation fails - e.g. if I get only noise textures in the first week, that is.

You are right that it would be foolish to expect lots of great pictures. It's just.. With some luck, I might be able to get one. I might even be able to discover some sort of algorythm - even though the numbers themselfs will be too high to inspect, there are certainly some kind of relationships - for example, pictures with more than 60% of the same color are not likely giving a good result, so does pictures with a lot of different colors or the same color spread out. Whew, I quess I'm thinking way to deep into this. When I get home on saturday, I'll simply try it out. If it fails, well, I didn't loose anything - the basic render is set up, I just lacked a proper algorythm and a way to store these large numbers.

Really? Keep in mind, I'd not add them up directly, I'd add them [rand*256*i]. I don't know, it has been a while since I had maths and talked about probability theory and stuff, but it just feels natural to me that the whole number behaves differently..? Also, I'm using the rand() method which afaik only gives pseudo-random nunbers, so obviously when creating multiple rands (1024 in my case) there will be some kind of patter). It's really hard to think that both cases are the same.. Can somebody point me out some hard evidence?

Think about this:

It wouldn't be random if there were a difference between creating a lot of small numbers than creating one big number.

Also think about this:

You cannot represent an unlimited amount of pictures using a value between 0.0f and 1.0f simply because numbers are represented with a limited amount of digits. Images that are represented on a computer screen are also limited, so in theory you can theoretically represent all combinations within that limited set using a number between 0.0f and 1.0f, even though it might need incredible huge numbers. Finding the algorithm to map such numbers to all these possible combinations of images is not hard, but it certainly is to find a decent picture within the vast amount of different mappings.

Third thing to think about:

You will by no means be able to compress anything using a method like this.

It may be that I didn't get what kind of imagery you are trying to generate. Even with the limitations I mentioned above, you may be able to get interesting results depending on your choice of algorithm.

@way2lazy2care: As I said, 1024 rnd ops per image is just too much. Encoding it even makes it easier to keep a database of which Images I already genereated. Memory intensive nevertheless, but a lot more conviently (at least to me).

You'll still generate more images than you'll have time to process doing it the long way and you don't have to obfuscate any of your functionality with a stupidly large number. I'm not positive if generating a 128 bit random int on a 64 bit system is any faster than generating two 64 bit big ints, and I feel like converting this super huge int to a viewable picture will be much much slower than any performance gain you'll get generating one random number.