who8mylunch/charpyls

JPEG-LS for Python via CharLS C++ Library

charpyls's Issues

Unit test attempts to import wrong version of data_io.py

While investigating a problem in issue #1, I noticed that the unit test is expecting to import an older version of the data_io.py module. That older version supported reading/writing from a large variety of file types, including the ENVI data types referenced in the unit test. The new version was brought in since the older could not be made open-source. The unit test code and data files need to be updated to work properly on other people's computers.

Example code exception

Environment: Centos 6 (64 bit) VM in VirtualBox 4.3.6 on Windows 7

Just installed CharLS and CharPyLS.
Copied the test/gray_raw.png to test/image.png

[root@dev01 jpeg_ls]# python2.7 example.py
Traceback (most recent call last):
File "example.py", line 15, in
data_buffer = jpeg_ls.encode(data_image)
File "/usr/local/lib/python2.7/site-packages/CharPyLS-1.0.0-py2.7-linux-x86_64.egg/jpeg_ls/CharLS.py", line 47, in encode
data_buffer = _CharLS.encode(data_image)
File "_CharLS.pyx", line 119, in _CharLS.encode (jpeg_ls/_CharLS.cpp:1721)
raise Exception('Invalid input data type %s' % data_image.dtype)
Exception: Invalid input data type object

Maintenance of CharPyLS?

First, I want to thank you for the work in this repo - we (at pydicom) very much appreciate it, and we have been using this it in pydicom for decoding JPEG-LS images for years (and would like to continue to do so).

I made a simple PR for Python 3.11 compatibility yesterday, and afterwards noted that there there hasn't been any activity in this repo for years, so under the assumption that the repo is not maintained anymore, I created a fork that has the PR integrated, and which we will use at least temporary.

If this repo is still maintained, and the PR(s) will be reviewed and eventually merged, we can remove that repo again. That would be the preferred option in my view.

Otherwise, there are a few options:

• the maintainer invites collaborators who are able to handle maintance in the future
• this repo is officially transferred to pydicom (in this case the other one will be removed), or another suitable organization, where more maintainers can be added
• this repo is archived and points to our fork for further development, possibly giving us also the possibility to publish new PyPi versions (by adding more maintainers in PyPi)

Of these options, I personally would prefer the transfer to pydicom, as it would avoid having a fork.

Last, if we get no response here, we will proceed with our fork and add a PyPi package of our own with a new name.

Thank you!

MacBook M1 nad CharPyLS

Hi!

Is possible to install CharPyLS on M1 MacBook?

Cheers!