pydicom / pyjpegls Goto Github PK

I'd like to add support for:

• Decoding a buffer-like without having to go through an ndarray
• Returning the decoded image as a bytearray

Also, literally only just realised this already supports encoding (greyscale) to JPEG-LS...

pydicom's encoding backend expects encoders to take bytes rather than ndarray.

def  encode_to_buffer(src: bytes | np.ndarray, lossy_error, interleave_mode, **kwargs) -> bytearray: ...

Required kwargs for bytes: rows, columns, samples_per_pixel, planar_configuration, bits_stored.

Maybe add a separate function instead: encode_pixel_data(src: bytes, lossy_error: int = 0, **kwargs)

Currently, there are a few tests which do not work anymore because the test data has been removed.
Instead, some test files from the JPEG-LS conformance test have been added, but no automatic test exists for these.
Probably the old tests have to be completely rewritten to work with this test data.

The current version of CharLS used roughly corresponds to version 1.0, released in 2010.
The last released version of the actively manatained project is 2.4.1 from 2023, with many fixes in place.

The API has also changed, so that would also mean to adapt the wrapper code.
A possibility would also to include the CharLS code as a submodule, simliar to openjpeg in pylibjpeg-openjpeg.

And drop it for Python 3.7.

The release workflow will need some updates, too.

@mrbean-bremen do you mind inviting me on pypi so I can setup that side of things?

Also, do you want to review any PRs or are you happy for me to move fast and break things (as the saying goes)?

They're ending up a encoded as single component due to the use of interleaving 0, but interleaving 1 and 2 don't work due to an incorrect stride calculation.

Interleaving 0 is for single component, 1 and 2 for multi, so the interleaving value needs to be restricted based on the number of components.

Currently, there is no easy way to create a PyPi release with packages for different targets.
This can probably mostly be borrowed from the release workflow in pylibjpeg-openjpeg and pylibjpeg-libjpeg.
The targets may be the same ones, maybe remove Windows 32 bit, as I don't think it is still needed (though I may be wrong).