Compatibility with multiframe pixel data via GDCM

[ingwinlu]

I have been looking to extract images from dicoms that are encoded via "JPEG_LOSSLESS_NON_HIERARCHICAL_FIRST_ORDER_PREDICTION". With the gdcm feature this also worked nicely as long as it was single frame. However I also have series of images per file where I run into https://github.com/Enet4/dicom-rs/blob/master/pixeldata/src/gdcm.rs#L56.

I have been looking around how pydicom (what we currently use mostly) does this in combination with pillow and thought a similar approach could be implemented for dicom-rs (build on top of the image crate so it should also be fully rust). https://github.com/pydicom/pydicom/blob/master/pydicom/pixel_data_handlers/pillow_handler.py A similar decoder to https://github.com/Enet4/dicom-rs/blob/master/encoding/src/adapters/rle_lossless.rs where we point the image crate to the u8 vectors that represent each image.

Before I invest a lot further time, is this something you would consider merging if I provide an implementation? Does it need to be gated behind a feature flag (and do you have a recommendation on how to implement it)? Maybe other things that could go wrong that I might have missed and makes the above approach unfeasible?

[Enet4]

Thank you for reporting, @ingwinlu. It's true that some efforts of the pixeldata component are ongoing, and not all of them are tracked by issues yet (although there is a catch-all: #125).

I have been looking around how pydicom (what we currently use mostly) does this in combination with pillow and thought a similar approach could be implemented for dicom-rs (build on top of the image crate so it should also be fully rust).

Unless I misunderstood you, DICOM-rs already has a backbone for this:

• A registry of transfer syntaxes with pixel data encoding/decoding handlers, so that the right decoder is picked based on the given object's transfer syntax;
• A set of methods and types for turning the decoded pixel data into an image (also integrated with the image crate).

What indeed could be done, is add a native implementation of a transfer syntax for JPEG decoding. I was surprised to see that jpeg-decoder seems to support JPEG lossless since version 0.2.0, so it could be used here.

Before I invest a lot further time, is this something you would consider merging if I provide an implementation? Does it need to be gated behind a feature flag (and do you have a recommendation on how to implement it)? Maybe other things that could go wrong that I might have missed and makes the above approach unfeasible?

A pull request which provides some JPEG-related transfer syntax implementations would be rather welcome! (See CONTRIBUTING.md if you haven't yet) I think RLE losssless isn't feature-gated yet, so it would be fine if the pull request followed a similar pattern, so gating can be done later. There is only no need to add image directly for the decoding process, jpeg-decoder should have what we need.

[ingwinlu]

I think this can be closed now