There are currently two known limitations with the PixelRWAdapter::decode signature.
[ ] It is an all or nothing operation: the decoder will decode all frames and push the decoded outcome onto the destination, even if there is interest in working with frames only on demand.
[x] Adapters can now read frames independently. In addition, If the consumer specifies the interest in a specific frame, it is currently possible to issue that only that frame is retrieved and decoded from an object (#421). However, this decoding is still done eagerly, before the user decides how to transform it. Due to the in-memory nature of the default DICOM object implementation, this may still be too expensive in more demanding modalities.
[ ] The solution so far has been to decode all data onto a Vec<u8>, which allows consumers to reuse memory for future decoding, but it exposes the decoded data in a way which may be slightly inconvenient to work with if Bits Allocated is greater than 8. Maybe there could be a nicer data structure giving the best of both worlds.
A future reiteration of the pixel data adapters should bring changes to the PixelRWAdapter interface to fulfill at least the first requirement. It is still unclear how far one can go with the second requirement.
There are currently two known limitations with the
PixelRWAdapter::decodesignature.Vec<u8>, which allows consumers to reuse memory for future decoding, but it exposes the decoded data in a way which may be slightly inconvenient to work with if Bits Allocated is greater than 8. Maybe there could be a nicer data structure giving the best of both worlds.A future reiteration of the pixel data adapters should bring changes to the
PixelRWAdapterinterface to fulfill at least the first requirement. It is still unclear how far one can go with the second requirement.