h a l f b a k e r yWarm and Fussy
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Imagine a 2x2 grid of squares, each of which can be either black or white. It is relatively easy to draw, on one page, all of the possible combinations of black and white squares within the grid. Using a lot more paper, the same can be done for a 3x3 grid. If we introduce one more colour other than black
& white, the same can be done, although the results would fill an average sized book.
Increase the grid size to, say, 8x8, sticking with two colours. It would still be possible for a computer to generate and store every single combination in an archive. The archive would be peppered with little anomalies such smiley faces, simple letters, numbers, and symbols. Basically, every image discernable on an 8x8 grid would be there, along with an overwhelming number of “meaningless” combinations of pixels.
Let us take a large and implausible leap and imagine that it is possible to create and store every possible combination of pixels contained in a 640x480 grid, allowing for 256 colours. This would in theory create a mind-bogglingly large archive. This archive would not be peppered by symbols, but pictures. Not only this, but it would include a representation of every single picture ever taken, seen, imagined or otherwise! Want to know what you’d look like with a pencil-thin moustache? It’s somewhere in the archive. Want to know what a new extension would look like? It’s in the archive somewhere. As are all the holiday snaps you or anyone else has ever taken, along with infinite variations in details such as hair colour, location, people etc. As long as it can be displayed on a 640x480x256 monitor, it's there. Everything.
If you’re about to point out the absurd impossibility of such a feat, I know, I’ve already done the maths. The number of combinations in an x by y grid, with c colours can be expressed as;
c ^ (x * y)
So, in our hypothetical case,
256 ^ (640 * 480)
=256 ^ 307200
…which is not even calculable by any means I know. Also consider the vast, vast amounts of screens of random, meaningless pixels (call them ‘duds’), which would far outnumber the useful pictures.
However, if each combination, when generated, was then compressed to a JPEG, and it could not be reduced to at most 10% of its original size, it could be dismissed at not being a “picture” but a dud. I’m sure there are much more efficient and reliable methods of discerning between a squall of pixels and a picture. Simple rules could be applied, for example if you have a random mass of pixels, changing 20, 50, 100 pixels would not make a difference, so these combinations can be ignored, saving time.
A supercomputer could then wade through billions of combinations per day, ignoring the duds, compressing and storing the pictures. After a period that may be years, tens of years or even centuries, an archive of every discernable image viewable on a 640 x 480 screen with 256 colours would be completed. The time taken to finish would be irrelevant, as the archive would be definitive and even contain images seen after the archive was made, and while it was being made. Again I invite you to imagine the stupendously wide array of scenarios the archive would depict.
Storing the archive would be one problem, categorising the pictures almost impossible. As for actual uses, I can think of few. Simply the thought that every single image that can be created has been created would be enough justification. Simply browsing the archive would be something to behold.
If, as I fear, it will be proven that this idea is impossible, and always will be, then what about a (relatively) miniature archive containing 60 x 60 x 16 colour images? Mozart’s thumb, my left eye, blurred view of Big Ben etc., they’d all be in there.
The Ultimate Gallery
http://www.halfbake...0Ultimate_20Gallery
"A Machine to Create Every Image Possible" [phoenix, Oct 04 2004]
evolutionary design for the other sort of designers
http://www.halfbake...rt_20of_20designers
"nice aesthetic shapes and designs by selection" Not quite the same thing. [phoenix, Oct 04 2004]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
I don't know how possible it is, but there's an awesome sci-fi story in there somewhere. + |
|
| |
Boggled. Completely boggled. (+) for sheer imaginative scope. |
|
| |
<searches archive for naked picture of ...> Aha! |
|
| |
The problem would be finding anything. But it is a nice idea. |
|
| |
Since you'll generate the pictures in a way that each one is different, they don't need to be compressed for storage. Just store the index number of each useful picture, from 1 to 256 ^ 307200. Rebuild a particular picture in real-time when you need it. |
|
| |
in fact, they never even need to be stored, the process can be done on the fly. |
|
| |
Nice idea, a bit like the monkeys typing Shakespere. Even some of the dud pictures would make interesting abstract art. |
|
| |
A group in the 70s did something very much like this. Pixelated version of the monkeys/typewriters theory. The thinking was then that you'd actually generate not just images, but pictures of every written page as well. So it sounded like an even better deal. |
|
| |
This was in a late 70s issue of Omni magazine. Don't know what ever became of it. Couldn't have been much, never heard of them again. |
|
| |
I remember writing a program on an Apple II to do this for an 8x8 two-color grid. Wanted to see how many different possible single character forms there would be. I pushed through the math and discovered that with about 1.845x10^19 combinations, displayable at 10 images a second, I wasn't going to get anywhere. I wrote the program anyway; it was only about a dozen lines of code, and I thought it was cool to have written a program that would take over 58 billion years to run. |
|
| |
[Amos] - (your pardon if I'm messing up your joke) - the index number is precisely the same data as the image itself. |
|
| |
Re: filtering - Just compress all the images into .JPG images; the vast majority of them will be duplicates and you will end up with a far more managable (!) image base. |
|
| |
US GOV'T: We have discovered an Internet image of Scott Phundug together with Osama Bin Laden. As per the USA PATRIOT Act, Phundug can be held indefinitely without bail and without the rights to representation by an attorney. |
|
| |
(Your database will also contain thousands of images of fishbones.) |
|
| |
But why bother generating all the images upfront. If you're interested in the images you can create using random methods then why not just generate the image on the fly. You can always tag them with a bit of text describing what you see and a number representing how clearly you see it. |
|
| |
That way your database grows only at the rate at which people are looking at images rather than storing a whole load of data that may never be used. |
|
| |
Seems redundant with the idea in the first link, to me. |
|
| |
How about simply having a site which can return any possible image file up to the size of the maximum URL length? In otherwords, if someone asks for |
|
| |
http://www.whatever.com/magicimage.psp?47494620103AB387B32348... it would return the file encoded in the URL? |
|
| |
Throwing a bit more math at the problem... |
|
| |
Considering the issue of storing all of the possible images. For the thought experiment, first consider a single byte. I know that there are 2^8 = 256 different numbers representable by a byte; but if I wanted to represent them all simultaneously (as in storage), I need to have all eight bits for each resultant number. Therefore 8 * (2^8) = 2048 bits of storage are required. If I wanted to represent all of the possible 8 byte files (that's a pretty small image [the character glyphs I mentioned before] it could be done in (8*8) * (2^(8*8)) bits (about 1.18*10^21, or 147 billion gigabytes). |
|
| |
Pressing on to a huge file: let's look at storage for all possible 36 byte files. That's (8*36) * (2^(8*36)) = 1.43*10^89 bits. Estimates of the size of the universe range from 10^72 up to 10^87 particles; we are now at the point of needing to store a hundred bits of data on each and every proton, neutron, and electron in the universe just to fit it all (assuming maximum estimates are correct). |
|
| |
(8*307200)*(2^(8*307200)) is left as an exercise for the student. |
|
| |
I'd just like to say that this is a totally awesome idea, and if anyone can come up with the 'real-time' version, that'd be very amusing to paly with. |
|
| |
As far as 256^307200, it is very easily calculatable on my moderately loaded athlon server in merely 1 minute, 30 seconds using BC (which may not be the fastest way ever to do it). The number turns out to be over 75000 digits (the output file is almost 11k 69 character lines of numbers). |
|
| |
2076556729866615810208528111554 ... (75 thousand digits later) ... 656834621362405376 |
|
| |
So if you could make it searchable, effectively, you'd be omniscient. Or no, I guess not, since there'd be no way to discern plausible information from complete fiction. |
|
| |
Why deal with a giant database? Should be easy to create it dynamically. Create a program that takes a number as an input and an image as an output. 0 = all white (# of possible images) = all black. (reads annos again) I know [st3f] mentioned this, but said "random", which wouldn't work if you ever wanted to reference that image again. |
|
| |
Baked. Its called the universe. |
|
| |
[Jamoni]Hahahaha! Deep. Besides, anything that involves so much math must have something wrong with it. |
|
| |
Would this database have equal numbers of "evil" and "good" images?. Would there be more Glad than Sad images? What is the minimum grid size to determine if the universe is more happy than sad. If every image is in it is the universe finite at some level? And last but not least, would the number of images increase as the universe expands? |
|
| |
// Would there be more Glad than Sad images? // |
|
| |
If the criterion for a glad/sad image is a circle which contains in its lower half an arc, then there would be a greater number of glad images as there are more possible arcs that fit the space. |
|
| |