Slashdot Mirror
256GB Geometrically Encoded Paper Storage Device
jrieth50 noted that a method of using geometric shapes combined with color to store up to 256GB of data on a sheet of paper or plastic. The article says "Files such as text, images, sounds and video clips are encoded in 'rainbow format' as colored circles, triangles, squares and so on, and printed as dense graphics on paper at a density of 2.7GB per square inch. The paper can then be read through a specially developed scanner and the contents decoded into their original digital format and viewed or played."
My question would be how much wear & tear can a sample of this medium stand before it is rendered unreadable? I would highly doubt one would be able to fold it--however it would be interesting to see whether creating a diagonal read/write scheme would protect from vertical & horizontal folds with the proper ECC. I think the plastic sheets could potentially be as robust as discs but would you be able to bend them? I doubt it though if they allowed it, it'd probably end up being more expensive than a disc.
Interesting technology but I'd sure like to hear a lot more of the details of how it works & how it performs before I make a solid judgment on its feasibility.
My work here is dung.
Now it's possible to fold up 256MB worth of data and fly it across the room.
I would love to know which scanner has the ability to scan with such high fidelity.
according to this Indian blogger.
http://itsoup.blogspot.com/2006/11/scam-of-indian- student-developing.htmle nt_developing_technology_to_store_450_GB_on_paper
http://www.digg.com/tech_news/Scam_of_Indian_stud
than 6800000000 dwords?
Copied from digg.com, where there is already a post indicating this is from a very unreliable source. Besides, we can't even get B&W OCR right.
Shouldn't work, really should it? I mean it's all very well saying 'ooh we can get an infinite number of different curves in this finite area', but at the end of the day, you're going to be limited by the resolution of the scanner or printer. But for a given resolution, you can store the most data by drawing arrays of coloured dots (the curves surely have redundant data in them). Which isn't a very novel idea, at all. Maybe I'm wrong. Besides, think of the trees.
The ultimate backup solution. With acid free paper & some stable color inks, you can back up your entire hard drive on a regular basis.
= 88962&d=18&m=11&y=2006
I wonder how... low the data density can go in terms of DPI & resolution and how that would compare to 2D barcodes.
BTW - TFA is really just a summary of this article
http://www.arabnews.com/?page=4§ion=0&article
[Fuck Beta]
o0t!
I expect to see a story like this on Digg, but I thought Slashdot was better than this.
It's a scam.
I dunno who it is
but it prolly is fhqwhgads.
I wiped my ass on a blank sheet, scanned it in and was greeted with the Windows Vista login screen.
What does this bring that normal scanners can't ?
Let's see A4 - 256Gig. Let's say n different colors.
He'd need to store 256*1024*1024*1024*8 = 2199023255552 bits
on A4 = 210 mm x 297 mm = 62370 mm^2 = 2456 inch
That makes 895 367 775 bits per inch. To encode that you'd need 895 367 775 / log2(n) dots. Increasing the number of colors can buy you some leeway, but not that much.
The surface area of such a dot would be 1/30 000 000 th of a millimeter.
Where will you find paper that has surface flaws significantly smaller than that ? No matter what the encoding, you're still going to need it. So this is a scam, plain and simple.
While I'm sure this is very pretty and sounds good, there have to be durability issues with storing all your data on a piece of paper. At least if I spill my coffee over a CD I know it will work again once I've dried it off - doing this with a bit of paper is a little more problematic.
If they can pull it off, it might be a good "Medium term" archive format (in other words, about 100 - 500 years), as there are many many books of those ages.
m ), then there are currently no reliable digital archive systems for long term storage.
p t)
Given that the BBC's Domesday project (data gathered in 1986) needed to be "rescued" by 2002 (http://news.bbc.co.uk/1/hi/technology/2534391.st
On the other hand, the Rosetta Project look like they could get it licked for really long term storage (Example http://www.rosettaproject.org/about-us/disk/conce
"She's furniture with a pulse"
Can we now say again, "Sorry, my dog ate my homework!" ?
2.7GB per square inch would would require a linear data density of 152292 dpi. Neither my scanner nor my printer come within a hundredth of this. The main problem with the printer at such resolutions is bleeding of the inks into the paper. To form the different shapes several dots would be necessary, which would further decrease the effective resolution by an order of magnitude. For example, suppose a 3x3 grid was used to form each character, the article states that there are four different shapes used, yet that 3x3 grid could encode 512 different patterns. Realistically, at 600dpi (giving 360000 dots per square inch), with 3 ink colours (yielding 8 different colours) you would get 360000 bytes per square inch, or 33MB per A4 page - somewhat short of the 256GB promised. You'd also need to dedicate around 25% of the capacity for error correction. This is complete and utter bollocks.
Like tinyurl, but one letter less! http://qurl.co.uk/
2.7GB per square inch, eh?
Alright, that's 21.6 gigabits per square inch.
For the sake of argument, let's say that the printer and scanner can reliably print and scan colour at 24-bit fidelity (which is nonsense, but makes the numbers nice and tidy): 900 million pixels per square inch.
That's 30,000 dpi.
That means you'd have to print and scan pixels less than a micron across. In full colour.
I don't think so.
And I thought those huge floppy disks we used back at school were large....
;)
Sound interesting tho', but those 256GBs seem a bit too much, unless the computer has a massive translation table for those shapes and colors that account for a staggering amount of possible meanings. This is like the mother of all barcodes
600dpi times 8*11 inches makes 32M dots. To get 26GB you need 6500 bits per dot. This gives either an amazing resolution in color separation (as opposed to, say, 32 bits on a screen - maybe 700 different frequencies, each with 10bit separation), or much higher dot density - something like 50000dpi!
So, the paper is cheap - but how exactly do you print on it? Using dyes? Which costs how much? And are created from what?
Exactly.
Let's see, a piece of "letter" paper is 8.5 x 11 inches. Let's see at 600 dpis inch that are 8.5 x 600 = 5100 dots
:-) ) because of real-life equipment limitations in color and dot resolution and of course the
per line or 5100 x 11 = 56100 dots per page. The raw capacity of a common laser printer is therefore a little less
than 64 Kilobytes per page.
The next thing we could do to increase the amount of data is to add the color dimension. Let's say our printer is capable
of printing 256 * 65536 different shades of red, blue and green by putting different quantities of cyan, magenta and yellow
and black ink/toner on the paper _and_ our scanner has the color resolution to discern 65535 different shades on it, each of
the 56100 dots on that piece of paper could be in 256 * 65536 = 16777216 states meaning each of the 56100 dot can store a
distinct 3 byte value. So now we get 56100 * 3 = ca. a little less than 192 Kilobytes of raw data.
I guess however that in practice we would be hard pressed to come up with more than 64K per piece of paper (128K if you're
using double sided paper
certainly required error correction scheme(s).
I still like the idea, though of refining the 2d barcode.
I think they've introduced some kind of compression into their encoding.
Enter the usual mode of operations for people coming up with new "fantastic" compression algorithms. First the present what they've done. Then they're asked to do a demonstration on actual data supplied by someone else. After that they either disappear straight away or say it has a few glitches to iron out and they will be back soon with the sharp version and disappear.
I once heard that Linus has a the complete source code of the 2.6.0 kernel codified in a tattoo in his left buttock.
To distribute a copy he sits on a copying machine and presses the green button. Otherwise this would violate the GPL (or perhaps no, since he is the copyright owner?).
Stop posting stupid stories!
If these "videos" are the kind that I'm thinking of, be careful of the pages sticking together!
"Was it a millionaire who said 'Imagine No Posessions?'" -- Elvis Costello
The blogs proclaiming this to be a scam seem pretty feeble reasoning. But it's not too hard to see if the numbers add up themselves. First let's suppose we have a very fine color printer and a very fine color scanner that can print at say 4096 DPI in RGB with 24 bits of color. And we'll consider an 8x11 sheet of paper:
4096*4096*256*256*256*8*11
this is 24 Million Giga Bits, or 3 Million Gigabytes.
Now he's going to have to redundantly encode this in some error correcting way since paper and color resolution is imperfect. So assume he makes it 10,000 fold redundant with his circles and triangles. that's 300GB just like he claimes.
Some drink at the fountain of knowledge. Others just gargle.
Since most forms of digital media are trumped by paper in terms of how long it lasts, this seems like a great way to archive digital data for the future. This would solve the problem of all our digital information disaapearing from one generation to the next. It's still amazing that paper records will outlast digital ones today....so I'm not sure if this is ironic or just practical...
AB HOC POSSUM VIDERE DOMUM TUUM
This story is a hoax.
Lets just imagine for one second that its true.
Instead of printing this data onto paper, why not just store it loslessly in a bitmap file? After all, printers only have a certain DPI and a certain amount of colours. If you could take this bitmap file and somehow extract 256GB of data from it, that sure would be some cool magic.
I was SO hoping that fax flier senders would start to fax me some pr0n movies instead.
I read some elaborate explanations for why this is not possible. There is a simpler way of showing that this is not possible.
Assumptions:
1 Printing is done using a 24-bit continuous color tone reproduction process
2 Resolution is high. Let's say 2400 dpi.
3 Paper is 12"x24"
This means there are 12x24x2400x2400 = 1658880000 ~ 1.7E9 pixels. Printed at 24-bit resolution. That's about 5GB. In other word, this person is claiming a way to compress arbitrary 250GB into 5GB, losslessly.
That is impossible theoretically. So the claim is bogus.
The entropy rate of arbitrary pixel values is higher than the entropy rate of related pixel values (such as shapes).
Therefore the obvious way gives a better information density.
Therefore comparing against the obvious way is *not* necessarily the behaviour of a jackass, but quite possibly the behaviour of someone who has a grasp of Information Theory.
Time for everyone to borrow Cover and Thomas from their local library, methinks.
FatPhil
Also FatPhil on SoylentNews, id 863
All the "proofs" in the comments that show this is a scam so far calculates how many dots can be printed/read from a piece of paper, and then corresponds each dot to a bit of data. Well, guess what. The whole point of this thing is he's NOT USING DOTS. This may very well be bullshit, but the "proofs" against it are meaningless.
Anyone can "stand up for what they believe", but it takes a very brave individual to change what they believe. - Loundry
OK, so let's assume the printer prints dots of different color. If there are x colors each dot would contain log2(x) bits of information.
Now, the clever encoding of information into shapes would mean that a shape represents Y bits of information using Z dots.
If Y/Z/log2(x) > 1, we would magically be able to have more information on the sheet of paper than we would arrive at doing the DPI*paper area calculations.
On the other hand, wouldn't we also be able use the same magical trick also without the paper? I.e. digitally code all information not as bits but as the digital representation of the shapes? (i.e. achiving the Y/(Z*log2(x)) compression ratio without needing new printer/scanner devices)
I don't know the exact dimensions of A4, but it's similar to 8.5"x11" (at . Suppose each spot of color stores 24 bits of information -- this is really a stretch, for reasons I'll get to below. Normal Xerox paper supports something like 300 dpi of resolution (that is the scale of the fibers of the paper). Then you can store at most 3*8.5*11*300*300 bytes of information on a piece of paper with color coding. That is just 0.025 GB.
Now, one might argue that nice photo paper could do better -- but it couldn't do better than about 1200x1200 -- the resolution of inkjet photopaper. That would yield a factor-of-16 increase, for 0.4 GB.
In practice, you can't do that well at all, because each location on the paper doesn't store 24 bits, it generally only stores one bit for each type of ink you put down. With an RGB ink system you get only 3 bits per location, even with ideal placement. That yields 0.003 GB on normal paper or 0.05 GB on photo paper.
The only way to do better is to increase the number of symbols on the paper (writing smaller) or to increase the information content of each symbol (using more subtle gradations of color). If it were easy, we'd all be doing it already.
You are an idiot because: You ignored the one and only thing he /did/ say, which was that he was doing something differently.
Bzzt.
Encoding data using dots is the most efficient method possible. He has to print the image somehow, and scan it back in again. No combination of triangles and circles can circumvent the resolution limit, which is what is being calculated here.
By showing that the claim exceeds all practical limits of optical resolution (and probably the absolute physical limits), we show that what we have is just another magical compression scam.
He says that he's "doing something differently"; we've proved that what he claims to be doing is impossible. End of story.
Ultimately, the triangles on the paper are really just printed as a bunch of dots. Printing purely a bunch of dots would give the highest data capacity, but would also be highly unreliable - printing triangles give a kind of error correction. Printing triangles may be a novel technique, and may be more useful than all previous techniques, but its capacity is bounded by the capacity of the page when printed with dots.
No matter *how* he does things differently, it is just not possible to get the required density.
But hey, you got to show your ignorance, that's not bad, eh?
!ERR: Signature not found.
Okay, let's look at some math. First, calculate the number of bits that must be stored to reliably archive 256GB:
.426 micro meters = 426 nm
256*1024*1024*1024*8*(10/8) = 2.749 * 10^12 [allowing for 25% extra - error detection/correction]
Now, the area of a sheet of paper in mm^2:
210 mm * 297 mm = 6.237 * 10^4
Let's make an assumption: it would be tough for a scanner to correctly identify more than 256 colors (blues especially are problematic). So, going by a pixel based method, we can store 8 bits per pixel, so the number of pixels needed is:
2.749 * 10^12 / 8 = 3.436 * 10^11
Pixels per mm^2 will therefore be:
3.436 * 10^11 / 6.237 * 10^4 = 5.509 * 10^6
Taking the square root of this figure and inverting will give us the size of one side of a pixel in mm, so:
1 / (5.509 * 10^6)^.5 = 4.260 * 10^-4 mm =
This is smaller than the wavelengths of some frequencies of visible light, therefore a large portion of the spectrum is gone in terms of colors that can be used. Eliminate these colors and you increase density yet again, requiring you eliminate more colours. By the time you get to monochromatic (black white), which you will, the size is smaller than the wavelength of ANY visible light.
So, for this storage density, either you are scanning in ultraviolet light (and printing using an appropriate ink) to get a small enough wavelength, or you have thrown out light all together and you are using an electron microscope as your scanner. (Note - ever see electron microscope images in color? Can't exist unless colorized).
Fairly clever hoax though - if they had stuck with, say, 16GB then it would not have edged into the impossible.
So much for the paperless office.
Extraordinary claims require extraordinary proof. Carl Sagan
Someone should send this quote to all the people who bought into this claim, and reported it. Someone makes a claim, does a "demonstration", and it gets reported as an advance. Didn't anyone in the media (including Techworld), bother to do some background checks? Standard things like checking the credentials of the person making the claim, checking with experts in the field? Apparently not. That would be standard journalism practice, and we know how discredited that is these days!
As has been pointed out here and on other forums, it's a scam. Is it possible to store 256 GB, etc. on paper? Sure it is. There was a time when computer data was stored on paper - punch cards and paper tape systems. Is it likely to be done on the size of paper mentioned with anything resembling today's best technology? No.
An extraordinary claim has been made - and there is no ordinary proof, let alone extraordinary proof. But, I do have a bridge to sell, and I think I see some potential buyers!
Which is what this would have to do - scan markings on the paper that are smaller than the wavelength of visible light. Why do you think the max an optical microscope can magnify is 2,000x, and beyond that you need electron microscopes?
So how many Libraries of Congress amount of information would the Library of Congress contain if each and every one of the pages of books in the library were like this ?
P.S. The calculation has to be divided by 8 to get Bytes from Bits.
So, the upper bound is 72.5 Gig not 579 Gig
You seem to have confused numbers with the bits required to store them.
A 300 dpi scanner with 6 bits each for R,G,B can only encode 300*300*(6+6+6)=1,620,000 bits per inch. At 600 dpi, you get 4 times as many bits. Also, keep in mind that (a) not all paper is created equally "white" which will diminish the required accuracy for storing data, and (b) even if you store this paper as carefully as we in the US have stored the Declaration of Independence, the color quality of the paper will degrade slightly. Sure, acid free and all that, but there will be some color degradation, so I think it's optimistic to even think you'll be able to store 252,752 colors for any significant amount of time. Imagine this: how many bits get altered by a single fingerprint?
Ben Hocking
Need a professional organizer?
Could have sworn I set my default posting style to plaintext, but meh. And in my defense I was battling the lameness filter to get this posted in the first place.
so lets see.
If he uses 3 shapes, and 5 colours, that's 13 possibilities per "dot". For example, Circle, Square, Triangle, Red, Blue, Green, Black, White. All he has to do, s find another 3 permutations, and he has 16 options per pixel. For those of you out there that didn't notice, white can't have a shape, as the paper is white.
If the data to be stored were to be translated into hexidecimal, you can store 1 hexidecimal digit per "dot".
1 Hex digit is equivalent to a nibble, so for every 2 dots you have encoded one byte.
256 gigabytes is 274877906944 bytes. Now, most printers can easily do 1200 dpi. This is linear DPI though, so they can actually do 1440000 dots per square inch. Now, if we assume that we would need at least 9 dots to do all three shapes:
(see the full comment on my blog for the shapes, I had to take them out to avoid the lameness filter, address is http://www.omega.org.uk/)
As shown above, that reduces the shape density to 360000 shapes per square inch, or 180000 bits per square inch.
A4 paper which is almost foolscap has an area of 96.6763 square inches, so we can store, using my methods, 17401734 bytes, so 16 megabytes, much higher than people here so far have been claiming, and using very, very conservative colour choices and resolutions.
While this is an order of magnitude away from the stated values, this could easily be much higher.
I have assumed a very low resolution (laser printers can easily get up to 2000 DPI these days), no compression, and a very restricted subset of values. I should think it would be easily possible to use 8 bit colour, with no risk of data loss.
Add to this 8 to 14 conversion, or parity values, to ensure data integrity, and I think that what this guy is claiming is within the realms of possibility.
FYI, using 8 bit colour which yields 256 possibilities
3x256-3 = 765
765 is almost 3 bytes per dot
using 2000 DPI,
2000x2000 is 4000000 divided by 9 is 444444 shapes per square inch.
444444x3 makes 1333332 bytes per square inch.
so, 128901604 bytes per sheet of A4
which is 128 megabytes per sheet of A4.
So as you can see, it's not a case of "is it possible to fit that much data", it's just a case of howdetailed it has to be; add another shape, and the desity per dot goes up massively,
(see the full comment on my blog for the shapes, I had to take them out to avoid the lameness filter, address is http://www.omega.org.uk/)
maybe?
Is it possible to fit 256 gigs of data on a sheet of A4 with ink?: Yes.
Is it possible to retrieve it?: Possibly, depends how small you go.
If you want precendent, think how small the pits are on a Blu Ray disk are; if we can retrieve a single bit from something that small, can we can surely retrieve something a bit bigger and a bit more detailed.
My maths isn't too strong, so if I've made a mistake, feel free to correct me.
From what I can tell you're using the color information wrong. You divided the number of bits (21.6 gigabit) by 24 assuming a total of 24 colors. But you said to assume 24 bits of colors yielding a total of 2^24 different colors in one dot, right? Doing the same calculations on that numbers gives a 30dpi which is quite possible.
Calculations:
2.7GB per square inch = 21.6gigabit per square inch.
Each dot carry 2^24 bits of information due to color so we only need 21.6*1024^3 / 2^24 = 1382.4 dots per square inch
Square root of that equals about 37 dpi.
I'm not saying that the article might be bogus. It all seems to come down to what color depth you can get on a paper (and doing the correct calculations, so please correct me if I got something wrong). From the posts it seems like the ones that claim this is bogus counts with a very low color depth, like 3 colors or 8 colors. While the ones who believe this might be true counts with a very high color depth, 2^24 or something. I think 24 bits seems a bit high, although I must admit that I don't know anything about that.
... in confusing number of colors with number of bits. Each of your pixels doesn't store 255*255*255 bits, only one of 255*255*255 values (about 24 bits). You have overestimated the capacity by a small factor of 700,000.
Sorry, like the other poster, you have used combinatorial maths where it doesn't apply.
Replace the 255^3 with 24 to get the correct number of bits. That reduces the result by a factor of 700,000.
Oh, and 10^12 is tera, not giga.
So no, not theoretically possible.
You are an idiot because: You ignored the one and only thing he /did/ say, which was that he was doing something differently.
Bzzt.
Encoding data using dots is the most efficient method possible. He has to print the image somehow, and scan it back in again. No combination of triangles and circles can circumvent the resolution limit, which is what is being calculated here.
By showing that the claim exceeds all practical limits of optical resolution (and probably the absolute physical limits), we show that what we have is just another magical compression scam.
He says that he's "doing something differently"; we've proved that what he claims to be doing is impossible. End of story.Indeed. For those not inclined to simple mathematics, here it is in a nutshell-
Assumptions (none of them unreasonable, all of them quite generous even):
1440dpi
8 bit color
8" x 10.5" printing area
Even assuming perfect readability, this resolution yields only 1.4GB per page. Talk of "shapes" is smoke and mirrors to obfuscate one of the cold hard facts of information theory: you cannot accurately represent all permutations of 8 bits of information if you've budgeted less than 8 bits. Compression schemes allow you to compress repetitive patterns is you know they're going to be there beforehand (e.g. an almost arbitrarily large number of only 1's or only 0's can be represented with run length encoding), but X bits of random data requires X bits of allocated space.
If a job's not worth doing, it's not worth doing right.
Ooops. Please ignore this post.
24-bit color of course means 24 bits of information in one dot (being enough to represent 2^24 colors but thats not of any importance). Very stupid of me. So yet again we learn the importance of making correct calculations. Now I to call bogus on this.
24-bit fidelity would allow over 16 million colors. In fact, it appears to me that they are allowing for much less fidelity than that. Assuming a 1200dpi print capability (most modern dot matrix can do better than that, especially on the horizontal) and a 3x3 matrix for the shapes we get the following:
(1200 * 1200)/(3 * 3) = 160,000
160,000 * 4 shapes = 640,000
640,000 * (32 shades (6 bits) ** 3) = 20,971,520,000
Using some of the other print resolutions commonly available such as 1440 DPI or 2880 DPI could easily reduce the color scanner accuracy requirements to less than the 18 bits I assumed here. Note that much of the accuracy requirement could be met without "absolute" accuracy from the color scanner. It merely has to have "relative" accuracy if a small calibration area of known colors is provided. Also, I didn't account for the possibility of having multiple color regions per shape which could further increase density.
Please ignore my correction too. Though it does seem to be a common confusion.
While I agree that 256GB on a sheet of paper is probably a scam, I find parts of the story to be an interesting idea. The barcode is ubiquitious but it stores a limited amount of information. Some specialty codes can store a great deal more information in a much smaller area in black and white (like the UPS scatter code). Adding color and using geometric shapes seems like it could increase density by a factor of three or better (just considering color).
This kind of encoding and scanning probably isn't for everyone. A barcode can convey information that can be stored in a database - so a small amount of data (in essence a serial number) can convey a great deal of information. For inhouse applications, like storing the location of a particular pallet in a warehouse for instance this is more than adequate. But for applications where you want to share information with others outside of your network, a great deal more data may need to be contained - like when providing a lot of steel from a foundary to a manufacturing plant. In this case, you may need to provide a large amount of data to an outside company that you do not want to have access to your network data. Info that goes beyon simple dimension data, stuff like formulation data, lot number, and manufacturing date.
Paper is much cheaper than RFID and has stood the test of time. It is in many ways the ideal medium for data exchange between two entities. It has served this exact purpose for centuries.
He's got the ultimate proof this story is a hoax, hands down. And he did it without juggling a lot of numbers.
It's just Hollerith cards all over again.
Get your Unix fortune now!
Ok, I agree this is most likely a scam or a fake.
But what about the general principle of archiving to dots on paper (be they black and white, probably better lasting, or colour for greater density) as a way of getting around the problem of constantly having to translate our archives into the latest technology (less we be left without a reader or, at best, only one in a museum some where).
It seems to me we'll probably always have scanners and the software to extract the information from an image would probably be relatively easy to write (for different image formats). It seems (at least superficially to me) that scanning is sort of independent of the underlying technology in a way that reading from a tape isn't.
I realise there have been (and are now) paper tape storage systems, I am more interested in getting over the problem of technology going out of date.
Cheers,
Ashley.
No. You've made the same mistake as everyone else. Well, and a couple of other minor ones.
If you have 6 bits per colour (RGB), that's 18 bits per pixel. Not, as you calculated, 32,768. You would have us encode 4Kbytes per pixel.
YOU CANNOT COUNT THE COLOURS. YOU CAN ONLY COUNT THE BITS USED ENCODED THEREIN.
Note: Some bits may be redundant...
(Darn that lameness filter!)
6 bits of color control per color allows for 32 shades of that color to be created. A 24 bit color printer produces 256 shades for each of 3 colors giving over 16 million colors.
I am using metric because this is a question of physics and the wavelength of light. Physics uses metric exclusively. Also, outside of the United States, the world overwhelmingly uses metric measure - and I am not in the United States.
:P
DPI or dpmm, the basic facts have not been altered, nor has the conclusion: a scanner using visible light can't pick up objects this small. Work this out yourself, using your treasured "imperial" measure if you would like - but if you are going to measure the speed of light in "furlongs per fortnight", try to be accurate.
Yes, I wouldn't discount the idea in principle, even though I am quite confident that much of this story is a fake. Playing a movie from a self-built prototype implies quite a bit of bandwidth.
256GB per paper? The next step will be a 3d scanner which scans multiple "papers" attached, and will contain few layers.
Do the math, n layers * 256 while n might be from 2..100 for example!
lets say 10 layers (which shouldn't be hard once you get to do the multiple layers attached) = 2560 GB! per one unit!
The next step is a 3d scanner, definitely.
What do you think of that?
It's not the first time that we hear some kind of hoax like that. Remember the wonderful 100:1 losless video that "superseded Claude Shannon's work", right here on Slashdot in 2002 (or enter "zeosync" on Google for a bit of geek fun) : http://science.slashdot.org/article.pl?sid=02/01/0 8/137246&mode=thread
I believe it was "Dr. Dobb's Journal" that used to publish code that could be scanned, sort of a variant on barcodes.
Printed at the higher resolutions available to printers and scanners 15-20 years later, how much data could you store using that encoding format on paper? We've gone from about 100dpi to 600-1200, which actually means at least 36 times the data storage per square inch.
I fail to see how a binary pixel can fail to take less space than a printed geometric shape. You can squirt an ink dot a lot smaller than you can a recognizable microscopic shape.
Colour filtering to provide "layers" of data is a form of bonding or multi-frequency processing. Even CMY alone triples the storage potential; the colour discrimination of the scanner is the only limit to the potential bandwidth multiplier (plus data loss due to fading.)
In other words, it sounds a lot more original than it actually is. Odds are the creator is too young to have even heard of Dr. Dobbs, much less have played with the code scanners to save typing time.
I do not fail; I succeed at finding out what does not work.
Sounds similar to a system called Softstrip from 20 or so years ago.
l
http://rich12345.tripod.com/museum2/softstrip.htm
Hey guys, remember back in the day when we stored data on paper using HOLES?
I wouldn't be so quick to say this is a scam.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
...the old 'softstrip'(?) barcodes from BYTE Magazine? And wasn't there something in NIBBLE too? Did anyone else here ever use them, and what stories do you have about them?
I remember _finally_ finding an HP barcode wand at a show and hooking it up to my Apple][+. I wrote-up a reader and had a lot of fun doing it and used it to load their programs (ASCII BASIC) - I was surprised at how efficient it was (for the times). It beat the daylights out of cassette storage (couldn't afford a disk drive at that time) and it led me to writing an output application so I could barcode all my work to the printer for storage. Most of those pages are still legible after all these years.
Good times.
"It's time to take life by the cans." ~ Bender ("Bendin' in the Wind", ep. 3-13)
dd if=/dev/zero of=foo bs=1G count=500
gzip foo
uuencode foo
lpr foo
et voila, 500G of data printed on a single sheet.
My first program:
Hell Segmentation fault
Here's an upper bound as a check on your numbers (not restricting ourselves to a small dictionary of shapes). I'll give away the punchline: My numbers agree with yours, but 256 GB is not possible using printers and paper.
Assumptions: I use your printer linear resolution of 1200 dpi, and assume that adjacent pixels can be resolved at this resolution. I also assume that 256 different colors can be distinguished, as you do, and that the paper we are using has an area of 96.6763 inches^2, also as you do.
Calculation: With a linear resolution of 1200 dpi, one can fit 1440000 dots per square inch (Check!), and so 139213872 dots on a sheet of A4. With 256 colors we can store a number as large as (number_of_colors)^(number_of_dots). So:
256^139213872 = 2^N (where N is the equivalent number of bits)
(2^8)^(139213872) = 2^N (recognizing that 256 = 2^8)
2^(8*139213872) = 2^N
N = 8*139213872 (bits)
(and if we just divide by 8 again to get bytes...) => 139213872 bytes = 139 MB
Discussion: This theoretical upper bound is three orders of magnitude smaller than what is being claimed by the article: It is not possible to store 256 GB on a sheet of A4. My result does however agree with your result in that the inequality (my_result)>(your_result) holds, as it should. Ad it's really not too shabby: Accounting for 8-to-14 conversion for some error correction, we can store slightly under 80 MB in this way.
Different assumptions: If I instead use your 2000 dpi laser printer figure, then I can fit 4000000 dots per square inch, and so 386705200 dots on a sheet of A4 and so almost 386 MB. (Including error correction, one might store 220 MB.) Pretty impressive!
The Absurd: Right now, many modern semiconductor fabs have working 90 nm photolithographic processes. That means that the smallest feature size is 3.54330709×10^(-6) in, and the linear resolution is about 282222 dpi. If all we print is the first metal layer, then a dot can either be "with metal" or "without metal" -- that is, one bit. And on a silicon wafer with an area the same as that of a sheet of A4 paper, we can then fit 7700207603555 dots, or 962 GB. Hard drives are about halfway there!
http://www.hindu.com/2006/10/08/stories/2006100800 021100.htm ("last modified" seems correct)
/ cyberspace163748200695.asp (but "last modified" is november 26...)= 165 ... http://img319.imageshack.us/my.php?image=rainbowte chzz4.jpg )
e x.php
:)
"I have achieved storage densities of about 2.7 gigabytes per square inch," Mr. Abideen told The Hindu over phone from Kottakkal in Kerala.
And sooner, in September :
http://www.deccanherald.com/deccanherald/sep62006
(But has been linked by some blogs the 19 September)
http://www.stingygaming.com/forum/viewtopic.php?p
( the photo was on imageshack
I never think to this technology but the better way to discredit it is this kind of re-publication of an imprecise article.
Concepts stay very exiting even if storage place is in the order of the hundred of MB.
About the dot precision, laser printers (Xer.. ?) do some miracles :
http://www.eff.org/Privacy/printers/
http://www.eff.org/Privacy/printers/docucolor/ind
Could you believe that ?!
The first time I read a related article several days ago they were professing something like 450-475gigs not 250. Wonder who's got their story wrong? Some comments regarding those were that it was not possible or even more possible with color coded binary.
You can lead a man with reason but you can't make him think.
Suppose for a moment we have 10" square paper (8.5" x 11") 256Gbits translates to a data density of 2.5 Gbits per square inch. If you have a really nice colour printer you might get 500 dots per inch - so you need to encode 2.5Gbits using 250 thousand dots. So each coloured dot has to store 10,000 bits of information. That's a pretty clever trick for a colour that's only described using a 24 bit RGB value.
So the best you could POSSIBLY do with a 500 dpi printer would be 24bits x 500 x 500 x 8.5" x 11" = 561 Mbits.
But that assumes that the colour reproduction of both printer and scanner are 100% perfect - which they most certainly aren't!
You'd need a 100% perfect 10,000 dpi full colour printer AND an equally perfect scanner.
All the crap about storing different shapes is irrelevent - even using every possible colour of every possible shape/pattern/whatever only gets you to a half a gigabyte in theory and maybe one megabyte in practice.
This is incredibly bogus...total BS.
www.sjbaker.org
The problem there is that books:
A) are very low resolution, so a speck of dust here and there, or even a hole/stain/discolouration here and there, isn't all that much. When you "encode" the letter "A" as a big hand-written letter, there is a lot of space it's spread over. Even without any additional hints (see next points) you could destroy a quarter of that area and still take an informed guess that it looks like an "A". By comparison, the same surface destroyed in this guy's encoding scheme (if it weren't a scam, which it is), you've lost a few megabytes worth of data.
B) have a much higher tolerance to stains, discolouration, etc. If you were to print this message and spill coffee over it, chances are that you could still tell there's an "A" here, because you only have to deal with two colours. If it looks like a darker "A" on brown, it's still the same as an "A" on white. But when you have thousands of superimposed shapes of all colours, a brown triangle on yellow may well be a whole different thing than a cyan triangle on white meant before the coffee spill.
C) writing and human languages have a great deal of redundancy in them, so you can still use the context to guess when bits are missing. If you have a hole in the page and you read something like "ye olde m_nks" you can take an informed guess that it was "monks". You also have the historical context there. If you were to read somewhere something like "N__ths__re Abbey", you could guess that it probably meant "Northshire Abbey", because we don't know any other that fits those letters.
Binary data doesn't have that luxury. By comparison, when you miss about an 1000x1000 bits area (and that may well be less than one square millimeter at this density -- again, if it weren't a scam anyway), even if you encoded each sector with a generous ECC code and stored checksums on each row _and_ column, you're still basically boned. It's not going to repair that much missing data.
D) conversely, writing and human languages have a certain "locality" and contexts only span so far. If the half the page about Northshire Abbey was missing from the Domesday Book, you could still read the next entry just as well. Even if half the book went missing, we could still extract _some_ info from the other half. In binary data, you don't always have that luxury. An exe where half of it is missing, is pretty much just screwed. A Domesday database where one of the normalized tables is gone, may well become nearly useless, depending on which table was lost.
Now none of those are necessarily the end of the world (or not as much as the fact that this is just as scam), because you can store the information repeatedly all over the place, and build baroque structures on ECC on top of other ECC, to the point of achieving the same effect. But by that time, you've lost most of the advantage anyway. And you've certainly lost the advantage compared to using a more robust medium in the first place, and not needing as much redundancy in the first place.
A polar bear is a cartesian bear after a coordinate transform.
In this Digg generation, I've still kept reading Slashdot. The community here feels a lot nicer (surprising, I know!) and a lot more clued up. It's just a shame, then, that idiotic stories like this get posted. Usually I wouldn't whine about a bad story, but it was an hour or two before this story hit that I read the whole "why it's a scam" story on Digg.. so I read how stupid something is on Digg, only for it to be posted seriously here at Slashdot.
It's time for some sort of shakeup with editorial at Slashdot. Digg is imperfect and a lot of the users are idiots (I'd certainly say the average Slashdotter is significantly more intelligent and clued-up) but Slashdot is slow and has a poor editorial process. Could we, perhaps, strive to produce something with the perfect mix of the two? Fast news, the ability to vote, etc, but coupled with the superb Slashdot audience? It's all false hope, I'm sure, but I have more hope in people than technology.. so Slashdot is just the place to bring this up IMHO.
so 16 megabytes, much higher than people here so far have been claiming, and using very, very conservative colour choices and resolutions. While this is an order of magnitude away from the stated values
I have no problem in believing 16Mbytes - but that's not "an order of magnitude away" - he's claiming 250Gbytes. That's FIVE orders of magnitude.
You end up needing shapes that are of the order of 1/10000'th of an inch across (much smaller than the strands of material that make up the paper) and colour precision of around 24 bits - which is vastly better than any existing printer can manage.
Then you need a small scanner that can scan at similar resolutions...also VASTLY beyond any reasonable technology.
It's a scam - the end.
www.sjbaker.org
This guys watched too many episodes of Prison Break. Next season the tatoo will hold the Library of Congress!
There are 2D barcode technologies out there that can store data on paper like that - including a few that use colour.
Picking one at random from the Wikipedia article on 'Barcode': A company called 'MarkAny' (for example) has a 440bytes/cm2 black and white barcode that's actually in common use. That would get you around 200Kbytes on a sheet of A4...it's not 10Mbytes - but enough for an MP3 track.
10Mbytes would be tough - that's 117Kbytes per square inch - which would need (say) 256 unique colours and 350 dots per inch - reliably through both printer and scanner. I wouldn't say it was impossible - but it's pushing the envelope. You could use error-correction techniques to solve some of the ikky problems you'd end up with - but that'll eat into your data capacity.
www.sjbaker.org
Close, but not quite analogous. A lossless bitmap file needs 24 bits per pixel to store color information. Actually printing on paper would theoretically allow you to map 24 bits against a single colored dot, providing a form of compression.
In other news, Sony sure employs a lot of idiots to make its BlueRay drives. They have to use blue lasers, a special medium, and lots of expensive parts to get the same storage density they could have got by having a spinning disc made out of paper and a cheap CCD.
Let's not stir that bag of worms...
Any exposure to light and you are going to start losing data.
You must use light to scan it.
This might be good for storage for under 2 years- can't see it for archival storage unless you greatly reduce the number of colors so fade won't matter.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
I call "Bullshit". Makes no sense. If you encoded every single fiber visible on a page, you'd not have the claimed storage.
First, don't most color scanners scan in true 32-bit color? Second, he's not just using a single dot of color to represent the 32-bits, he's using the color in shapes, which will take many dots (and is probably less efficient than using just a single dot), so I would imagine he's using an even higher DPI printer (my really really cheap printer at home is 1200x1200 dpi). Perhaps the purpose of the shapes is to make the data readable after some damage has been done (imagine a square being recognizable after part of it has been destroyed, a single dot wouldn't be recoverable).
I thought I had posted this before, but it seems as though Slashdot ate my post...
Anyway, information about PaperBytes is available here. They also made a more sophisticated, 2D version of it, PaperDisk (circa 2001). It had a data density of around 140 bytes per square centimeter, or around 84,461 bytes on an 8.5x11 inch page.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I believe it was "Dr. Dobb's Journal" that used to publish code that could be scanned, sort of a variant on barcodes.
Several magazines did this. They used Cauzin Softstrip format. Wikipedia didn't have an article on Cauzin Softstrips so I just added one: http://en.wikipedia.org/wiki/Cauzin_Softstrip
I fail to see how a binary pixel can fail to take less space than a printed geometric shape. You can squirt an ink dot a lot smaller than you can a recognizable microscopic shape.
You also need to take into account the real-world issues, such as fibers in the paper wicking the ink and making your precise geometric shapes into fuzzy blobs. Careful bit patterns, with error-correcting bits, ought to be a lot more efficient than geometric shapes.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
An A4 Sheet?
I could use that scanner to scan all my
vinyl LP's rather then scan in half's
and stitch them together..
Resolving 16 bits of color for a typical four-color (CMYK) laser printer or even a digital press won't improve things, because you always have exactly four colors plus the medium color (most typically white). Increasing color depth can improve with dye sublimation and similar technologies, but the ink and paper quality (especially absorption rate) need to be strictly controlled.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
How big in MB is the TIFF file?
Instead of printing it out and scanning it, why not transfer it on a USB stick?
While I doubt this can be true, imagine if it were. Imagine taking a DVD movie, storing it on two square inches of image, well rather than print the image, save it as a compressed, lossless PNG. 500dpi is a good res for printed material, so a 1x2" image at 500dpi in 16bit colour should be about 300kb, that's great, I've just got a DVD onto a floppy. If that's not small enough, just make another rainbow representing the PNG image, then make a PNG of that, it should be under 1kb. Do this as many times as you need to, even if my resolution of 500dpi is off, we can just repeat the stages a few more times. It is now possible to fit any data onto any storage medium I for one am very grateful to this guy and his team, as soon as youtube start using this compression technology, they will have abolished the problems of net bandwidth too.... YAY!!!
Or if this is true then dowloading a 240gig file will be as fast as downloading a a4 page high def graphic ? I mean if you can store that ammount on a a4 page, then you can scan it, and send it to someone by e-mail and then the person can print it out and get the data. But again, why scan and print, can the computer direcly compute the data from a digital file ? Why is this article about using paper instead of CD?? Shouldn't it be about a new way of storing data in a visual format, who cares what you do with it after ?? Printing and scanning the image containing 240gig of data seems to be so away from the fact that if we can store 240 on a graphic the size of a a4 page, then digital transfer is drastically modifyed... Is't this like the best encryption and compressing technology ever ???? well I might be just wrong also or I just don't get it
Units, units, units!
> (1200 pixels/in * 1200 pixels/in) / (3 * 3 pixels^2 / shape space) = 160,000 [ shape spaces / in^2 ]
> 160,000 shape spaces / in^2* 4 shapes / shape space = 640,000 [ shapes / in^2 ]
> 640,000 shapes / in^2 * (32 shades (6 bits) ** 3) = 20,971,520,000 [ shapes * shades * bits^3 / in^2 ??? ]
My calculation:
640,000 shapes / in^2 * (36 bits / shape[see note]) = 23,040,000 bits / in^2
[4 shapes encodes 2 bits. With 18 bit color, each colored shape represents 18 color bits * 2 shape bits = 36 bits]
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
binary..
now divide that by the number of colors you can discern later
let's say you have 152,292 colors
now only need one dot.
every day http://en.wikipedia.org/wiki/Special:Random
This has been proven to be a scam. It needs to be removed before people begin believing that this is even plausible. http://itsoup.blogspot.com/2006/11/scam-of-indian- student-developing.html
Strictly speaking he could use many colors. The resonable width of color spectrum is around :).
1000 nm and good optical filters will give you a window of 2 nm bandpass, so assuming he used
500 wavelengths/colors he could store 700 Gb per page. Also, I am aware of prototype, in the lab
printers (by Canon) which do 9600 dpi (Google it), so pushing technology to its limits and
cost notwithstanding you could write 31 Tb on an A4 sheet. And I am pretty sure one can make
this work for not much more than a yearly budget of one National Lab in the US
I worked with a classmate to develop a paper disk system more on the order of what has been discussed in this board than what the article describes - dots, not shapes, and theoretical maximum capacity on the order of hundreds of megabytes, not gigabytes. It was essentially a larger version of Datamatrix.
Practically speaking, we were shooting for tens of megabytes: 600 dpi, 8-bit color resolution, 1-inch margins on 8.5x11 -> 600 * 600 dots / sq in * 1 byte / dot * 75 sq in printable area / sheet of paper = about 26 MB, not including error correction.
My classmate put in the error correction which added some 25-33% to the data. We stayed with black and white and never had time to go any farther, but we did get it to work - maybe a few hundred kilobytes worth of some random file.
The unanticipated problem we ran into was skew - progressively increased rotation of the scan lines, a warped scan. To overcome it, we stumbled on the same solution the creators of Datamatrix used - a row and a column of alternating black and white dots used to establish independently-angled scan lines.
We never did do much with testing how rigorous it was; once we got the basic idea working we wrote up the paper and moved on. I believe we intended to keep working on it, mostly to spite the EE professor who arrogantly opposed the idea of paper storing anything near what CDs can store. But the intentions went nowhere as we both entered the military and got assigned to different continents.
I believe instead of sniping what is very likely a hoax, we should focus on the practical uses of paper as a digital storage device. We wondered whether companies might create posters at the front of the store - customers snap the photo with a PDA and use conversion software to extract a store catalog, special coupons, hyperlinks to advertisements. Billboards along the highway packed with audio clips. Letters to relatives with home videos included.
Some of these uses may seem more practical than others, but I'd like to hear more creativity along what can be done with tens of megabytes than proof after proof of why paper can't pack 256GB.
Everyone seems to be focusing on the density of the printing onto the paper, but the key is probably the colors. The encoding algorithm probably uses color as symbolic representation of data.
x,y,z(color depth)
Assign color to represent data in the color range provided along with a coordinate system and viola, you have a practical, two dimensional representation of a three dimensional coordinate system with data depth provided on the z axis.
Everything in the Universe sucks: It's the law!
Comment removed based on user account deletion
I just mime encoded a couple of dvd's and printed them with a point size of 0.00000001.
The important thing is to use an OCR font...
TC - My Photos..
That is dots per inch, not pixels per inch. Each dot only being one color, the full color spectrum only created by halftones. So the maximum data to be stored on an 8.5"x11" sheet of paper using your 9600dpi printer is:
(8.5*9600)*(11*9600) dots with each dot being one of N+1 values
Where N is the number of colour tanks/toners your printer has. The +1 is for the medium (paper).
I'll be real nice and assume a 7 colour printer.
N+1=8 8 possible values = 3 bits
000=1
001=2
010=3
011=4
100=5
101=6
110=7
111=8
3 bits
So the math is 8.5*9600*11*9600*3 = storage in bits
3.23136 TiB is the theoretical maximum on paper with this 9600dpi printer.
Of course you would need a 19,200 dpi scanner...but that is child's play.
Thank you for reminding me why I like the comments section of SlashDot better than digg.com in its entirety.
No. The article says a 45 second video clip. It does not say the size of the video clip. The 432 pages of foolscap (single sided, in 10pt courier with 1 inch margins) could fit onto a four square inch piece of paper at just over 2200 pixels per inch.
A 2400 PPI printer on letter size paper with 1/4" margins could put 8*10.5*2400*2400=483840000 bits, or 57 megabytes onto the page (twice that if you use both sides of the page). That's enough for a 45 second video clip, especially if you don't use a full screen for the video.
When our name is on the back of your car, we're behind you all the way!
Ultimately, the triangles on the paper are really just printed as a bunch of dots.
Given that an ordinary printers can't print triangles, that is indeed how we normally fake it. Now, the question is, would his claims be credible if he actually was printing these shapes, not approximating them with a bunch of dots?
It seems that every "disproof" posted here starts by discarding half his claims, then proving it can't be done assuming he's only doing half of what he says he is doing.
This is still probably a scam, or he wouldn't be so tight-lipped about how he's doing it, he'd patent the process, simultaneously (a) publishing the details and (b) ensuring he makes a lot of money.
"Convictions are more dangerous enemies of truth than lies."
"Imperial" units have been metric for decades. An inch is *DEFINED* as being 25.4 mm long, a pound is *DEFINED* as being 0.45359237 kg exactly. If you went to a country that used 37 and 59.5 cent coins, you'd think they were crazy. Well, the rest of the world is looking at the US's measurement "coinage" and is shaking their heads in disbelief. How do you people function over there?
When our name is on the back of your car, we're behind you all the way!
Well, to be fair, he could be printing on both sides of the page.
When our name is on the back of your car, we're behind you all the way!
Even assuming 1200 dpi and full color range per DPI (i.e., 24 bit/pixel), you get
1200 x 1200 x 12 x 8 x 3 Byte = 414MB
That is a far cry from the claimed 256GB. An take into account that most scanners cannot resolve 24 bit color (because of noise) and have real resolutions more in the 300-500 dpi range, then this is just one giant unfounded claim.
Yes, true the best scanners available may actually resolve 4 bytes/pixel and 2400 dpi. But that would be drum scanners that costs more than a new car. And even with that you get only
2400 x 2400 x 12 x 8 x 4 Byte = 2.2GB
Another problem is printing. Current high-quality printing can get something like 1500...2500 dpi real resolution orn really good paper, but they have less than 16 colors per pixel and color is rasterized to give more color spectrum.
I call this a really bad calculation error on all sides involved or possibly plain fraud.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This is fun. Let's see what we can do if money really is no object, Bronx Bomber style.
First, you can take that picoliter of ink and stuff it full of all elements of the periodic
table including isotopes. All of those have distinct spectroscopic signatures, so you can
get 200-300 8 bit markers in one dot. On top of that there are techniques which discern
bond energies (look up coherent anti-stokes resonance for instance). Once you make complex
molecules and have sensitive enough equipment to read attomolar concentrations, the playing
field widens considerably. It may take several years and billions of dollars to write an image
like this and the same to read it off but I'll bet even hundreds of terabytes are possible if
you are wealthy and tricky enough. Of course it may be easier to weave the paper out of
double stranded DNA and sequence it (around 1e17 bits for a 2 nm thick A4 sized sheet).
I don't usualy like to think ill of my fellow slashdoters and I know I am going to get moded a troll or flaimbait and get a lot of heat for this but it seems like everyone who has posted so far are CLUELESS!
You are all talking about how you can only store so many bits at such and such a resolution on paper and how the scanners can only get so much info from it and yada yada its all a bunch of BS.
Ever wonder why a picture is worth a thousand words? Its bacause there is VISUAL data contained in the picture that can not be described in the same number of bits as it takes to represent the information in the image.
Nobody seems to flip out when we hear about a DVD size disk that can hold a few Terrabytes of data, why?, because its holographic, it uses the same storage technology as a DVD but stores information in the depth of the bit in the media as well as its linear location in the data stream, the actual data density hasn't changed when viewed as a two dimensional surface. So what if we think of this new methode as a "Visual" storage system, not just a two dimensional array but with color and geometric angles being the third and possibly fouth layer of data?
Anyone else remember that the sine of any angle is some F'ing huge number, what about cosine and tan? Throw in radians and a few math algorthms and you could probably store some major amounts of data whith just a few lines and colors.
This may be BS, but at the same time it may be a really incredible leap of imagination on the part of the creator of this. We only show how rigid and limited our minds are when we dismiss something out of hand because we don't understand it.
Now you all get to flame me, call me an idiot and explain to me how I don't understand information theory or any of the rest of the theorys or principles everyone is talking about. I don't, that may be why I get it and you don't. Maybe it is because of your inability to see beyond those principles and theorys you hold so dear that you don't understand how this data storage system works.
He's using 2^14 colors which using your math yeilds about 250GB as advertised.
I don't know who decided that printers can only distinguish between 256 different colors. You do realize that printers can actually print more that 16K colors and scanners can scan in at 24bit resolution.
All this debunking is based on a limitation of 256 colors which only exists on Slashdot.
Whether or not the printer can write the colors with the exact value as the scanner is another debate entirely. Something that is subject to "try it."
Work Safe Porn
8.5*9600*11*9600*3 bits != 3.23136 TiB.
http://retropolitan.blogspot.com/2005/06/all-ways- of-colouring-3x3-square-with.html
my password really is 'stinkypants'
Actually, no - 1200 dpi *resolution* (i.e. number of dots per inch that can be distinguished) is impossible on any dot matrix printer. That's the dot density that they print. In the old days the printer people were more honest - and computer articles were more saavy about the difference (some of the old MacUser mags from the early 90s for example).
A good laser printer might get between 300 to 600 dpi true resolution with good toner on plain paper. A dye sub might get you 300 dpi with something approaching the hues that you are talking about.
Same with scanners - while they might have the optical resolution of 1200 dpi - the number of colours that they actually distinguish is far less than the ones that they claim. Just because they keep 24 or 32 bits and their chips output that many bits doesn't mean they can *distinguish* 24 bits of colour. I believe that it's much closer to 15 to 18 bits of colour.
yea, off by 1000, my bad.
Otherwise how are you going to read your rainbow disk if the paper is slightly rotated, crumbled or sheared? With geometric shapes, you can detect these effects and compensate for them.
because the "higher orders" are completely dependent on the finer details. There's nowhere to put any more information that doesn't destroy some of what you already wrote. If you know every detail at the finest resolution, then you also know exactly what it looks like at the next level up, so there's no uncertainty to fill with more information.
I think what the article must have failed to mention is that it was a 256GB text file containing almost completely white space that he was storing in this manner -- after compressing it.
Assuming that this method of encoding was initially designed to work with a standard home printer and assuming a standard printing quality of 300 DPI, that leaves us short by a factor of about 16, (4792 / 300), or 2^4. By using the standard 4 standard CYMK printing colours to encode each bit, we have our factor of 16
My calculations do not take into account the need for any colour registration or error correction areas on the page. I would think however that by increasing the number of colours, it would still be technically feasible to have your 256GB and have plenty of room to include error correction etc.
The only thing that I can't figure out is the requirement for different shapes, maybe the error correction is built in to the shapes being used, but surely there would be more efficient ways of doing it?
One of the universal rules of happiness is always be wary of any helpful item that weighs less than its operating manual
Yes you're wrong.
An image that was printed "actual size" would not fill an a4 piece of paper. Sure there are various formats that can compress the image, but there is no additional compression gained when printed on paper vs. saved to disk. The amount of information that needs to be saved is the same.
Turn your comments around:
Suppose you had printed a full page (A4 - 8.27 x 11.69 inches) image such that every "dot" printed by a 9600 x 1200 dpi printer was a different color. Now you scan it in as a full-color tiff image - i.e. no data loss (images saved as jpg can compress quite a bit, but you loose data - hence the name "lossy-compression").
So you scan the image at the scanners best ("highest") resolution. Assuming 24 bits per color, the graphic image that is scanned in is now (9600*8.27)*(1200*11.69)*24 = 26,729,063,424 bits = 3,341,132,928 bytes or about 3Gig.
That is how big your file would be to "email" around. You may be able to get some additional compression (zip, gif, etc), but that would be software compression, and software compression doesn't care what the medium is that it is saving to - so the fact that it's from printed paper doesn't matter - and really only confuses the issue.
The point here is that just because you have a high-def image that looks good printed edge-to-edge, don't assume that there is a lot of data there. A 3meg jpg file looks damn good when printed with a high-quality printer - but there is still only 3meg of data on the printed page no matter how good the scanner is that reads it back in.
-CF
Never underestimate the bandwidth of the Hammermill® paper truck hurtling down the highway
Okay, lets look at the current maximum feasible specs we could use: 24 bit color depth at 2400dpi, seem reasonable?
Per square inch of space, that's:
(2^24)^(2400*2400) possible combinations of data, which equals
2^(24*2400*2400) if rewritten, or, conveniently enough (since I started in base 2)
24*2400*2400 bits of data per square inch, about 17 megs
17 megs per square inch of paper, although fairly impressive, falls vastly short of what was supposedly achieved. And no matter what mysterious system of shapes might be used, once put on paper, the data is going to be in dots. There's nothing you can do about that. It's just the physical limitations of two dimensions.
I wonder what kind of information (Very Work Safe) is stored on this page?
Must be top secret info!!!
if (!sig) { printf("Signature Unavailable\n"); }
But reading the comments on this article make me realize just how many morons we have reading SlashDot. Actually, it would be nice if they stuck to just reading it.
Happy Thankgiving everybody!
# (/.);;
- : float -> float -> float =
Maybe you can shit out some code for us over at ReactOS! Or hell with it, maybe just join any Linux distro dev team, and let's really bury redmond this time!
I'm sure Vista is over a million lines of code, so at one sheet of paper to a million lines of code, I'd guess you could code something really awesome with just 10 blank sheets of paper and a few burritos! But testing will be hard, since the bugs will be so small, but maybe we can kill them with the nano knives I read about 3 stories up.
rhY
I hold very few opinions. I hold information based on observation and fact. If you wish to disagree, please use facts.
You make the same error numerous people have made. 16M colors is only 24 bits, 16K colors is only 16 bits, so you are off by a factor of 1024.
(1200^2 * 8.5*11 * 16 / 8)/(1024^2) = 257 MB
Wow, you could use a sheet of paper to store like... thousands of pr0n images! Just think of the possibilities! Playboy could stop being so wasteful with individual images and include images of the past 50 years on a few sheets of colored print!
So the question is, with 16M colors, how much information can be stored there? 24 bits. "256 GB" is measuring bytes, and bytes are made of bits. Thus, ultimately we care about the number of bits, not the number of colors. So, he's right, you're wrong.
P.S. 2^6 = 64, NOT 32
What's sad is that you get the units right, but then get the exponentiation/bits wrong.
log2(2^18 * 2^2) = log2(2^18) + log2(2^2) = 18 + 2
i.e. 18 color bits + 2 shape bits = 20 bits.
Wait.. that is impossible. (really try it with a A4! )
Google sez:
Sainul Abideen rainbow: 646 hits
sainul Abideen rainbow shannon: 3 hits
If anyone is wondering what (Claude) Shannon has to do with all this, look him up.
Don't promise me a rainbow, cry me a river instead.
The Hacker's Guide To The Kernel: Don't panic()!
I have to admit that the first time I heard about 16qam was in your post. But you can't make 96 bits out of 16 bits. 16 bits have 65536 possible states. You can not code more than 65536 states using 65536 states.
if you RTFA ....you would have seen that this technology is what we are talking about,
I am sure that the paper scheme is the least important of concerns, and if you create copies
and store them, lamimate them, you still use 2 sheets of paper compared to discs which are not
recyclable....you just shred the paper and create new ones....backups my man backups.....
plus someone wants to sell you an mp3, showing you have bought a legal copy of an mp3 will be much easier in court now that you have your bill & the mp3 on the same piece of paper
Have a nice day
"Now this is what I am talking about!"
I got stuck at this word in TFA. Isn't the purpose of long-term storage to be as bio-UNdegradable as possible?
Adventure, Romance, MAD SCIENCE!
If somebody could do something similar with sealed storage devices, imagine the possibilities. It's basically compression of data with a physical algorithm.
I don't know how effective it might be without color, but I suspect there's still a lot of data that can be stored.
Too bad I didn't try to do something with my (and probably half everyone else's) idea for a more-than-binary format.
Never underestimate the bandwidth of a paper plane full of data hurtling across the room
Darn. That was indeed stupid.
There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
and to save you from having to read the whole discussion, all estimates from below at the time of posting as to the maximum amount of information that can be stored on a sheet of either A4 or 8.5"x11" paper in this way:
2 GB, 244 GB, 7.6MB, 22MB,03GB, 765KB, 1.360006 million bits, 244,800,000 bytes, 8,415,000 MB, 15,000,000 bytes, 578MB, 1540.83 MB, 403MB, 9GB, 140MB, 280MB, 87,925,612 bytes, 256 MByte, 1.7 trillion bytes, 26 Megabytes, 20196 Mbit, 3 Million Gigabytes, 68 megabytes, 64K, 30 Mb, 32Mb, 8.2Gb, 69MiB, 1.4GB, 700 Gb, 31 Tb, 3.23136 TiB, 12MB, 247.955GB, 257 MB, 50 MB, 20,971,520,000 bits, 23,040,000 bits, 4000 megabytes, 5GB, 10MB, 200Kbytes, 1.4GB, 0.18 GB, 0.05 GB, 579 Gigabytes, 72.5 Gigabytes, 7,166 gigabits, 561 Mbits, 3,341,132,928 bytes, 26 MB, 2.2GB, 17 megabytes, 17401734 bytes, 128 megabytes, 139 MB, 254 megabytes, 245 GB, 128 MB.
my password really is 'stinkypants'
Thank you for poving to me that there are still other people out there who have not yet had their brains become so full of "facts" that they can't see beyond them.
When I saw "geometrically" in the title the first thing I thought was "WOW, the data is in the angles!", but now I think your closer to the truth, its all about adding states to the bits. Though using the angle of the figure relative to some reference line would add another set of states, hmmmm.
Can you imagine the fun when quantum computing hits main stream? All of the 1/0 dinosuars are going to be facing a meteor in the form of the Qbit. Thanks again, PG
He didn't say how thick the plastic sheet or "paper" was, did he?
I think scotch tape stored 100GB didn't it? You just need to get enough tape. The rest's all grunt work.
The leaders of the business in April of course announced 515GB/square inch which sounds like a lot but how long does it take to read and back it up, right?
link
I'm sure someone will correct me if I'm wrong, but I've been of the impression that "32-bit" color is the same bit-depth as 24-bit color, plus an alpha (transparency) channel. Transparency is irrelevant in capturing an image.. You still end up with 8 bits per color channel. So in other words, there's no such thing as "true 32-bit color" from a scanner.
*sits back and waits to be corrected*
http://undecidedgames.blogspot.com
Thanks. After rereading this whole exchange, I think that checking up on my drug regimen is in order :-)