No, it’s not possible in any languages I’m familiar with. You’re talking about a huuuuuuge number here that is better represented as something like, well, a 1024x768 image.
The number of bits you’ll need to represent 16777216^786432 is 18,874,368 bits, which turns out to be exactly the number of bits in the proposed 1024 x 768 24bpp image. In other words, you haven’t gained anything by pursuing this calculation. It’s like asking whether it takes more bits to store the decimal number 16 in binary or hex.
You mentioned some familiarity with perl so I’m sure you realize there’s no difference in the data itself; decimal, binary and hex are just different ways of describing the same number. A bit-mapped image can be considered a fourth way of describing a number. The 1024 x 768 image you see on your screen is, in fact, just your video card’s way of showing you the number you’re trying to calculate. Rather than taking the bits and turning them into 1’s and 0’s or E’s and F’s, it instead turns them into colored dots in a grid.
Consider an image consisting of a single pixel with a 24bpp color depth. There’s no way to represent that in less than 3 bytes, since each pixel, by definition, takes 24 bits. These bytes could be anything from 00/00/00 (a black dot) to FF/FF/FF (a white dot) or any R/G/B combination in between.
Now add another pixel and you’re up to 6 bytes. This could be anything from 00/00/00/00/00/00 (two black dots) to FF/FF/FF/FF/FF/FF (two white dots). We’ve got two dots so far and we’re up to 48 bits. Keep this up for 786430 more pixels and you see where this is going.
This assumes you’re attempting a full lossless representation of the image in question. There are compression algorithms out there to reduce the amount of storage required for repetitive sequences, but that’s what JPEG and the like are there for. If this satisfies your need, you can download a freeware compression library and avoid the hassle of reinventing the wheel.
Incidentally, I think you can do it in considerably less space if all you want is “fairly decent resolution image of everything and everyone ever born, or to be born”
Your method calculates all possible bitmaps. Not only are bitmaps the least efficient way to store pictures, but you’d also be representing every possible animal, object, and ‘random static pattern’, as well as “gazillions” of images of each posssible face (at every possible size, orientation and background) There are about 3/4 million dots on a 1024/768 screen, and though you didn’t specify if the picture would B+W (1-bit per pixel) 256 colors/grays (8-bits per pixel) or an even larger palette, a bitmap of that size screen would typically be 786kB - 2.25 MB.
A JPEG can provide all possible “decent quality images” in, say 100-250kB (arbitrary numbers) because the JPEG compression algorithm is geared to preserving contours and other visually significant features. A JPEG this size would be terrible at detailed images like fractals or random static, but this is a benefot in your case. The lower the file size (i.e. higher compression factorI at a given resolution, the more you’ll limit the universe of possibilities to general patterns and “object like” images, while all but the tiniest of fraction of all possible bitmaps are simply elaborate static patterns.
For human faces, you should be able to perform the function with far fewer possible permutations using eigenfaces - a coding system that incorporates knowledge of how human faces are constructed, and uses this knowledge to decompose each possible face into a base face plus eigenfeatures. It’s meant to make face recognition computationally practical for routine use, but you could just as easily use it to encode and store all ‘possible’ faces (I’m not sure how it’d handle the Elephant man or a Picasso-esque birth deformity) in far less space. Essentially, the encoding narrows the possibilities to only those images that are “face-like”.
Once you settle on a specific size for your eigenface files (say 20k or 200k) the number of permutations is simply 2^[bit size of file] I haven’t looked into how efficient the currently used file format is. Research projects often use text-based file formats for readability and expandability as they change their programs, when binary formats would do the same in far fewer bits. Postscript is one common graphics format that’s stored as easily modifiable text.
I realize that using a bitmap is a bit ineffecient… but like I said, I’m a purist. I wouldn’t want to fake it. I have already written a (very slow) script to generate randomly colored pictures, but I was looking for more of a way to identify pictures by a specific number, as opposed to something like “Image 289571245, found on Dec 31, 11:04AM”… but perhaps I’ll do that instead… make it less of an equation and more of a manhunt (har!).
In essence, you are using the file’s contents as a filename.
That’s about as inefficient as you can get (once you know the name, you don’t need the file at all), but it does have certain benefits. Of course, I’d say it really makes it more important to use a short file. Otherwise, you’ll end up like Shanks - spending years of your life writing down the digits of a single number and having someone realize that you made a single mistake along the way that rendered 1/4th your digits wrong.
I don’t think that your “purism” is impugned by choosing to use one unambiguous format over another. A compressed format may lose some detail compared to bitmaps, but any one JPEG is still exactly the same picture every time. In math terms, it’s lossy, not fuzzy: you get the exact same approximation every time. A fuzzy format gives a slightly different approximation every time, but even ‘fuzzy’ is quite useful. A videotape (or anything analog) is fuzzy, and never yields exactly the same result twice (think Heisenberg) but we consider analog data and storage accurate enough to be fairly definitive.
On the plus side, bitmaps are so redundant that a single digit error won’t visible damage the picture under discussion.
Just don’t forget that you BMP collection would include, not just every possible face, but every possible photo of EACH person, place or thing that can, has, or will ever exist - including ALL pornographic images. Or is that your real plan? “Working on your data set again, honey?” “Yes, genius is a relentless burden.” “It sounds very hard. ;-> Should I send down a sandwich and a beer?”
On the other hand, sales of abridged data sets could be brisk.
