4 ms·
I spent way too much time on a project similar to this years ago. I figured a 8.5x11 sheet of paper reduced to 8x10.5. With 1000dpi that is 84 megabits of da
by sumtechguy 3y ago
I spent way too much time on a project similar to this years ago.
I figured a 8.5x11 sheet of paper reduced to 8x10.5.
With 1000dpi that is 84 megabits of data you can spit out. Way more if you use color. x5 if you just use the standard colors (white, black, cyan, yellow, magenta) 420 megabits. That comes out to about 52.5 megabytes.
Now realistically. You will probably have a pretty awful scanner (100-300dpi) you can get better but they cost more. Also your scanner has to be spot on the grid to get the full amount. Also your print heads need to be exactly calibrated. So that means some sort of slop in the grid. usually by lowering the DPI and by making the pixels bigger, some sort of alignment retical, plus some sort of data recovery (like in CDs). That wildly reduces the amount of actual data you can get in there. Oh and then fun things like using a jet ink printer and it ink bleed. I was lucky to get about 2-8 megabytes with my methods.
I stopped playing with it. The ink got too expensive for me to keep playing with it. A box of 10 reams of paper of 1000 sheets each put it in the 40-80GB per box range as you could use both sides of the paper. And wildly slow to get back out. But a fun experiment.
- fsiefken 3y agoWow, so with state of the art text compression and error correction, that could conceivably reach 400 megabytes. That'd all my paper books! Now if I print my text with the smallest readable font I could fit around 500 kilobytes of human readable text on an A4, with shorthand compression more. The same as with paperback uncompressed. The has the advantage of not needing the software, power, a camera or a computer. Just a magnifying glass, good eyes, functioning cognition and light.
- sumtechguy 3y agoMegabits not bytes. it is about 50 megabytes raw data. You will lose most of it to paper alignment and reed solomon error correction. The 52MB is super optimistic. But only if you can get the paper to align correctly and read back the data extremely hyper accurately. I too started with glyphs like you did. But if you can get more colors and just treat them as pixels. You will probably approach the maximum of the medium. Which at point the Shannon CS papers kick in hard. For something like a 10pt font and 1000 dpi. You could be looking at about 3200 glyphs per sheet. Smaller is better obviously. But just to ballpark it that is about 80x40 glyphs. Using 256 different glyphs that is about 1MB of data, probably within most printer/scanners capabilities. 4x more if you use colors (not 5 as you can not use white), more if you do things like multi color glyphs. You may run into the problem of getting the OCR to get the 256 glyphs right though. Give it a shot. It was fun to mess around with for a few weeks. Until I realized I was basically coating sheets of paper with expensive ink for 2-5MB of data.
- MadnessASAP 3y agoI've got this stuck in my head a bit now and I'm wondering if you have any thoughts on my idea. I feel instead of trying to encode data directly in individual dots it would be better to encode data as small squares (or overlapping circle) of varying intensities. So a slower symbol rate but with more symbols. Using color you could have a 4D (C M Y K) space to distribute symbols into and probably hit some pretty high densities. This way your less reliant on how precisely your printer/scanner can place and read a dot (which is not what they're meant to do) and more relying on how well they can produce an image (which they are meant to do)
- fsiefken 3y agoPerhaps something like colored rMQR or HCCB is helpful? https://hackaday.com/2023/07/28/color-can-triple-qr-code-capacity/ https://hackaday.com/2023/07/28/color-can-triple-qr-code-cap... https://hackaday.com/2023/07/28/color-can-triple-qr-code-capacity/ https://hackaday.com/2023/07/28/color-can-triple-qr-code-cap... https://en.wikipedia.org/wiki/High_Capacity_Color_Barcode https://en.wikipedia.org/wiki/High_Capacity_Color_Barcode
- sumtechguy 3y agonot a bad idea... could work. Also the child to yours has a decent link to using masking. That way you could encode 'color filters' into a few different spaces and get the most of the color ranges. The more dimensions you can pack in, the higher your bit rate. For example I could have 256 glyphs. Just black and white. But if I rotate them (and make sure all the glyphs are rotatable) I can at least 8x the amount of data packed into one location (just using 45degree rotations). Color for me was just to another dimension. You could pack more by breaking the glyphs into 4 regions (or more) and varying the colors. There all sorts of interesting dimensions you can pack in there.