4 ms·

You know, punched card decks used to store data -- very small amounts of data, at least relative to tapes -- which in turn stored very small amounts of data rel

You know, punched card decks used to store data -- very small amounts of data, at least relative to tapes -- which in turn stored very small amounts of data relative to disk drives, etc., etc. On that note, if one wanted to make an improvised data storage device, for storing very small amounts of data (for let's say, a future Zombie Apocalypse, or what-have-you!) -- then what about using a Printer/OCR combo -- to store small amounts of data (relatively speaking!) -- as graphical designs, dot graphs, similar to punch cards, in effect, on pieces of ordinary printer paper? Oh sure, it wouldn't store Gigabytes of information, or even Megabytes or Killobytes -- but you could probably fit some early historical computer programs onto standard printer paper -- just printed as dot patterns! Which leads to another interesting question! Given a Printer of X DPI printing capacity, and an OCR of Y DPI scanning capacity: a) What algorithm or algorithms should be used to put the maximum amount of information that can be reliably scanned (100% accuracy every time!) back onto the the page? b) What encoding method should be used? c) What checksumming/CRC/hash/error correcting method should be used to insure 100% accuracy? d) Are there any other potential snags or gotchas, such as the inability to print and/or scan on a specific part of a page and/or issues with inks fading over time, etc., etc.? e) All of the above with only black and white permitted...? f) All of the above with grayscale permitted...? g) All of the above with all colors that a printer can produce permitted...? An interesting question in information storage/retrieval, no? Perhaps it would make a good future interview question... Anyway, love the card punch emulator!

drekipus 4y ago
QR codes would probably be best for this, but I don't know how well they can be tiled / scaled. They do have good data compression and error correction though.
- jononor 4y ago
  If one embeds a sequence number into the data of each QR code, then they can be scanned independently and ordered later using the sequence number.
buildsjets 4y ago
A 177 x 177 QR code holds 2953 bytes. Each voxel should be printed 4 pixels wide for repeatable printing/scanning. Assuming a 600 DPI printer and no margin limitations, you can fit a grid of 7 x 9 QR codes on an 8.5 x 11 paper. About 181 kB per side, about as much as an old-school 5.25 floppy.
teraflop 4y ago
Here's an implementation of that idea that can fit 200KB on a sheet of paper: http://ronja.twibright.com/optar/ http://ronja.twibright.com/optar/
- TedDoesntTalk 4y ago
  This is really cool. The weak spot is in the decoder software… if that is lost, your paper is useless.
banana_giraffe 4y ago
Cauzin Softstrip did this back in the day to save magazine readers from having to type in programs or raw byte code. Or at least, that was the theory, I never actually had a fancy enough setup, or knew someone that did, to see it in action. Here's an example from a random magazine: https://archive.org/details/byte-magazine-1986-05/page/n432/mode/1up https://archive.org/details/byte-magazine-1986-05/page/n432/...
mgdlbp 4y ago
> store small amounts of data ... as graphical designs ... on pieces of ordinary printer paper? You mean, printing out a picture? ... Joking aside, if you tolerate lossy "compression", it'd be interesting to see what the characteristics of printing an image are in terms of image codec metrics. I guess the comparison would be with the "decoded" result, which'd be the raw output of the scanner. With modern equipment, it'd certainly be much higher quality than a JPEG encoded at the (albeit conservative) ~200 kB estimates given for the lossless formats. This would also be a rare codec where future increases in decoder technology can actually increase the quality of the decoded output, assuming that the printer and scanner currently have similar DPI. I wonder whether that applies still to historical film photos or if digital scanners have already surpassed the resolution of the original media to the point of saturation. Would being able to "subsample" individual film grains allow extracting a tiny bit more detail?

drekipus 4y ago

QR codes would probably be best for this, but I don't know how well they can be tiled / scaled. They do have good data compression and error correction though.

jononor 4y ago
If one embeds a sequence number into the data of each QR code, then they can be scanned independently and ordered later using the sequence number.

buildsjets 4y ago

A 177 x 177 QR code holds 2953 bytes. Each voxel should be printed 4 pixels wide for repeatable printing/scanning. Assuming a 600 DPI printer and no margin limitations, you can fit a grid of 7 x 9 QR codes on an 8.5 x 11 paper. About 181 kB per side, about as much as an old-school 5.25 floppy.

teraflop 4y ago

Here's an implementation of that idea that can fit 200KB on a sheet of paper: http://ronja.twibright.com/optar/ http://ronja.twibright.com/optar/

TedDoesntTalk 4y ago
This is really cool. The weak spot is in the decoder software… if that is lost, your paper is useless.

banana_giraffe 4y ago

Cauzin Softstrip did this back in the day to save magazine readers from having to type in programs or raw byte code. Or at least, that was the theory, I never actually had a fancy enough setup, or knew someone that did, to see it in action. Here's an example from a random magazine: https://archive.org/details/byte-magazine-1986-05/page/n432/mode/1up https://archive.org/details/byte-magazine-1986-05/page/n432/...

mgdlbp 4y ago

> store small amounts of data ... as graphical designs ... on pieces of ordinary printer paper? You mean, printing out a picture? ... Joking aside, if you tolerate lossy "compression", it'd be interesting to see what the characteristics of printing an image are in terms of image codec metrics. I guess the comparison would be with the "decoded" result, which'd be the raw output of the scanner. With modern equipment, it'd certainly be much higher quality than a JPEG encoded at the (albeit conservative) ~200 kB estimates given for the lossless formats. This would also be a rare codec where future increases in decoder technology can actually increase the quality of the decoded output, assuming that the printer and scanner currently have similar DPI. I wonder whether that applies still to historical film photos or if digital scanners have already surpassed the resolution of the original media to the point of saturation. Would being able to "subsample" individual film grains allow extracting a tiny bit more detail?