lf94
Comparison with other formats
Could you make a comparison between QR/Datamatrix, Paperback, Optar and this?
https://github.com/cyphar/paperback and https://github.com/matheusd/pypaperbak
https://github.com/colorsafe/colorsafe
@lf94 not just black and white, but use standards like JABCode and HiQ Color QR code (Google it)
@DonaldTsang yeah I saw JABCode the other day. If you scroll to the bottom of my README you'll see though that color is actually a really bad idea right now. Maybe in the future when consumer printers are better, it will be more feasible.
Essentially all these formats are based around a few things:
- Alignment
- Data layout
- Error correction
My format aims to be the simplest and most dense. So it includes no error correction. Essentially you want your files you store on the paper to be "raw", as in, having a bad 0 or 1 will not break your format. This means the paper can fade and the data still retrievable.
In fact the format should be so simple you can print the decoder or pseudo-decoder on the other side so in 50 years time you can recreate it and read your data.
Well we do need to go by Voyager standards, but it is always better to do error checking. My advice
- Pick only one error checking level (30~50% or the highest settings in QR or iQR code)
- Make sure the color channels are done in a way that multiple types of data loss won't happen
- Don't just have linear encodings, make sure that if the paper gets smudged that you can still restore it
- Simplify QR code and Paperback/Optar to a point it is basically ELI5
Voyager standards
Ok, nice way to put it :slightly_smiling_face:
- I should probably just make this toggleable/adjustable
- Please see my README. The before printed and the after printed are actually hilarious. Color is not good right now - I'm not just saying this for no reason.
- My README shows the encoding is not linear, but in "blocks". Actually I think it's pretty clever!
- Yes we could do this. But they are still complex to implement. Could be interesting to pursue regardless to see the real outcome.
For 2. I saw it and I understand, but that is another thing to improve, 3bits vs 2 bit For 3. The chunks are not large enough for parity, 6 pixels does not make one barcode
The chunks are not large enough for parity, 6 pixels does not make one barcode
Could you give me more details on this? I'm looking to pick this up again and make the color variant work. Your suggestions are very great.
@lf94 the more pixels and the more bits you are allowed to bundle together, the easier it is for you to have flexibility in parity bit percentage.
Annual postmortem: what made it such that the implementation to be harder to do than Paperback or colorsafe? I might attribute it to the fact that this repo is prototyping in Rust rather than something like Go or Python
Hey once again @DonaldTsang !
I wouldn't say it is harder, it's just they seem complicated. Rust has nothing to do with it.
You are 100% right that it would be more beneficial to create a document that can teach someone concisely how to implement a decoder.
By the way, love your "favs" list. :slightly_smiling_face:
Maybe after I've tried implementing a few of the others, I can come back to mine. But for now, there is no time.
@DonaldTsang I've looked at the others you've listed, and they all are missing documentation, or are incomplete (colorsafe, paperbak, etc).
I have to say I really like where colorsafe is going, and feel like it is aiming for simplicity also. Unfortunately its documentation is terrible right now and since it's incomplete I feel the author's intentions are not complete either.
My main issue with creating my own format is learning how to properly print graphics onto paper. Just generating a bitmap is not enough...