sz3 / libcimbar

Optimized implementation for color-icon-matrix barcodes
https://cimbar.org
Mozilla Public License 2.0
4.22k stars 306 forks source link

decode error #108

Open pyke8351 opened 1 month ago

pyke8351 commented 1 month ago

Excuse me. I've run into a problem when using the decoding function. The bytes in this line of code is 0:

int bytes = decodefun(img, color_mode, shouldPreprocess, color_correct);

Among them, img can be loaded correctly. color_mode: 1. shouldPreprocess: 1 color_correct: 2 The encoding function is normal.

sz3 commented 1 month ago

What's the context here? Is the decode/encode being attempted via the cimbar command line tool?

For reference, that function signature is here: https://github.com/sz3/libcimbar/blob/75d6cfb77bf5d75df0a9498d546120019e9e522e/src/exe/cimbar/cimbar.cpp#L259-L265

... which is a decode in the basic, non-fountain format. In other words it does the reedsolomon error correction decoding but not wirehair. This is mostly useful for debugging -- if we have a single image, we can see if the reedsolomon part of the decode succeeds or not.

If it doesn't, that can mean a few things:

  1. maybe the image failed to extract. Some individual cimbar images act pathological against the extract algorithm, making them borderline useless. (for reference, this is the same concern that leads to QR codes having multiple mask patterns. cimbar doesn't have the same tricks, but because it's a stream we can brute force it)
    • In the context of the encoder generating a redundant set of barcodes this is not a big deal, but for an individual image it can be an issue.
    • I've considered adding an extract sanity check to the cli encode tool. The idea would be to discard "bad" codes, since we can just ask the fountain encoder for the next in the sequence anyway.
  2. maybe the parameters don't match. For example, if the encode used mode 4C and the decode is using mode B, the decode will fail. Similarly, color_mode must also be correct (the cli should handle this if the mode is correct)
  3. the image could be bad, blurry, etc
pyke8351 commented 1 month ago

Thank you for your reply.I employed the command-line input, namely “./cimbar --encode -i inputfile.txt -o outputprefix” as mentioned in the example, to obtain the image. When I attempted to decode it, no result was yielded, just as I previously stated. Nevertheless, when I utilized the app for decoding, the corresponding file could be obtained. Maybe I am not yet quite familiar with the code and I should study it more earnestly.

pyke8351 commented 1 month ago

When the file is too small, for example, less than 183 bytes, it is likely to encounter the above problems.

sz3 commented 1 month ago

It's possible that there's a different failure mode I'm not aware of. If you have an example file that can reproduces the issue, I might be able to take a look. :slightly_smiling_face: