You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 (Decode a single frame via object pixel data decoding API #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.
The text was updated successfully, but these errors were encountered:
Enet4
changed the title
[encoding] Pixel data decoder is too eager and always returns bytes
Pixel data decoder is too eager and always returns bytes
Dec 10, 2022
There are currently two known limitations with the
PixelRWAdapter::decode
signature.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.The text was updated successfully, but these errors were encountered: