Writing data sets with encapsulated pixel data may have an unintuitive behavior

[Enet4]

The current data set writing capabilities via the object write_dataset methods allow the user to choose the transfer syntax of the output data:

let ts = TransferSyntaxRegistry.get("1.2.840.10008.1.2.1").unwrap();

obj.write_dataset_with_ts(&mut out, &ts)?;

However, the methods do not check whether the object's pixel data encoding matches the requested output transfer syntax. It merely passes over the pixel data as is, either as native encoded pixel data or as a sequence of fragments. They were designed this way so that this implementation does not have to check the pixel data and other properties to identify how it was encoded. However:

1. There may be interest in converting from one pixel data encoding to another in an almost seamless fashion.
2. It may be surprising to read a DICOM object from a file and then write the data set to a channel as part of a networking service, and realize that no pixel data conversion was done, leading to an inconsistent object at the destination.

This might only be tackled when the image abstraction becomes available, but it's worth recording this concern for now.

[hmeine]

FWIW, one edge case to keep in mind is multi-frame binary image data. The standard specifies that no padding should be applied between frames, which means that frames beyond the first do not necessarily start at a byte (let alone word) boundary. Sorry, just a "voice from the off", because I recently dealt with an issue in a (C++) implementation in that regard.

[Enet4]

@hmeine That's a good gotcha to keep in mind, thanks. Does that apply to transfer syntaxes with encapsulated pixel data? I suppose that these concerns will arrive when implementing the base image abstraction.

[hmeine]

I am afraid I cannot answer that one, sorry. :-)

[Enet4]

#408 provides a solution, although it will continue to be true that write_datset does no transcoding.