Dear Maintainer,

I use libdtmx to place 2D codes with compressed and encrypted (and
therefore binary) content.
I have found that the decode routine truncates the decoded content at
the first null byte.
It seems that it incorrectly uses C-strings to pass the data between the
library and Python.
The dmtxread utility correctly decodes such contents.
I send the demonstrator files:
1) demo.png - the 2D code with binary content containing a null byte in
the middle,
2) demo_bug.py - the Python scripts, which decodes only 37 bits (run it
and it will produce the 37 bit long demo_out_0.bin)
If you run:
dmtxread demo.png > demo_ok.bin
you'll get the 111 bytes long demo_ok.bin with correctly decoded data.

Of course in my workaround.py there was a mistake. Instead of:

     img.save("code.png")

there should be:

    ic.save("code.png")

Based on the fact that dmtxread correctly handles decoding of data
containing null bytes I have created a temporary workaround.
The result of decoding in Python is used only to identify the rectangle
containing the code.

That rectangle is then saved to the file and os.system is used to decode
it with dmtxread.

It is a "quick & dirty" solution, but at least works...

I have tested my workaround on a bigger image with the code and found
that pydmtx reverses the coordinates.
Calculation of the box used to export the code must be more complicated:

     # We need to introduce certain margin when exporting the rectangle
with the code
     margin = 10
b=(r.left-margin,img.size[1]-r.top-r.height-margin,r.left+r.width+margin,img.size[1]-r.top+margin)