-1

I have 1 running server for handle C-Move, 2 running server for handle C-Store and remote pacs server(GEPACS)

When i tried to C-Move command from remote pacs to C-Store handler, 1 server(py-netdicom) is build and save the file properly and 1 server(go-netdicom) is not.

So there was couple of problems in go-netdicom. I fixed the code can handle hexadecimals. It originally not supported on go-netdicom. This was fix almost every problems in my case but still cannot store pixel data properly.

For example, I got 9117252 bytes from original signal from remote pacs and I saved the data itself, but actually it needs to be 18000000 bytes(got an error). even CT images are short for 3 times(got approximately 180000, but need 524288)

I think the problem caused by might be the encapsulation of pixel-data but not sure.

Is there any tip or some help?

Thank you.

EDIT 4: I've got a clue.link here

Somehow C-STORE command have a kind of transfer syntax. This offer to scp type(compressed or not) of data scu get. But still I don't have a idea which part of go-netdicom has to be changed. I'll delete "python" tag because this is not related with python anymore.

Moon
  • 11
  • 5
  • The reference to the private data elements has nothing to do with the problem - better delete the EDIT / EDIT2 / EDIT3 parts, as they only confuse matter. You seem to be on the right track regarding David Clunies post - all DICOM entities have to negotiate a transfer syntax they both can handle, which you can configure on both sides. – MrBean Bremen Feb 12 '20 at 07:55
  • MrBean// thx for advise. i agree. transfer syntax will be the key of this problem. but as i said, i really cannot find out what part would be changed. i'm looking "contextmanager" now. – Moon Feb 12 '20 at 08:29

2 Answers2

0

I found the solution.

Somehow, GEPACS send the certain transfer syntax for JPEG compression. if go-netdicom doesn't have the TransferSyntaxUID then pick the GEPACS's first transfer syntax and that was for JPEG compression.

i just put bigendian and explicitvr (GEPACS default) when transfersyntax is empty.

which placed in contextmanager.go line 101 on AssociateRequest, line 127

Hope this result help someone.

Thank you

Moon
  • 11
  • 5
  • Hint: BigEndian transfer syntax is deprecated for many years now, I wouldn't use that. Little Endian Explicit VR should work almost always. – MrBean Bremen Feb 12 '20 at 10:16
  • Implicit Little Endian is the default Transfer Syntax for DICOM and must be supported by all DICOM conformant systems (with a few exceptions which are unlikely to apply in this case) – Markus Sabin Feb 12 '20 at 10:50
  • @kritzel_sw: true - though I haven't encountered anything that does not support Explicit Little Endian, too (thus the "almost always"), and Explicit Little Endian is generally easier to handle (for example regarding the VR of private tags), and I usually prefer it. But you are right... – MrBean Bremen Feb 12 '20 at 20:53
  • Thx for comment. In my case the default TransferSyntaxUID is "2.16.840.1.113709.1.2.2" which is ExplicitVRBigEndian according to GE officials. Please tell me if I'm wrong. – Moon Feb 12 '20 at 23:53
  • 1
    Transfer Syntax UID for Explicit Big Endian is 1.2.840.10008.1.2.2. According to the DICOM Conformance Statement of GE's Centricity PACS "2.16.840.1.113709.1.2.2" is a private TS named "COMPRESS_EXPRESS", and "It is expected that other vendors’ applications will ignore all Presentation Contexts proposed with the COMPRESS_EXPRESS Transfer Syntax.". See here: http://www3.gehealthcare.pl/~/media/documents/us-global/products/interoperability/dicom/radiology-pacs-ris/gehc-dicom-conformance_centricitypacs-v2-1_2017753-209_rev0-7.pdf – Markus Sabin Feb 13 '20 at 07:07
  • @kritzel_sw Thx for correcting me. maybe i saw wrong. – Moon Feb 19 '20 at 07:33
0

The problem here is that go-netdicom uses the first PresentationContext sent in the A_ASSOCIATE_RQ (As you can see in the last image). So it accepts "2.16.840.1.113709.1.2.2" which is a privative Transfer Syntax and it is not in the DICOM standart, so no one can manage the C-STORE at the end.

If you are reading this.. maybe you do not use go-netdicom but the problem could be the same if the error involves the transfer Syntax "2.16.840.1.113709.1.2.2", in the Centricity PACs documentation says: "It is expected that other vendors' applications will ignore all Presentation Context proposed with the GE Private Compress Express Transfer Syntax"

enter image description here

And that is what we are suppose to do. I see a list of PRs in go-netdicom so I suppose it is not mantained, so I will post the change for go-netdicom here. I made this changes in contextmanager.go and works like a charm:

enter image description here

Santi Iglesias
  • 454
  • 4
  • 11