All the details are in the README
I am looking for someone to write a decoder, test the hell out of it, and give feedback.
Because my printer is broken at the moment, I can't test it out right now.
All the details are in the README
I am looking for someone to write a decoder, test the hell out of it, and give feedback.
Because my printer is broken at the moment, I can't test it out right now.
My understanding is that the smallest unit of data representation is a single pixel for 2 bits, so I don't think it would be able to guard against defects like smudges, scratches where you lose a large chunk of pixels?
I feel it would be better to have the output "blocks" much larger than a pixel, or have the error recovery mechanism extend across a larger region.
If this works out well I am interested in using/helping, would be pretty neat to be able to store key materials in this format.
You are close, but the smallest unit of data representation is a single dot for 2 bits.
This means the lower your DPI, the larger the dot should be. 10 DPI is 10 dots per inch, meaning the dots are much larger than 600 DPI dots, because more fit into an inch. Pretty cool, right?
In theory, adjusting DPI enhances the properties you mentioned. Blots is currently configured to 300 DPI, but it is easy to change this.
This is stuff I should have mentioned in the README.
As for colors, I will paste what I wrote on reddit:
Two other users:
I mean, paper can last that long, but it can change color/structure/consistency which might disturb those little patterns
Yeah, I suspect different papers / inks would greatly affect how long it could be readable. Typical consumer ink gets color shifts pretty quickly.
Me:
That is the reason solid red, green and blue were chosen. It is ok to have them fade. There will be thresholds for what all shades of red, green and blue to determine what color the shade is.
Any more than those channels and it gets even harder to know what color is which. This is why most current formats use black and white, to be 100% sure, but I think they are being overly cautious. There is a color-based format like mine by Microsoft, which from what I briefly saw, has a similar idea.
Is it possible to spread the group over a larger area than putting them very close together? And do you think that's a good idea? (like instead of putting them together consecutively, you just have an algorithm to determine the spread)
I am facing a similar problem with upgrading a file format to have error correction, but I also want to guard against burst errors effectively. So I am curious with what you think about burst errors as well.
I think the multi colour choice is good, since the most common use case would probably be to store private keys or other key materials, where you don't need/want to print a lot of pages anyway.
Yep, there is no issue to spread out the group of dots over a larger area. But in that case, why not just reduce the DPI, so that your dots are larger?
I think the best solution would be to randomly spread the data all over the page, but then you would need some sort of map to know what piece of data is where.
What you are suggesting is what most QR code or similar formats do. In QR's case, it is somewhat diagonally biased. In another's case (I forget it's name), it spreads the data out circularly.
In Blots case, I think this is a non-issue, because this paper will most likely be put into a plastic sleeve or folded once and put into a safe or folder.
I'm no expert so we're on the same level of understanding
Just wanted to say this project is so awesome, you keep rocking, my dude!