markusfisch
commented
1 year ago The reason for this is that Binary Eye can only encode text, unfortunately. Decoding binary content is fully supported - but not encoding it, embarrassingly 😉 But I'll add this with the next version!
I'd like to use BinaryEye to get a clean image of an Aztec code which catima has trouble scanning (and BinaryEye scans just OK) – but even outside of catima, one might want to save a clean copy of a code.
I scanned the code in BinaryEye, and got the data (it's binary, 286 characters, AZTEC Version 11) with its hex dump showing a mix of binary data, some intentional and some accidental ASCII in it.
When I then pressed "share" and selected "Share with Compose barcode" (also provided by BinaryEye), the "Compose barcode" dialog offered AZTEC from the start (could also be a relic of last time I tried that), and the hex data as the content. (So far unsuspicious, could be that the data is always taken in as hex, would make sense given most codes can transport binary data). The resulting image looked was a plausible code -- didn't look exactly like the original, but then again, I didn't see the original input's error correction level, and might have picked the wrong one.
However, decoding a screenshot of that code showed that it contains only ASCII numbers and hex digits, so things suddenly became hex encoded instead of round-tripping.
I don't have any clear suggestion of how to fix it – whether the intent should use binary on both sides, hex on both sides, or whether it makes sense to use a dedicated action to reproduce the code (maybe with its exact error correction level, and similar choices identical to the input).
Thanks for providing BinaryEye, it often comes in handy (pun intended for German speakers ;-) )