storing Dicom/ changing dicom file

[uzleuven]

Hi,

I was sending Dicom images to dcmtk (storescp), and it seems the size changed (sometimes) remarkable, so can anyone tell me why this happens? (Is it completing the Dicom fields...?) Or maybe some kind of compression??

Best regards,

Jan

[Michael Onken]

Hi Jan,

a single DICOM image can be encoded differently. Besides other characteristics, the compression of the pixel data can be changed, e. g. from JPEG Lossless Compression to uncompressed. Different encodings are called Transfer Syntaxes. Basically, the Transfer Syntax of an image can be changed over time for different purposes, and is actually changed often by image archives etc. or when burnt onto a DICOM CD.

For network transmission, client and server (storescp) first negotiate which encoding should be used for transmission. If storescp is configured only to accept uncompressed transfer syntaxes then the sender has to decompress any compressed images first before sending. storescp then stores the uncompressed image to disk. This may be the reason for the size difference.

To check that, run dcmdump on the file before sending and after receiving by storescp. Most probably (if there is a large size difference) the Transfer Syntax has changed (should be printed by dcmdump in the first few lines).

Regards,
Michael

[uzleuven]

Hi,

Thanks for the reply.

In fact the TransferSyntax was changed and also the Private Data was removed. Is there a way to keep all this data, there we need it for analysis.

Best regards,

Jan

[Michael Onken]

Hi Jan,

I guess the sender has removed that information. storescp does not discard any private data from received files.

And: Are you sure the private tags (you can recognize them by their odd group numbers) are missing? Or does dcmdump list them but does not list the attribute names (and instead shows Unknown Tag and Data). The latter would be the case because dcmdump can't know any private attribute names unless they are added to the dicom dictionary dicom.dic (or use private.dic), see documentation.

Regards,
Michael

[uzleuven]

Hi Michael,

First of all, thanks for the usefull replies!

The size is, as you mentioned, caused by the decompression (if I use the +cl option it should be compressed again??)

I've sent also to another storescp and the comparison of the dcmdump files shows threre is missing a lot..

Is it possible to send you these files?

Regards,

Jan

[Michael Onken]

Hi Jan,

Hi Michael,
if I use the +cl option it should be compressed again??

Yes but storescp will then use a ZLIB-based (ZIP) transfer syntax called Deflated which probably works not as good as image-specific compression methods. Probably the image was compressed using another compression (transfer syntax). Some compression schemes are only useful for specific kind of images; Deflated is most useful for DICOM's non-image objects like ECGs. But just give it a try.

If you want to try out JPEG compression, use the tool dcmcjpeg to change to a JPEG based transfer syntax. Per default it applies a lossless JPEG compression. If you want to try out a lossy (caution, that affects image quality) JPEG, try switch +eb for example.

I've sent also to another storescp and the comparison of the dcmdump files shows threre is missing a lot..
Is it possible to send you these files?

If you like, send them to dicom at offis dot de .

Regards,
Michael

[Michael Onken]

Hi,

I checked the files you sent me. You are right, in the file received and stored by storescp the private data is missing that is still available in the same file you received with DCM4CHEE.

However, the DCM4CHEE PACS obviously was configured to receive the image in compressed JPEG baseline transfer syntax which is probably the one originally used by the Ultrasound machine. So in my humble opinion the sender deletes the private data when decoding the image for uncompressed transmission.

If you want to receivethe file in JPEG Baseline, use the configuration file for storescp to tell what exactly should be accepted (see file storescp.cfg in dcmnet/etc/ as an example). Or, for a quick try, use storescp --prefer-jpeg8 option to also accept JPEG Baseline.

Regards,
Michael

[uzleuven]

If you want to receivethe file in JPEG Baseline, use the configuration file for storescp to tell what exactly should be accepted (see file storescp.cfg in dcmnet/etc/ as an example). Or, for a quick try, use storescp --prefer-jpeg8 option to also accept JPEG Baseline.

My config file is set in a way that all image data can 'negotiate' with AnyTransferSyntax
I also tried the option you suggested but it keeps using LittleEndianExplicit

On the other hand, I'm not sure if this will 'bring back' my private tags...?

Regards,

Jan

[Michael Onken]

Jan,

The problem is that when storescp answers the client that it is ok for any transfer syntax, then the client can decide which one it uses. In your case, it seems the client then prefers uncompressed (if your configuration is correct). Also start storescp with -v -d to see what exactly is negotiated.

As I explained storescp does not remove ANY tags (most probably!), but the sender does when sending uncompressed ultrasound images. So, try the option --prefer-jpeg8 as stated above and you find out within 10 seconds whether it works and the private tags are preserved.

Best regards,
Michael

[uzleuven]

Hi,

I've sent the verbose print of the negotiation because I was not sure if the ?proposed syntax? is proposed by client or server?

regards,

Jan

[Michael Onken]

Hi Jan,

Their Max PDU Receive Size: 16352
Presentation Contexts:
Context ID: 1 (Proposed)
Abstract Syntax: =UltrasoundImageStorage
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Proposed Transfer Syntax(es):
=LittleEndianExplicit
=LittleEndianImplicit

Here the client proposes only a single presentation context for Ultrasound. This presentation context only offers Little Endian Explicit and Little Endian Implicit (here the client could list different encoding possibilities from which the server selects one). This is what the server (storescp) responds:

Presentation Contexts:
Context ID: 1 (Accepted)
Abstract Syntax: =UltrasoundImageStorage
Proposed SCP/SCU Role: Default
Accepted SCP/SCU Role: Default
Accepted Transfer Syntax: =LittleEndianExplicit

It accepts the Presentation Context and can select a single Transfer Syntax inside. Because two times uncompressed Transfer Syntaxes are proposed, it has no other chance than accepting -- guess what -- an uncompressed one, which, in that case is Little Endian Explicit. If you want to accept Little Endian Implicit VR than you could use --implicit . Maybe that also will give you original private data but you can only find out by trying. If the sender (in that case dcm4chee) does not want to send ANY private data in ANY transfer syntax then there is no chance forcing it.

So in the (second mail) log you sent me storescp has no other chance than accepting only an uncompressed variant which then of course is also sent by the client.

Regards,
Michael

----
RE-EDITED by Michael (overlooked that there were two transfer syntaxes proposed, not only one)