3 ms·
To be truly resilient against any kind of (potentially unknown, even) lossy image compression, you would need to add a lot of redundancy. QR Codes are pretty mu
by anyfoo 8y ago
To be truly resilient against any kind of (potentially unknown, even) lossy image compression, you would need to add a lot of redundancy. QR Codes are pretty much that, but their data needs to survive being “transmitted” through a blurry photo with arbitrary lighting, rotation and perspective, so they likely have a lot more redundancy than you realistically need. (EDIT: You might hit the limit where you need QR Code levels of efficiency relatively quickly, depending on the number of steps and how aggressive each recompression is.)
If saving and sharing can mean changing the image dimensions however, you of course need redundancy by that factor.
But yeah, that’s why we don’t choose lossy compression algorithms for binary data. If every bit counts, there is no entropy you can lose (though a lossless algorithm might find a more efficient representation, so to speak).
- peterburkimsher 8y agoQR codes have a maximum size of 7,089 numerical digits - not enough to transmit a program or song. I'd be hoping to move about 5 MB.
- snaily 8y agoFacebook, which was the use case you mentioned upthread, doesn't store 5MB images. You'd have to design for way less than 5MB, I should imagine.
- anyfoo 8y agoThat was kind of my point, was it not? QR Code might or might not have too much redundancy (depending on how resilient you want to be against what amount of sharing), but the general principle stands. Lossy compression removes information by design, you want to keep all bits of information, therefore you have to represent your information in a redundant (and therefore inefficient, by density) way.