Add possibility to remove default Implicit VR Little Endian transfer syntax when acting as CStore SCU

[bjorn-malmo]

When transferring a video file (be it MPEG-2/MPEG-4 or HEVC), it is (probably) never feasible to convert it into native format.

With fo-dicom, all CStoreRequests always include the (mandatory) Implicit VR Little Endian transfer syntax, but in situations where a compressed video file is to be transferred, this is not desired, since the remote party may accept this transfer syntax if the "correct" one is not supported.
In a situation like this, I would rather get an association error indicating we could not agree on a common transfer syntax.

Therefore; I suggest adding a property in the CStoreRequest to allow the implementor to not include the default transfer syntax.

[mrbean-bremen]

Note that a PACS (e.g. a DICOM node that implements C-STORE and C-FIND/C-MOVE SCP) is required to support Implicit Little Endian, so setting this flag might be unexpected to clients in general. I still think that this is a valid use case, just nothing you want to set in the wild (e.g. with unknown clients).

[bjorn-malmo]

I use it as a client when transferring instances to a Pacs.
One specific situation that I've seen is when having a lossy Jpeg image (from a camera) that should be sent, and where the Pacs will prioritize the uncompressed Implicit VR over JpegProcess1 and only accept Implicit VR.
By only presenting the JPegProcess1 in this case, the Pacs will accept it and no reencoding is necessary.

[mrbean-bremen]

Right, that makes sense!

[gofal]

Dicom Standard makes it clear, that a client always has to offer the uncompressed version. In your sitution above, where the pacs decides to priorize uncompressed implicit VR, then it's the PACS decission, not yours. The PACS is responsible for storing the data and needs to have the chance to choose the compression.

Or when you want to send a video, where conversion to implicit is not possible, but the PACS rejects the mpeg transfersyntax, then the pacs simply does not support video and it makes no sense to send the data to that pacs.

I really want to downvote this issue, because it breaks DICOM Standard without really solving a problem. You as a client would like to avoid decoding a image and force the pacs to use your TS, while standard makes it very clear that is has to be the other way round: the server must have the choice.

It this a x/y problem? do you have issues decoding JpegProcess1 for example?

[bjorn-malmo]

I beg to disagree...

According to the standard PS3.5 section 10.1:

"In other words, every sending AE is required to be able to convert any Data Set it is going to transmit into the Default Transfer Syntax, regardless of the form in which it originally received or stored the Data Set, except in the cases of when the decompressed Pixel Data is too large to encode in the Default Transfer Syntax or is received in a lossy compressed form. In the case of lossy compressed Pixel Data, the sending AE is permitted to propose only the lossy compressed Transfer Syntax appropriate to the lossy form that was received. In the case of lossless compressed Pixel Data that is too large to encode in the Default Transfer Syntax, the sending AE is permitted to propose any appropriate lossless compression Transfer Syntax, not necessarily that in which the image was received, as an alternative to the Default Transfer Syntax."

You just have to love the massive amount of text in the standard ;)

... but I also see in the following section that in the Jpeg case described above, it is not according to spec - however for video files it is still valid to not present Implicit VR little endian.