Show HN: GigaPaper0.6.1 Colored Dot Data
I've been trying to print massive amounts of data as dots on paper. The more colors you use, the more data per dot. I believe that write once read many (WORM) data is absolutely crucial in a time where anything can be recreated or altered by AI with incredible realism and precision.
At this point, all I have is a program that converts data into SVG files. I had some familiarity with the format and wanted to make sure I could make something that just works, given that I have very little experience with C.
Right now, these files can only be written in base16, where every half of a byte is a dot and there are 16 hypothetical colors, or base64, where every 4 dots is 3 bytes and there are 64 colors. 16 or 64 color SVG files, multiplied by the number of pages necessary to hold all the data. I hope to eventually increase this to many millions of colors in the visible light spectrum (at lower resolutions than I will describe shortly), then branch out into ultraviolet reflective resins and infrared reflective resins. I do worry about color degradation and the impact of repeated scanning.
The papers, I hope, can be read using a captured slow motion video from a camera taped to a (toy?) microscope lens that pans across the paper.
My intent was to first recommend an SVG to GCode software, which turns the SVGs into something a 3d printer can actually use. Later, I would create some code that converts the data to GCode natively. Unfortunately, and I don't fully know why, but every software I've tried out for this purpose has failed to accurately recreate the SVG images, or failed to open the data whatsoever. If you know something that works, please write it in the comments.
I absolutely hope to get the GCode conversion part underway, but must first restructure the program to read the input files once and write to alternating output files depending on the corresponding color of the current input bytes. Right now, the program reads it 16 or 64 times and only writes the ones, twos, threes, etc to their respective color files. I must make something to get mkdir to work in windows and Linux. I must create something that reads output files and reverses the process to check if the input was properly translated into svgs. I must also turn some numbers into arrays of numbers, since long long int may not be big enough for certain things I have planned. I might make something to break up the output files into pieces so they can load more easily. I hope to eventually rewrite many amateur elements of my code.
I hope for myself and others to use modified 3d printers which have detachable nozzles. First, you print from one nozzle and one color onto the paper. Then print 62 more times or so (white is the paper). I don't actually know if this kind of exchange is possible for printers at the tiny xy resolution I've been evaluating.
Here are some potential specs that measure the data on individual sides of a paper, I understand that visible light is 380 to 750 nm so resolutions this small must lack visible colors, but some ultraviolet reflective materials should still function perfectly.
HP Jet Fusion 5200 Series is 80 nm
210297/0.08/0.08
9745312 dots
155924992 permutations with 16 colors
19490624 bytes
18.58771 megabytes
623699968 permutations with 64 colors
77962496 bytes
74.35083 megabytes
https://all3dp.com/1/high-resolution-3d-printer-the-ultimate...
Phrozen Sonic Mini 8K Resin 3D is 22 nm
210297/0.022/0.022
128863636 dots
2061818176 permutations with 16 colors
257727272 bytes
245.78787994 megabytes
8247272704 permutations with 64 colors
1030909088 bytes
983.15151978 megabytes
Here's the software. GigaPaper0.6.1. Please heed the readme. https://sourceforge.net/u/acaiblue44/blog/2024/05/gigapaper0...
There may be something better than color and brightness, which works at microscopic sizes, that I'm missing. Please comment here if you know something. Alternatively, I have the idea to use height instead of color, GigaBricks, where cubes are stacked on each other and precise lidar determines the number of cubes. These are stored within a container that has an inversion of the 3d cube pattern resting on top so that neither breaks too easily.