Why dcm4che creates huge files when we send DICOM from CharruaSoft sendscu tool using different transfer syntax?

I have few 16 bit and 8 bit DICOM files which I am transferring to dcm4che StoreSCP using CharruaSoft sendscu tool.

It is working fine for 16 bit files but for 8 bit simple 2 MB file it generates a huge 90 MB file.

I tried to send using StoreSCU from dcm4che itself and it works fine. But from CharruaSoft SendSCU it creates huge files.

Steps to reproduce:

Download CharruaSoft SendSCU.
Setup dcm4che tool SCP maven project.
Run main method of java using the proper arguments given in --help.
Use CharruaSoft SendSCU to send a 16 bit DICOM, it works fine.
Now send a 8 bit DICOM, it works but creates a huge file, in my case 2 MB became 90 MB.

First of all, I thought it could be a CharruaSoft SendSCU problem but CharruaSoft SendSCU is able to send to other SCPs for eg: mymedicalimages.com properly.

Did anyone already faced similar issues?

Edit:

If I select JPEG lossy 8 bit compression from CharruaSoft sendscu, it works and doesn't create a huge 90 mb file.
But I have no control over CharruaSoft sendSCU tool. I want java dcm4che SCP to handle that.

Edit 2: It is also fine if I just override the transfer syntax with the correct one instead , so that it saves the dicom file as exact size file.

Solution

I debugged your issue with SendSCU.

I got an image with JPEG 2000 Lossy compression. I established a connection with my SCP with it and pushed the image.

Following is the Associate log:

Implementation Version:  CharruaSoft
Maximum PDU Size:        16384
Called AE Title:         remote
Calling AE Title:        local
Presentation Contexts:   1
  Presentation Context:  1 [Proposed]
      Abstract:  CT Image Storage
      Transfer:  Explicit VR Little Endian
      Transfer:  JPEG 2000 Image Compression
      Transfer:  Implicit VR Little Endian: Default Transfer Syntax for DICOM

Note that SendSCU is proposing just one presentation context (PC) with three transfer syntaxes in it. Now it is up to SCP which TS to accept. Good thing here is that, SCU is auto-detecting the original TS of image to be sent.

for 8 bit simple 2 MB file it generates a huge 90 MB file.

This is because your SCP is accepting first transfer syntax and send ASSOCIATE-ACCEPT back to SendSCU. SendSCU then (as expected) decompresses the image on the fly and hence the increase in size.

I tried to send using StoreSCU from dcm4che itself and it works fine.

I am sure StoreSCU must be proposing:

only one TS - the Lossy one OR
multiple TS each in separate PC. SCP accepts each PC. StoreSCU uses the best one - Lossy OR
multiple TS with Lossy TS at the top

In any of the above case, StoreSCU will not decompress the image and there will not be a size issue. May be you should get the similar log for it as did above.

CharruaSoft SendSCU is able to send to other SCPs for eg: mymedicalimages.com properly.

It is decision of SCP which TS to accept if multiple TS are proposed in one PC. As the SCP you mentioned is hosted on internet, most probably it accepts Lossy TS (to improve performance and save bandwidth) on priority and hence the resultant file size is small. You should check their Conformance statement. If you upload it here, I may help out a bit.

If I select JPEG lossy 8 bit compression from CharruaSoft sendscu, it works and doesn't create a huge 90 mb file.

Following is the Associate log in that case:

Implementation Version:  CharruaSoft
Maximum PDU Size:        16384
Called AE Title:         remote
Calling AE Title:        local
Presentation Contexts:   1
  Presentation Context:  1 [Proposed]
      Abstract:  CT Image Storage
      Transfer:  JPEG 2000 Image Compression
      Transfer:  Implicit VR Little Endian: Default Transfer Syntax for DICOM

Note that JPEG 2000 is the first TS proposed here. SCP accepts it and everything just works fine.

But I have no control over CharruaSoft sendSCU tool. I want java dcm4che SCP to handle that.

I never used dcm4che tool; I cannot help here. You can check dcm4che document to see how you can configure which TS to accept that is proposed in PCs. Hopefully, there is a setting/switch to handle that behavior. This is your only way to go if you want to handle this with SCP on the fly.

Other alternative is offline TS conversion with -t switch as explained here.

-t,--transfer-syntax <uid>
transcode sources to specified Transfer Syntax. At default use Explicit VR Little Endian