Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Data Storage

256GB Geometrically Encoded Paper Storage Device 462

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."
This discussion has been archived. No new comments can be posted.

256GB Geometrically Encoded Paper Storage Device

Comments Filter:
  • by eldavojohn ( 898314 ) * <eldavojohn@@@gmail...com> on Sunday November 26, 2006 @10:29AM (#16991402) Journal
    The Rainbow technology is feasible because printed text, readable by the human eye is a very wasteful use of the potential capacity of paper to store data.
    And I'm sure this "Rainbow Technology" is also very wasteful if you would devise a way to encode data on electrons & lay them on the sheet of paper and then read them. The obvious problem being that just exposing the paper to the natural elements would probably render some of the data useless. Now I know that compact disc drives in computers use a form of error correcting codes (I can't recall if it's cyclic redundancy checks or some other form of parity) and I assume that the scheme of this paper technology uses the same (most likely at the cost of a fraction of space). Judging by the word 'rainbow' I'm guessing it uses colorized shapes to encode the data which is a novel idea but what quality must the paper & ink be? Can the paper in my printer be used to encode this data?

    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.
    • by Zadaz ( 950521 ) on Sunday November 26, 2006 @10:39AM (#16991458)
      QR Codes [wikipedia.org] are not as sophisticated, but can reconstruct the original data when 30% image is missing or distorted. Since these guys are obviously pretty clever, I can't imagine this feature would be overlooked.
    • Related prior art (Score:3, Informative)

      by msobkow ( 48369 )

      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

    • We can imagine to protect the paper in some way. After all, hard drives have to be stored in a metallic case to work correctly. That brings me to another question : Considering a feasible protection, how long do the data stay on the medium ? How many read errors per Gb ? how many write errors ? That is the real problem with data storage.
  • Cool... (Score:5, Funny)

    by tinrobot ( 314936 ) on Sunday November 26, 2006 @10:34AM (#16991430)
    Now it's possible to fold up 256MB worth of data and fly it across the room.
  • by Utopia ( 149375 ) on Sunday November 26, 2006 @10:37AM (#16991440)
    I would love to know which scanner has the ability to scan with such high fidelity.

  • Scam... (Score:5, Informative)

    by Anonymous Coward on Sunday November 26, 2006 @10:37AM (#16991442)
    according to this Indian blogger [blogspot.com].
    • 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
      • Re: (Score:2, Informative)

        by SQL Error ( 16383 )
        Sorry, but you have combinatorial math in there where it doesn't apply. Yes, 24 bits gives you 256*256*256 colours, but it's still 24 bits.

        The appropriate calculation is 4096*4096*24*8*11, so you over-estimated the capacity by a factor of 700,000 or so.
        • oopsie you're right! but that's still multi-gigabyte capacity. As for the other comments about it taking more than one dot to make an image pixel, they don't understand that I'm computing the maximum data capacity not the image reproduction capacity. And the calculation was supposed to be the ideal one not one considering imperfections.

          Now if we were to assume that he could get an extra factor of 256 somewhere, like for example he had 48 Bit color depth, used 6 color inks, and could get 4 times as many p
        • Re:maybe not scam? (Score:4, Insightful)

          by Yartrebo ( 690383 ) on Sunday November 26, 2006 @12:33PM (#16992226)
          Can you really print 4,096 dots per linear inch on paper and still be able to read each individual dot? My guess is that beyond 300 dpi or so bleeding becomes a major issue and somewhere beyond that the grain size of paper becomes an issue.

          Also, can you really have 256 distinguishable color levels on a piece of paper - especially considering that paper is not a uniform color on the micro-scale (it's made up of short strands of cellulose)?

          Even if all these problems can be overcome, there is the limiting factor of diffraction, which will limit any optical system (paper or otherwise) to a data density of about 1/wavelength^2, which is roughly the density of a DVD.
      • Re: (Score:2, Informative)

        by Anonymous Coward
        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


        Please, at least try to understand the technology involved. 4096 dpi means 4096 individual dots. Each of those dots is a single ink colour (typically one of cyan, magenta, yellow, or black), and it is the combination of those dots in dithering patterns which produces multicoloured output.

        Your "4096 * 4
      • by gutnor ( 872759 )
        He claims a density of 2.7 GB per square inch.

        Professional printer can realiabily print with 300 dpi resolution. The extra dot in 4096 dpi are used only because more than one dot is required to create 1 visual dot : example you need at least 2 dots to create a pure red dot. Also there is diffusion and splatter, ...

        Now with 300 "realiable" dpi, it still needs to encode (2700*1024*1024*8)/(300*300) values ( ie colors ) = 250 000 colors.
        I suppose without using ultra calibrated hardware on highly consistent set
        • Sorry, you've fallen into the same trap. Not 250,000 colours (which sounds vaguely feasible), but 250,000 bits of colour resolution, which is of course impossible.

          As you say, the true colour resolution of good printers is around 300dpi, so the caculation is really off by a factor of 100,000,000 or so.
      • by Bender_ ( 179208 )

        Yeah, and now lets assume realistic numbers.

        Lets assume paper resolution is limited to 600dpi. The color fidelity that can be recognized accurately is probably less than 18bit.

        So, somehow we end up with 600*600*18*8*11=570240000bits which is 68 megabytes. Subtracting 50% for error correction (probably still way too conservative) we end up with 35 megabytes of usable data.

        Not impressive anymore? Well, add to that that an extremely expensive scanner is required to read the data.
        Suddenly USB sticks look like a
  • by Anonymous Coward
    than 6800000000 dwords?
  • The ultimate backup solution. With acid free paper & some stable color inks, you can back up your entire hard drive on a regular basis.

    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&section=0&article= 88962&d=18&m=11&y=2006 [arabnews.com]
  • C'mon Slashdot (Score:5, Informative)

    by jokell82 ( 536447 ) on Sunday November 26, 2006 @10:41AM (#16991472) Homepage
    I expect to see a story like this on Digg, but I thought Slashdot was better than this.

    It's a scam [blogspot.com].
    • Re: (Score:2, Funny)

      by Kuscheltier ( 752042 )
      quote:I expect to see a story like this on Digg, but I thought Slashdot was better than this.

      You must be new here!
  • by Anonymous Coward on Sunday November 26, 2006 @10:42AM (#16991476)
    I wiped my ass on a blank sheet, scanned it in and was greeted with the Windows Vista login screen.
    • I was just looking for the toilet paper reference! One use is an awesome random seed generator for security applications! Everytime you wipe, first scan and read contents to update the seed, before you toss!
  • by OeLeWaPpErKe ( 412765 ) on Sunday November 26, 2006 @10:45AM (#16991490) Homepage
    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.
    • You guys don't get it, this storage facility is write-only, so there is no need for a scanner.
    • by BeerCat ( 685972 )
      I think you are mostly there.

      He'd need to store 256*1024*1024*1024*8 = 2199023255552 bits

      A4 is, as you say 210mm x 297mm, which is 96.67 inch^2 (you forgot to divide by another 25.4)

      So, 22,747,732,032 bits per inch^2 are needed. Now, even a lowly 300 dpi scanner would only need to differentiate 252,752 colours, which is achievable with 6 bits each for R,G and B.

      Alternatively, a 600dpi scanner could do it with 63188 colours, which is less than 2^16.

      In other words, I think it is physically possible, but the s
      • You seem to have confused numbers with the bits required to store them.

        So, 22,747,732,032 bits per inch^2 are needed. Now, even a lowly 300 dpi scanner would only need to differentiate 252,752 colours, which is achievable with 6 bits each for R,G and B.

        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 accurac

    • Re:This is a lie (Score:4, Informative)

      by Panaqqa ( 927615 ) on Sunday November 26, 2006 @11:35AM (#16991826) Homepage
      Okay, let's look at some math. First, calculate the number of bits that must be stored to reliably archive 256GB:

      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 = .426 micro meters = 426 nm

      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.

    • No matter what the encoding, you're still going to need it. So this is a scam, plain and simple.

      You forgot the one important component which embedded in the name of the RTFA's method: colors. The method uses colors and thus called "Rainbow format". Also it specifically used geometrical shapes - which introduce another angle to data representations. It's not about dots anymore - it's about shapes and colors.

      Besides, somehow encodings used to reach megabyte wireless speeds are not surprising to you. (

  • 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.

    Given that the BBC's Domesday project [wikipedia.org] (data gathered in 1986) needed to be "rescued" by 2002 (http://news.bbc.co.uk/1/hi/technology/2534391.stm ), then there are currently no reliable digital archive systems for long term storage.

    On the other hand, the Rosetta Project look like they could get it licked for really long term storage (Example http:// [rosettaproject.org]
    • by Dunbal ( 464142 )
      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.

            Plus you could always take some LSD (if you're into that sort of thing) and stare at your data for a few hours. Like, wow - man. Try doing THAT with a hard drive...
    • by Znork ( 31774 )
      "then there are currently no reliable digital archive systems for long term storage."

      Actually, there are reliable digital archive systems, you just need to get rid of the conceptual fallacy that 'archive' means some 'special' form of storage.

      Consider the data you want 'archived' the same as stored live data and dont have that particular problem anymore. The problem for long term live data storage in that case merely becomes issues of migration, redundancy and maintenance (the issues one tries to ignore or d
      • by BeerCat ( 685972 )
        OK, my bad on using a bit too much verbal shorthand.

        The data medium matters for "store and forget about it", whereas "install new and copy old" means that every time the hardware is upgraded, the archived data is re-copied (which is presumably why there is still the oldest web page accessible, created back in 1996)

        Spot on with the DRM comment, though. I wonder how long it will take people to realise that it turns data into random junk.
    • by Rallion ( 711805 )
      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.


      Except that in a book, if the color fades a little, we can still read it. If the paper gets folded, we can still read it. And so on.
  • Can we now say again, "Sorry, my dog ate my homework!" ?
  • by terrencefw ( 605681 ) <slashdot@NOSPAm.jamesholden.net> on Sunday November 26, 2006 @10:52AM (#16991526) Homepage
    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.
  • Do The Numbers (Score:5, Insightful)

    by SQL Error ( 16383 ) on Sunday November 26, 2006 @10:53AM (#16991536)
    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.
    • 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

      • 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.
        • 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.
      • by rmstar ( 114746 )
        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.
  • hmmm... (Score:5, Interesting)

    by leehwtsohg ( 618675 ) on Sunday November 26, 2006 @10:57AM (#16991564)
    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!
  • From the linked article [arabnews.com] in the article:

    Sainul says a CD or DVD consumes 16 grams of polycarbonate, a petroleum by-product. While a CD costs Rs.15 (SR1.25), his paper or plastic-made RVD will cost just about Rs.1.50 and has 131 times more storage capacity.

    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.

  • 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.
    • There is an old saw in cryptography that anyone can create an encryption algorithm that they themselves cannot break. The point being that the value lies in creating an encryption algorithm that somebody else cannot break. The same excuse does not exist for compression algorithms. Just choose a random sample of wikipedia and see how well the scheme works.
  • 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!
  • by Flain ( 1032116 ) on Sunday November 26, 2006 @11:19AM (#16991702)
    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.
    • bingo- there's the real proof that this is a scam. most of the other arguments don't take into account a sort of compression that could be possible by using the shapes and whatnot to encode the data- so think of it on a bitmap- he claims you can store 256gb of data in a bitmap of only a few mb?

      I wanted to be the first to post this, but you beat me to it, and I wanted to make sure someone saw your post which was at zero for some reason.
  • 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'
  • 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

  • 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
  • by Khyber ( 864651 ) <techkitsune@gmail.com> on Sunday November 26, 2006 @01:02PM (#16992474) Homepage Journal
    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.
  • by Peter Cooper ( 660482 ) on Sunday November 26, 2006 @01:57PM (#16992936) Homepage Journal
    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.
    • Re: (Score:3, Insightful)

      While I agree that Digg's quicker updates make it more "relevant", and that Slashdot indeed needs a shakeup with its editors there is a reason Slashdot is still superior. In the Digg comments for that story, most of the people quite obviously have no science to back up their responses. On Slashdot you will find some of the most thorough scientific debunking on the net. You see, not only do the intelligent people on Slashdot hate to see crap like this posted, but they also hate for people to read it and g

As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality. -- Albert Einstein

Working...