Enhanced dicom via DCM SCP

[Tim Rosenow]

Hi there.

I am trying to send enhanced dicoms (diffusion data) via DICOM SCP to XNAT. During the transfer, they are converted to unenhanced DICOMs (and lose their 4th dimension and some metadata as a result). The compressed file uploader does not suffer this problem, so at least I know that XNAT can handle these files without problems.

My (admittedly lacking) understanding is that there is a negotiation at the start of transfer on whether enhanced DICOMs are acceptable, and if not, the dicoms are converted to unenhanced before sending. Can you please confirm whether the XNAT server accepts (and advertises its acceptance) of enhanced DICOM, and/or where I can see the receiver configuration?

Thank you!

[Charlie Moore]

Hi there Tim,

The list of SOP classes that XNAT will accept on a CSTORE should be represented by this array: https://bitbucket.org/xnatdev/xnat-web/src/fb469109b9b8535c20750fcbd6ce302e59ced6ed/src/main/java/org/nrg/dcm/scp/CStoreService.java?at=master#lines-59:205 . The first step would be to confirm that the particular SOP class you're referring to [there are several Enhanced SOP classes] is in that list. If it isn't, let me know so we can fix it :). I'll assume it is for the rest of this discussion.

My guess is that whatever client you're using to do the C-STORE is favoring classic SOP classes for the negotiation. If it's something like storescu from dcmtk, there's some flags on SOP class preferences, I believe. If it's directly from the modality, those often have configurations on how to handle it. For an example [and probably way to much detail] on some issues around this type of thing with Siemens XA30 data, I found these threads pretty illuminating:

1. https://github.com/CMRR-C2P/MB/issues/312

2. https://github.com/rordenlab/dcm2niix/issues/236

Hope that helps.

Thanks,

Charlie Moore

[David Clunie]

It is hard to tell whether or not your list in the source seems incomplete wrt. the current standard, or not. E.g., I initially thought it was missing the legacy converted enhanced MF SOP Classes, etc., but then I see they are present via they UID strings rather than a keyword - is there some reason they are specified that way (underlying toolkit that supplies the keywords not up to date perhaps?)? See https://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_B.5.html#table_B.5-1

[Charlie Moore]

> underlying toolkit that supplies the keywords not up to date perhaps?

Unfortunately, you're exactly correct: XNAT is still heavily tied to dcm4che2, which has long since moved on to dcm4che5. I would definitely be surprised if the list currently in XNAT contained everything currently in the standard, but it's usually "good enough" for most uses of XNAT.

Thanks,

Charlie Moore

[Tim Rosenow]

Thanks for your responses. Yes, the SOPClassUID is EnhancedMRImageStorage, which is in the array listed. That is encouraging - I will try to snoop the client/server negotiation to see if it is a client preference issue. It's reassuring that XNAT does in fact support this storage format with C-STORE.

Side note: here is the metadata from the scan stored on XNAT

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 192                                      #   4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01                                    #   2, 1 FileMetaInformationVersion
(0002,0002) UI =EnhancedMRImageStorage                  #  28, 1 MediaStorageSOPClassUID
(0002,0003) UI [2.16.756.5.5.200.8323328.68896.1655776218.58.3.0] #  48, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianExplicit                    #  20, 1 TransferSyntaxUID
(0002,0012) UI [1.2.40.0.13.1.1]                        #  16, 1 ImplementationClassUID
(0002,0013) SH [dcm4che-2.0]                            #  12, 1 ImplementationVersionName
(0002,0016) AE [Bruker]                                 #   6, 1 SourceApplicationEntityTitle

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
(0008,0005) CS [ISO_IR 192]                             #  10, 1 SpecificCharacterSet
(0008,0008) CS [ORIGINAL\PRIMARY\DIFFUSION\NONE]        #  32, 4 ImageType
(0008,0012) DA [20220621]                               #   8, 1 InstanceCreationDate
(0008,0013) TM [105025]                                 #   6, 1 InstanceCreationTime
(0008,0014) UI [2.16.756.5.5.1020.360.13.24.30]         #  30, 1 InstanceCreatorUID
(0008,0016) UI =EnhancedMRImageStorage                  #  28, 1 SOPClassUID
(0008,0018) UI [2.16.756.5.5.200.8323328.68896.1655776218.58.3.0] #  48, 1 SOPInstanceUID
...

[Tim Rosenow]

Hi all.

It looks like this is not an XNAT problem but a more general issue with either the way these DICOMs are encoded (from Bruker) or some other DCM transfer protocol misery. When transferring via C-STORE to *any* server I've tried (not just XNAT but even locally to my own via a number of listening services), all of the tags "Sequence with undefined length" are converted to "Sequence with explicit length," and I'm not convinced that the explicit lengths are correct because the data becomes corrupted.

I've contacted Bruker about whether it's a standards implementation error with their DICOM files, but in the meantime I'm just going to use the REST client to upload files and be done with it.

[Steve Moore]

For others interested in this topic, I have worked with Tim on this issue. I believe that this is happening:

1. Scanner software or other software (dcm4che, dcmtk) sends the DICOM file to XNAT using C-Store.
2. As XNAT receives the files, they are written to disk with sequence encoding that uses undefined lengths.
   1. You can find that description here: https://dicom.nema.org/medical/dicom/current/output/html/part05.html#sect_7.5
   2. I purposely did not say if the sending application sends these with undefined lengths or if the XNAT receiver does something. That requires more research. In either case, it is not wrong to encode sequences using undefined lengths.
      
3. The dump programs from dcm4che and dcmtk can dump the files after written to disk.
4. David Clunie's dciodvfy flags a number of problems with missing attributes in both the original file from the scanner (defined sequence lengths) and the file after upload to XNAT (sequences with undefined lengths). The errors flagged are the same, and no errors are flagged with basic element/sequence encoding.
   
5. Tim uses the MRtrix3 package, and I tried that locally. Sure enough, that program coughed up a hairball on this file.

I then used dcm4che to rewrite the file using sequences encoded with defined lengths. That same analysis program was happy with that version.

I wrote to Tim and think the problem is understood but not necessarily solved. I think there is a bug in the analysis package. I will do a little more work and log and ticket with the folks who maintain the package.

This leads me to another question. Does anyone use the mrtrix3 container within XNAT? Is there any interest in making sure this container works with the XNAT Container Service? I would be especially interested for anyone involved in small animal imaging as I am spending more time in that area.

Steve Moore

Washington University / St. Louis

[Tim Rosenow]

Thanks Steve. I can/will raise with the mrtrix team regarding their support for this particular encoding. I see that FSL supports this encoding and loads the images, so it looks like it is in fact an mrtrix missing feature rather than an XNAT or dcm4chee issue. Interesting! I suspect that there will be demand for mrtrix support with XNAT as it's a popular diffusion imaging analysis tool in preclinical and clinical imaging.

--
You received this message because you are subscribed to a topic in the Google Groups "xnat_discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xnat_discussion/8HvBDU1GT7c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/a4cf216c-bb2b-4eeb-8259-9ca47aa1796cn%40googlegroups.com.

[Tim Rosenow]

MRtrix3 bug report here:

https://github.com/MRtrix3/mrtrix3/issues/2690

[Tim Rosenow]

Issue has been resolved

https://github.com/MRtrix3/mrtrix3/pull/2691

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/c87f54af-7dbc-4127-af02-1364e876828en%40googlegroups.com.