What is Digg?145 Comments
- sameerb, on 10/12/2007, -8/+89Im sorry, it was 3 in the morning and english is not my mother tongue :(
- Lorian, on 10/12/2007, -2/+53orangemarmalade: You clearly don't know what you're talking about.
- blastradius, on 10/12/2007, -6/+45For simplicities sake, let's take the square root of the number of bits in 450 GB.
sqrt(3 865 470 566 400) = 1 966 080
So we will assume he has to print 1 966 080 bits across and 1 966 080 bits down.
A standard 8.5 x 11 inch piece of paper is 216 mm x 280 mm.
Give all this each pixel would have to be 109.863281 nanometers x 142.415365 nanometers.
That's currently much finer than any printer available on the market. By a long shot.
Not to mention the impracticality of paper. A single smudge or stain, and enormous amounts of data would be lost. Heaven forbid you fold the paper and slip it in a pocket. - cwcheang, on 10/12/2007, -8/+41@blackjack75
It's not like
"Im sorry, it was 3 in the morning SO english is not my mother tongue :("
stop being a jackass - geminitojanus, on 10/12/2007, -5/+36" * How did he make his paper disk?, though the reporter missed to ask this question directly, it seems he used some sort of printer (laser or inkjet). So if we take the best printer available and print a try to print a digital photo with such a high resolution that it s size is 450 GB, will you be able to print that with out loosing its resolution?"
A piece of paper would be more than adequate. We print more accurate images on cotton flax (money). Thin films would work better, but it's best to KISS until you've got the bugs worked out. With paper, you can prototype the system in a lab, instead of needing heavily specialized equipment for thin film processing.
" * Even if a printer is able print at that high resolution, the paper is made of fibre which has uneven surface, think about your CD or DVD being rough like paper, will the drives read it. When you want to store such a huge amount of data, even micron level of difference do matter."
No, the differences in the paper at that level doesn't matter as much as the color of the paper being uniform. Take a piece of paper, stick it in your scanner at home and scan it at 4200 DPI. What you're looking for here is the difference in the colors; as long as the paper is more or less uniformly colored, the channel is clear, and good for writing data to. This system wouldn't be much more advanced than that (10,000 DPI+ isn't reasonable yet, but soon could be).
" * Some people where suggesting by using different colours one can squeeze in more data, but what about error tolerance then? This guy is questioning the fundamental reason why digital / binary technology became popular, its because its either 0 or 1 , so its mostly fool proof, we could have used different voltages and instead of binary use 0 1 2 3 4, but then it will not be fool proof."
Using colors doesn't change the error tolerance of the medium. Essentially, using different colors is the way we cram more data into a fiber optic cable (by changing the wavelength of light we pulse through the channel, we can send more data). Because our photosensors only respond to R, G, and B independently, black and white is actually wasting the capabilities of the system. Simply by diversifying to color, we increase the channel carrying capacity by 3 times. Using more specific color sensors, we can increase that further. Your delusion of the system needing to be "fool proof" is what's throwing you off here; we don't need to be that precise when we're looking at colors. Even using a system with one drawn symbol and 12 colors, (which just gives us 4 different states in each of the colors), we can store 12 states per dot, meaning we can store more than three bits of data per dot (but then we have to worry about the sensor being able to pick up that single dot, which is why we use more than one dot).
" * This guy is claiming he used circles and triangles to store data, so for circle he has to use 3 co-ordinates , that itself utilized 3 bites."
Why does a circle need to use 3 bytes? I'm entirely confused here. Imagine a font table, 8x8 characters, 12 color states per pixel. Using that font table, we can generate 8 * 8 * 12 (768) different possible states. The problem is, if we want to reinterpret those states, our sensor technology needs to be perfect. So we knock it down to fewer states. While we lose theoretical capacity, we gain clarity in our signal and build in the necessary error detection/correction. So we define 20 symbols or so instead. This makes the OCR system less complicated, which makes it faster (in trade for capacity).
"* Barcode companies did their maximum when they tried to develop 2 D barcodes and the maximum they could get was around 2000 bytes of data!!"
Barcodes need to be read in a less specialized environment; inside of a cell phone, the barcode has virtually no chance of being damaged, and thusly can be more complicated. Out on a store shelf or in your wallet, it's going to become much more damaged, much more quickly, and thusly needs to be simpler. But, as it turns out, the two are orthogonal goals; barcodes don't need to store very much data (a 32-bit number is more than enough 98% of the time), and this system needs to store gigabytes of data.
"* These types of scams happen regularly in India, a guy claimed he got alien cells from rain, someone developed gasolene from leaves in started selling it in large quantities"
Well gee, because it happens a lot, we should ignore everything they do and not use the scientific method to try and test the ideas?
Nowhere in that whole tirade do you once attack his algorithm (data to reference data table to printer to OCR to reference data table to data), or even ask the right questions (What kind of symbol language did he use? What was the DPI of the printer/scanner? How scalable does he believe the solution to be or does it only work at this density? How durable is the ink to light and repeated scanning?). You didn't even introduce useful data towards drawing conclusions yourself (such as a 600 DPI image on 9"x11" paper, scanned in at uncompressed 24-bit RGB consumes about 100 Megabytes of space, or make a comparison for DPI to symbol usefulness), nor introduce any scientific evidence debunking the invention (such as the signal densities of a Latin language (letters) vs an Asian language (syllables) on printed paper at a standard font size).
Lastly, I'm not going to claim that I absolutely know that it isn't a hoax, just that from reading his research that he's published that it shows promise. As I mentioned earlier, it is very incomplete, and without the whole picture, it's doubtful to the whole package's credibility, but, because we have the Scientific Method and are reasonable people, we can reproduce the experiment for ourselves and attempt to measure how close we can get to his claims, then, as scientists approach the community and say what we've found. If I were a computer scientist, I would love to take on such a project (hell, as a Computer Engineer I'd love to take on the project, but simply don't ever have the time), as it's challenging, and conceivably very profitable. - boyinuk, on 10/12/2007, -7/+37Let's remember that 8.5"x11" is NOT an international standard. Chances are, in India, as with the rest of the world, they were using A4, 210mm x 297mm.
- sameerb, on 10/12/2007, -5/+35I just found that I have met this guy 3 years back, he has no background in Hardware, he is a librarian, he was working with digital library in an instituition called IIITMK, I shall update the blog as I find more information.
- mikaelc, on 10/12/2007, -1/+16The Koran at gutenberg.org is 409KB (Zipped).
So you are still more than 1.000.000 times short of the 450 GB claim. - rm999, on 10/12/2007, -5/+18What it comes down to is no printer is capable of the precision to get that kind of capacity. Here is my estimate of the *maximum* informational capacity of a sheet of paper using a 600 dpi printer:
8.5*11 = 93.5 square inches
600*600 = 360000 dots per square inch
33660000 dots per sheet of paper
16 million colors per dot = 24 bits per dot
807,840,000 bits total = 100,980,000 bytes total
100 megabytes! This is a theoretical maximum, i.e. there is *no* way you can get more data into a sheet of paper. - devindotcom, on 10/12/2007, -3/+16Yeah, my main issue was, what kind of printer exactly has the capability to print such a fine pattern that 256gb can be put on 8"x11"?
The colors thing wouldn't be so hard to get around;
white=0
black=1
red=00
blue=01
green=10
yellow=11
etc. - richIsBored, on 10/12/2007, -5/+16Almost all of his points are applicable in terms of a conventional medium where data is represented in 0's and 1's. Of course in that context density matters because each token can only be one of two values.
But when you're talking about storing data on a sheet of paper, it doesn't make sense to limit yourself to dots of black ink. Nor is color tolerance an issue if you limit yourself to a select range of colors.
He references barcodes but you have to remember that barcodes are old tech. Certainly we have scanning devices capable of distinguishing color. I know the flatbed I have in the corner claims to be capable of it.
He also tries to address the issue of shapes by saying that it takes more data to print a circle than you could store under the assumption that a circle represents some minuscule value.
Forget trying to come up with an argument for or against it. I wanna see someone do some hard math and tell me what the probability is.
How many bits are in 450GBs? How many shapes and colors would you need? How small would you have to print them? Could you overlap shapes? Can you rotate shapes? Ect, ect, ect
It's a much more complex problem than people are treating it but it doesn't sound impossible. - geminitojanus, on 10/12/2007, -5/+15@fear: That's the most credible analysis towards debunking I've seen yet, which is sad to hear.
@ass: Encoding.
Encoding is the process of making one piece of data look like something else, making it easier to transfer in any given channel. For radio waves (including light), it's sometimes quadrature encoding, frequency or amplitude modulation. But for thin films/paper, it's not been very widely explored. Some companies started developing the technology, and because we are the way we are, we evolved the technology instead of stepping back and wondering what we learned.
For films, the industry took linear tape, something they could very well understand, something they've been doing for 30 years at that point, and made it more compact. Instead of winding the tape around a spool, they wound it around a disk. And instead of using a physical tape, they used a single piece of film, just like a record, only much, much smaller. To increase the density, all they needed to do was shrink the tape, or add another layer of film (possibly at a different wavelength). They use an encoding method (Reed-Solomon encoding) to make it more resilient to errors (as the film itself is very likely to be damaged just by ambient light, then the protective layer can be scratched, etc).
Stepping back to this technology, because we're not as worried about errors, and because we're looking in two dimensions, we can take new approaches to storing the data. We can overlap images made of two dissimilar colors and using OCR, take them back apart in software, and convert the symbols into data. We can use the colors as one dimension of the lookup table, and use the shape in the second, making a matrix of possible data values. Our limitation then becomes our printing and scanning technologies. Since scanning is better than printing right now, we can oversample the scanned data and in software, throw away errors. That puts the load of the entire system on the printers; the more densely you can print the data, the more data you can theoretically store with this technology.
Using thin films, we can print very small images; 10nm deep by 100nm wide by 300nm long pits for CDs (0.012 cubic inches), even smaller for DVDs. But, because we're moving in 2D (printing), we can be more precise than that. The depth might not change, but the decrease in length alone to 100nm x 100nm improves your density by a wide margin. Using paper, we can do a similar process with inks (though we typically don't measure ink droplets in nm).
So, using the above, all we can say is that we need more information about his specific process, how well the encoding scheme works, if it only works for MPEG data or ASCII data, or if it works for reproducing any possible byte sequence. We need to know how specific the encoder is to colors and to shapes, and how accurate the developed OCR system is to both. - fearofcorners, on 10/12/2007, -4/+13He's talking about 450gb on a normal piece of paper? 450/8.5/11 ~= 4.8gb per square inch, so sqrt(4.8) ~= 2.2 gb per linear inch. Generously assume you can store data as a solid block of pixels, and you can store 1 byte per printed pixel via colour. That means you've got to print at 2.36223201 * 10^9 ppi. That has to be at least a hundred thousand times more detailed than current printing/scanning technology can handle.
I know his methodology isn't that simple, but this still casts a little doubt on his claims. - exodii, on 10/12/2007, -14/+22You people don't understand about data compression.
In this age of hard drives and such, it's easy to throw around the phrase '256GB of storage', but let's consider what that really means. I'm a math student, so you can trust me on this.
An average 200-page book holds about 500KB of information -- uncompressed. 500MB would be 1000 books, or about the size of a library. 250GB would be five hundred thousand books worth of information, or about 100,000,000 pages.
The best loss-less algorithms in existence can probably compress that information to 20,000,000 pages. That's it. That's the limit of current technology as we know it.
Now, let's assume that this person has a printer that can print at a bit density of 1000 times normal printing (that's a wild, impossible assumption, folks!). Then we'd get 20,000 pages. Now, lets say that he has also come up with some trick to compress it 20 times further (!!!!- such a trick is the wet dream of many computer scientists out there!). We'd still be left with 1000 pages.
Yet this person has claimed to have compressed all that data onto one page. Does it sound impossible?? Hell yes!
Now, let's look at it at another perspective.
An average movie that you watch on you tube may be somewhere around 2MB per every minute. Note that this is optimized for performance. A 45-second movie would take up about 1.5 MB of space. Not 256GB. Not even remotely close.
In fact, simple math tells us that 256GB would be able to hold 2,100 *hours* of movies.
Did you know there are hundreds of competitions and millions of dollars worth of prize money to be given to anybody that can (losslessely) compress data just 3 times better than current algorithms?
Am I supposed to believe that this guy invented something 1000's of times better than what the collective knowledge of everybody in the world has dreamed of?
Nah. Not until I see some real proof and not three paragraphs on a bogus news page. - netdroid9, on 10/12/2007, -12/+20What if you used colors? Instead of black (0) and white (1), you could print it in 256 colors. Each color could correspond to a byte. I'm pretty sure a scanner can scan in over 256 colors without too much error. To prevent errors induced by folding you could mirror the data, but laminating it with some kind of thick, nigh-unfoldable laminate would probably be more efficient.
I've got no idea if it'd work, but it seems plausible. - noreturn, on 10/12/2007, -11/+20You guys are missing the point. Think of it this way:
Binary: 2 ^ 20 = 1,048,576
Trinary: 3 ^ 20 = 3,486,784,401
So, lets take 2 colors (red and blue) and maybe.. 3 shapes (circle, square, triangle). We have 6 different combinations which means that:
6 ^ 20 = 3,656,158,440,100,000
Now, it's becoming clear that by using shapes and colors instead of 0's and 1's, you can store data much more efficiently. One symbol can mean 6 different things. Two can mean 36. You don't NEED high density. - toomuchgreentea, on 10/12/2007, -5/+13C'mon people ... you have to realize that even though in theory color can be infinite, there are limits in what optics (lens) and detection (sensors) can do these days. I'm sorry to bust the bubble, but this "256Gb of data on a sheet of paper" is a scam.
- UltimaNut, on 10/12/2007, -2/+9"He never claimed to compress anything, just encode it. "
I lol'ed - geminitojanus, on 10/12/2007, -4/+11Sainul Abideen: 0091-98950-81493, Res: 0091-494-2495493, email: mysainul from (SPAMDEFENSE) yahoo. If you can get through to him, he seems to be pretty generous with bits and pieces of information (but like I've said, not very complete information).
- rm999, on 10/12/2007, -2/+8a 6000 dpi printer would have 100 times the resolution per given area than 600 dpi = 10 gigabytes of maximum storage.
Notice that this still falls short of a DVD's capacity per area (which is also much more reliable than paper). - WomunOfColour, on 10/12/2007, -2/+8How was the red rain a scam?
http://en.wikipedia.org/wiki/Red_rain_in_Kerala - mrASSMAN, on 10/12/2007, -1/+7Yeah I've been wondering about that too.. also the fact that the data relies on 3 different shapes rather than two (which would make it binary), didn't make sense to me. Also, I can't imagine that a scanner could even distinguish between the shapes (which must be densely packed) accurately enough to produce a method of data storage. Basically none of it made sense and using simple blocks of color would be much more practical and very possible (but still not 450 gigs worth).
- spliznork, on 10/12/2007, -4/+10Scanning an A4 page in 24-bit color at 1200 dpi (sorry for mixing units) produces about 400 megabytes of uncompressed data. The method of encoding onto those pixels using shapes or colors doesn't matter -- 400MB is the upper bound on the amount of raw data that can be encoded onto the paper.
- eee333, on 10/12/2007, -0/+6Apelnago, you are wrong:
137775330 dots and 48 bits per dot = 137775330 dots and 281474976710656 possible values for each dot = 281474976710656 ^ 137775330 combinations = (2 ^ 48) ^ 137775330 combinations = 2 ^ 6613215840 combinations= 6613215840 bits (not 2^6613215840 bits) = 788 MB - mindinhand, on 10/12/2007, -0/+5I like this research because it has fueled lots of brainstorming.
450 GB ~ 10 *4.7 GB ... about the storage of 10 DVDs.
So, this means that one needs to store the info of 5 DVDs on one side of A4.(5 Dvds on the backside as well)
Just thinking that if you laid out four Dvds to cover a piece of paper,and smashed the 5th one to small bits so that it will fill in the gaps, it would pretty much fill in an A4 sheet of paper.
So how do you get DVD level storage from paper? I think its a cool concept, and I hope that people continue to explore it.
I bet geeks would be interested if one rephrased the article as...
During a google interview, they ask- whats the maximum amount of data which you can store on a printed piece of paper?
And then they heard...one google employee came up with a sceme that gave us 450 GB. People would believe it. - sfacets, on 10/12/2007, -7/+11Hey I'd be willing to give the guy a go, if it is in fact true that he can store all that information on paper, then he deserves to be heard out.
- thedalek, on 10/12/2007, -0/+5"256 shapes X 512 color depths = 131072 bits per 'cell'"
Um... No. 256 * 512 = 131072, sure, but that's the number of possible shape/color configurations, not the number of bits per cell. The number of bits per cell would be 17, the number of bits required to represent 131072 possible distinct states.
1200 * 1200 = 1440000 dots per square inch.
1440000 / 9 = 160000 cells per square inch.
160000 * 17 = 2720000 bits per square inch.
2720000 / 8 = 340000 bytes per square inch.
340000 * 8.5 * 11 = 31790000 bytes (30.31 megabytes) per letter-sized sheet, assuming you print all the way to the margin. If you chop off .25 on each of the four edges, you get 28560000 bytes (27.23 megabytes) in an 8 * 10.5 area. - Crowforge, on 10/12/2007, -0/+5I didn't even need to think this out, it's a dumb idea even if you could do it. just sitting on the shelf paper yellows and gets brittle and oh yeah smudges. Ink blurs and color bleeds
- gerryk, on 10/12/2007, -0/+5Until you realise that your red pixel is only one quarter the wavelength of red light in length/width. In other words, invisible.
- geminitojanus, on 10/12/2007, -7/+12He never claimed to compress anything, just encode it. The "compression" is from the idea that we're making something smaller (physical compression), and somehow you're transferring that to decreasing the size of the data (digital compression). The two are completely different concepts; we can make a gate in CMOS that's >1 micron across, or we can make on that's 45nm across, but the two gates could perform the exact same task.
We've known for years that using a very small, thin needle we could theoretically write the Library of Congress on the head of a pin in atoms, this is actually *wayyyy less* dense than that; dense enough that you'd probably need a microscope or really good eyes to read the data if you were attempting to with your naked eye, but not dense enough that it's completely unreadable. - inactive, on 10/12/2007, -0/+4@thedalek
Yep, you are correct.. I was about to add a correction statement, but you beat me to it. I just redid the calculations and based upon my 9 pixel cell, only 0.029GB of data would be possible on a page. In a free-form method, only 0.14 GB would be possible assuming zero margin.
If the numbers are run using 9600DPI which I doubt would be feasible reliably, they are still nowhere near 256 GB of storage (only 1GB per page using the 9 pixel cells). Again, adding color depth would also greatly reduce the reliability, so I am finding this breakthrough hard to believe.
Maybe this indian student did the same miscalculation that I did :)
I am not going to cry foul, but I find the breakthrough to be highly unlikely. - sammysnake, on 10/12/2007, -1/+5To point out the most fundamentally flawed idea out of all this is printing bits of data in pieces that are much greater than the smallest divisible unit that we have already. If you are using large shapes to create 1 bit of data that is just absurd. For this size of media and storage you would need to use microscopic dots (or bits .. hmm I wonder how we got that name?) .
The only purpose a shape could possibly justify for is error correction since your using such a crappy medium to store it on.. also possibly of using different shapes to store different values besides 1's and 0's. However the problem is using such large units to represent one unit of data is far more costly than making it as small as the smallest divisible unit available to this printing process. - choibean, on 10/12/2007, -2/+6Several things wrong with this comment:
512 colors = octal RGB -- depending on the printer/scanner combination, it will be difficult to differentiate 8 shades of each color, not to mention combinations thereof. A more reasonable assumption would be maybe 2-3 shades per color, which would give you up to 27 different colors.
You are not being reasonable assuming you can clearly print/scan 256 different shapes in a 3x3 pixel square, not to mention 1200 dpi. We want to achieve reliability in poor countries, and you're just not going to find 1200dpi printers, or 1200dpi scanners.
A more reasonable assumption is 300dpi, and even then you're not going to be able to easily tell the difference between certain combinations easily (e.g. vertical line of 2 pixel vs 3 pixel), unless you're using a dot-matrix printer. I'd imagine a more reasonable assumption is that you should use at least 9x9 pixel squares, and 1 more pixel for border.
Now assuming (300dpi / 10)^2 and 8100 bits per cell, you end up at 7,290,000 bits per sq.inch, and 681,615,000 bits per page which is less than 100 megabytes of data. And that's with the assumption that you can print on every single available pixel on paper. I still think I'm being generous, and we're not even dealing with this junk about circles and squares - inactive, on 10/12/2007, -0/+4Congratulations, you've invented a process that will probably never work effectively that requires a hundred times the processing cost of writing to a disk, thus solving absolutely nothing. Not to mention the software/hardware costs. It's cheaper to buy a disk. There is absolutely no practical application for this.
- ReaperUnreal, on 10/12/2007, -1/+5@kubudubudubuntu
HIgh-ascii characters ftw. - balr0g, on 10/12/2007, -4/+8Scam of scam article of Indian student developing technology to store 450 GB on paper
I'm sure it will make the digg front page - dodgyd55, on 10/12/2007, -0/+4i wish i could of seen a video of it to see how confident he was making up all this crap
- mikaelc, on 10/12/2007, -3/+7@fearofcorners: I believe you should put the 'giga' inside you square-root ( sqrt(4.8G) ~ 70000 ).
Another calculation:
A4 is 8.27" x 11.69" ~ 100 sqr-inches. Hence each square inch should store 4.5 GB of data. (A DVD, btw, stores 329 MB per square inch).
If each pixel is capable of storing 3 bytes of information (say, 24-bit RGB), we need 1.5*10^9 pixels (ignoring the small differences between the 1024 and 1000 factors in the units). Taking the square root of this number we arrive at ~ 40000 dots per inch
es (DPI).
Still, no scanner or printer will be able output or read data reliably at something even close to this resolution. How could they possible? This is a higher data density than DVDs, which require lasers in order to read them. - mmpkidz, on 10/12/2007, -0/+4I dunno, the idea sounds good to me. Because whenever I want my data stored in a safe, durable, foolproof medium, I go with ink on paper everytime.
- ApeInago, on 10/12/2007, -2/+5yeah, specially that nifty 19,000+ dpi scanner they have now.
most off the shelf scanners have a "photo" resolution of "10 megapixles per inch" (about 3200dpi) made for digitalizing negatives... some even have 6400dpi models
also, a standard scanner can do typically 48bits per pixle color... which equates to a hell of a lot more than 512 (wich is like 9bits per pixle)...
heck, with 12bits per pixle (2^12, or 4096), you'd only need to recognize between thee diffrent shapes. and you could be using a 8x8 grid to draw your shapes if you were printed at 3200dpi - jelouguor, on 10/12/2007, -0/+3mistages:
you start grouping simbols with squares of 64 dots (so that is 8*8 dots), what you called area:
"9355500 dots / 64 dots per shape = 146179.6875 shapes (areas)"
But in the next line you take area of other size:
"take 64x64 pixles"
146179.6875 areas * 14336bits represented per area = 250GB
this is not true 146179*14336 bits is 250MBytes - CaughtThinking, on 10/12/2007, -0/+3I think this guy and his friends are now coding Java for American consulting companies.
- rm999, on 10/12/2007, -1/+4kubudubudubuntu
Nope, my computation took those shapes into account. That 9x9 square can hold at most 9*9*24 bits. Shapes are just certain combinations of those bits, and hold no additional information. If anything, constraining yourself to certain shapes will reduce the amount of information you can hold. - Johnnie, on 10/12/2007, -0/+3I can't tell if this is in fact true or not but form an information theory point of view.... the fact that he uses SHAPES indicates that the data compression is not using maximum entropy of the system, which basically means he would not be getting maximum amounts of data per square inch. At least I think a MCA student (is that like Master's in the US?) should know that...
- SETPeterM, on 10/12/2007, -1/+4Correct me if I'm wrong, but doesn't a printer only use one of three or four color for each "dot"? RGB, CMYK, or whatever particular mixture scheme it's using, only leaves a solid dot of one of those primary colors, and the numbers and density counts of those primary dots lead to a perception of 16 million colors (or whatever count).
Assuming I understand that correctly, than the calculations with the highest measures so far, which factor in 16 million colors, are 4 million times too high.
Also, the fact that it uses shapes is irrelevant - no matter how many shapes there are or what shapes are being used, they are still composed of nothing but pixels, and so the information content coded by a set of shapes has to be less than or equal to the content coded by the set of pixels that make up those shapes.
Addendum: http://en.wikipedia.org/wiki/Dots_per_inch for details on my point about DPI and bit counts. - kubudubudubuntu, on 10/12/2007, -10/+13You seem to be missing the fact that he used shapes too, let me show an example if you imagine a matrix with 9pixels for a shape with 16 million colors:
░▓░
▓▓▓ Circle
░▓░
▓▓▓
▓▓▓ Square
▓▓▓
▓░▓
▓░▓ Something
▓░▓
▓░▓
░░░
▓░▓ Something
So 81 possible combinations, multiplied by 16 million colors, and see from that what length of a binary string you could divide in each of those, so one symbol would be an entire sequence 010100010010 wich would be much larger that the printedsymbols and then using each block to create the binary sequence.
Im not good at maths so im not going to try to solve this, but i hope you get my idea =) - inactive, on 10/12/2007, -4/+7Here is my take on what he did based upon other user's posts:
The data is divided into cells. Each cell is 3 X 3 Pixels.
There are therefore 256 combinations of 3 X 3 cells assuming the center pixel is color fixed:
░░░
░▓░
░░░ 0
▓░░
░▓░
░░░ 1
░▓░
░▓░
░░░ 2
...
▓▓▓
▓▓▓
▓▓▓ 256
512 colors should be reliably printable and readable:
256 shapes X 512 color depths = 131072 bits per 'cell'
at 1200 dpi, 400 *400 cells could be available per inch
400 X 400 = 160000 cells per square inch
160000 cells * 131072 bits per 'cell' = 20971520000 bits per square inch
20971520000 / 8 = 2,621,440,000 bytes per inch
8.5 * 11 paper = 93.5 square inches
93.5 * 2,621,440,000 = 245104640000 bytes per page or 245 GB per page
Therefore, 256 GB of storage per sheet of paper should be reasonable with current technologies considering that photo paper has a very fine grain and current scanners and printers can easily surpass 1200 (even 2400) dpi.
Eric - inactive, on 10/12/2007, -0/+3How do you type in so much?
- gfixler, on 10/12/2007, -4/+7That Indian student hates trees! It seems mean to have teased them these past years with the concept of the "paperless office," only to make them the core of our vast, growing need for storage. That said, if it does pan out, and hit the mainstream, I'm buying some IP stock:
http://www.internationalpaper.com/ - world's largest paper company
http://en.wikipedia.org/wiki/International_Paper
http://www.nyse.com/about/listed/lcddata.html?ticker=IP - kubudubudubuntu, on 10/12/2007, -0/+364 dots / shape, 146179.6875
64*64 == 2284 dots / shape == 64 shapes
You would fit a little over 1 mb
64*64 != 146179 shapes -
Show 51 - 100 of 142 discussions
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is