Omnimaga
General Discussion => Other Discussions => Miscellaneous => Topic started by: josh landers on April 28, 2014, 12:55:41 pm
-
As the title suggests, how many are possible, keep in mind I'm only talking black and white, not color!!!
There are 64 pixels in the sprite, two colors, and the name of the sprite is its hex code, so only 16 letters or numbers are needed.
How many sprites are possible?
-
There are 28*8=18,446,744,073,709,551,616 unique monochrome 8*8 sprites.
-
There are 28*8=18,446,744,073,709,551,616 unique monochrome 8*8 sprites.
And there are 2 you can't use (I don't allow you to use them, as I have used them as well):
(http://img.ourl.ca/FLPYBIRD.PNG) (http://img.ourl.ca/SDNDELUX.PNG) <-- I had to ask leafy for this one
...JK, you can use them. :P
-
Now it gets more interesting if you say a sprite only like rotated 90° is the same one as the one before.
-
Or maybe you just divide the previous number by 4 :P
-
but that won't do the whole trick, like there are ones like an X which are unique, and when tilted they are still the same sprite
-
The question is... how many of those sprites are useable? :P
-
Very few compared to the ones that look like random junk. :P
-
Also could Omnimaga write a program that will make all of them, index them and have the hex code foreach? Obviously it would be huge, duh. But that would be cool to be the only site in the world with all 18,446,744,073,709,551,615 monochrome 8x8 sprites possible.
-
Also could Omnimaga write a program that will make all of them, index them and have the hex code foreach? Obviously it would be huge, duh. But that would be cool to be the only site in the world with all 18,7446,44,073,709,551,615 monochrome 8x8 sprites possible.
Are you CRAZY? I asked wolframalpha. You need 37.49 exabytes of data to store those images for 18 quintillion 744 quadrillion 644 trillion 73 billion 709 million 551 thousand 615 8-byte sprites. And that's the smallest part. You need 16 characters for every hex. In ASCII, every character is 1 byte. So that brings the total size per sprite to 24 bytes.
24 bytes * 18,7446,44,073,709,551,615 = 449.9 exabytes.
An exabyte, FYI, is 10 000 000 terabytes.
So unless you want to host the list, have the money, space, and power supply,
No.
EDIT: Because I feel like doing a What-If? XKCD style thing here, I'll put some more things here.
Assuming that Randall's approximation of Google's storage capacity (what-if #63) (http://what-if.xkcd.com/63/) which he gauges at about 15 exabytes is correct, this means you'll need almost 30 and a half Googles to store all this information. If you wanted to put all the information on 1TB hard drive disks (measuring 2x18x10 cm, totally guesstimated that), you would need 449900000 drives. That would take up a volume of 161964m^3, or 43 olympic swimming pools (size: 50mx25mx3m)
I could go on, this is fun, but that's it. :P
-
Actually it's 8 bytes per sprite, not two.
We wouldn't need to store them all. We could generate them on the fly extremely easily, since it's just a 64-bit number. Pass the 64 bit number and a small javascript program could generate it using a small canvas element.
-
I made a tool to do this a while ago:
http://merthsoft.com/binsprite.html (http://merthsoft.com/binsprite.html)
And, of course, TokenIDE can do it, and countless other tools.
-
Actually it's 8 bytes per sprite, not two.
We wouldn't need to store them all. We could generate them on the fly extremely easily, since it's just a 64-bit number. Pass the 64 bit number and a small javascript program could generate it using a small canvas element.
Yes, I know you don't have to store them all. But that's what OP is implying when he says "generates all of them". And I wanted to do some big number crushing :P
-
Actually it's 8 bytes per sprite, not two.
We wouldn't need to store them all. We could generate them on the fly extremely easily, since it's just a 64-bit number. Pass the 64 bit number and a small javascript program could generate it using a small canvas element.
Yes, I know you don't have to store them all. But that's what OP is implying when he says "generates all of them". And I wanted to do some big number crushing :P
Are you sure? That seems awfully large... plus i said that
"will make all of them, index them and have the hex code for each?"
Not generate. Simply spits them out, perhaps on paper... oh wait, thats would probably be the whole redwood tree forest right? ::)
-
Well indexing them and having the hex code for each is the same thing, except if you want to be original and make your indexation not follow the hex code (which you can do but why do complicated ?). And generating them from their index is just converting their index (whether from decimal or hex) to binary.
-
How many 8x8 sprites does it take to change a lightbulb?
Since 8x8=64 pixels, its 1 bit per pixel and there are 8-bits in 1 byte, 64/8 = 8bytes for an 8x8 sprite.
There are compression techniques that can be used however?
-
Since we are trying to get absolutely all sprites, it means that we will get the same probability for ones and zeroes, so no compression possible I guess.
-
I do believe that there was a Cellular Automata project going on for generating useful 8x8 sprites. It was on the old UTI boards i believe.
-
Well it was about useful sprites, not all sprites including garbage ones, so probabilities are probably not the same ;)
Which means compression might be possible.
-
Index of hex codes are the same as a 29991430517935280 worded document
-
Also could Omnimaga write a program that will make all of them, index them and have the hex code foreach? Obviously it would be huge, duh. But that would be cool to be the only site in the world with all 18,446,744,073,709,551,615 monochrome 8x8 sprites possible.
We'd just need to get google to index all of http://www.omnimaga.org/web-programming-and-design/8-by-8-sprite-image-from-url/ :trollface:
-
Indeed. Let's go to Mountain View and sign a contract with them. :trollface:
-
Index of hex codes are the same as a 29991430517935280 worded document
Maybe I don't understand what you mean (because I am French) but I understood this as "Indexing hex numbers is the same as..." but why would one want to index numbers (hex or decimal, they are just numbers) ? Your sprite indexing is just a converter. You give a decimal number, it can convert it to hex and to sprite. You give a hex number it can convert it to decimal and to sprite. You give a sprite it can convert it to hex and decimal.
-
Let me think: 300 DPI on paper that's 8.5"x11" (US Letter Size, same width but shorter than A4 for you metric folks)
300^2 = 90000 Pixels per Square Inch
8*10.5 = 84 Square inches printable per page (approximate, depends on your printer's feed mechanism and print head)
84*2 = 168 Square inches, double sided
90000*168 = 15120000 pixels per paper
15120000/64 = 236250 sprites per paper
2^64/236250 = 78081456396655 papers
assuming 0.000984252 inches thick (.025mm)
0.000984252*8.5*11*78081456396655 = 7185646069593.465 cubic inches of paper
7185646069593.465 / 12^3 = 4158359994 cubic feet of paper
4158359993 / 5280 = 0.028250121258480552 cubic miles of paper
So, in conclusion, probably an obtainable amount of paper, but not a feasible amount as far as cost or indexing goes, and the printer ink will be the main cost anyway.
-
Scale up the sprites and you're doomed. :P
-
Seems like this could help: http://what-if.xkcd.com/59/ (http://what-if.xkcd.com/59/)
-
The big difference here is that we don't need to worry about updates, but the references on ink usage are quite helpful.
-
Idea : hash each website and give it an unique sprite.
-
Ooooh now that sounds like a good idea ! :D