search

rordenlab / dcm2niix

dcm2nii DICOM to NIfTI converter: compiled versions available from NITRC
https://www.nitrc.org/plugins/mwiki/index.php/dcm2nii:MainPage
Other
894 stars 228 forks source link

vNavs from ABCD/MGH structurals on XA30 #716

Closed mharms closed 1 year ago

mharms commented 1 year ago

There are a couple issues with the conversion of the vNavs from the ABCD/MGH structural sequences on XA30 when the session is exported as 'Enhanced' DICOMs. (I don't know if the following would apply if they happened to be exported as 'Classic' DICOMs instead).

This is using the current public release version (v20230411), with the following naming string: -f '%s_%d_r%r_u%u'.

The first issue is presumably related to the fact that the vNavs are exported by the sequence still using the old MOSAIC format (and indeed have that tag in their ImageTypeText field), even when exported as Enhanced DICOM. The resulting NIFTIs are not "unpacked" from MOSAIC in the z-dimension, and most of them have a resulting dimension of 192x192x1x1. Hopefully, this can be straightforwardly addressed by checking the ImageTypeText tag for MOSAIC, and applying the code for handling the mosaic format in that situation.

However, the 2nd issue is that a small number of them are somehow getting lumped together with another DICOM during conversion, resulting in NIFTIs with dimensions of either 192x192x1x2 or 192x192x2x1.

I will send you a link to a set of DICOMs illustrating this.

mharms commented 1 year ago

I just emailed you an invite to an example data set on Box.

neurolabusc commented 1 year ago

@mharms, this appears to be a duplicate of issue 236 where Siemens asserts that mosaics secondary capture images intended for quality assurance only. The reason that some images are clumped together and others are separated is that the ImageOrientationPatient (0020,0037) varies. The NIfTI format requires a single spatial transform for all volumes in a series, so changes in alignment force the data to be segmented to encode this spatial position. It seems like dcm2niix is doing the best it can with this impoverished dataset. Perhaps you can write a Python script that gets details about the mosaic and spacing to reconstruct the data. You may want to engage your Siemens Research Collaboration Manager for help. However, my sense is the first step is to ensure that the data is not stored as mosaics: while this improved performance for VA, it leads to impoverished datasets for XA.

mharms commented 1 year ago

These are the navigators from the ABCD/MGH structural C2P sequences (which many sites will presumably be using eventually under XA30). I'm pretty sure that ImageOrientationPatient differed for the navs as well under VE11 as well for the output of this sequence. So, I guess what is happening here for the small number of frames that get lumped together into a single NIFTI is that ImageOrientationPatient is NOT differing (at least to the level of precision which is being checked)? I just realized that it should be relatively straightforward to work around that inconsistent lumping of frames together by just converting the vNav DICOMs one frame at a time (which now that I think about more, is I think the approach that we used for converting the navs under VE11 as well).

As for not storing the data as mosaics to begin with, that would be something the developer/maintainer of the sequence at MGH would need to take up, which I doubt would happen anytime soon. I take it that you are opposed to the hack I suggested of checking ImageTypeText for MOSAIC and if that exists applying the good-ol mosaic-related unpacking code?

neurolabusc commented 1 year ago

@mharms while ImageTypeText does report MOSAIC many other details are missing including the crucial NumberOfImagesInMosaic and ProtocolSliceNumber that existed in the VE11 CSA header as well as other useful information like slice timing and (for DWI sequences) gradient direction. This is a limitation of the impoverished XA mosaics, not dcm2niix. Scientists who wish to use XA for EPI data should always export enhanced data.

mharms commented 1 year ago

To be clear, users don't have a choice in this particular case. The data was exported as Enhanced, as can be confirmed from the SOPClassUID in (0002,0002). The problem is that presumably the sequence itself is forcing MOSAIC as the output format for the navigators. I'm not advocating for exporting non-enhanced data on XA30. But for these particular DICOMs we don't seem to have any say in the matter. That's why I'm exploring whether you might have another infamous 'hack' up your sleeve that would get these converted into a proper 3D volume. :)

neurolabusc commented 1 year ago

@mharms I do not have access to an XA system, so you really need to work through this with your Siemens Research Collaboration Manager and the sequence developers. I first raised concerns regarding the impoverished mosaics before the launch customer got their XA10. I understand Siemens' perspective that XA mosaics are for visual inspection only, but from VA-VE the mosaics had benefits, and therefore users and sequence developers have developed habits that are inappropriate for XA. The required meta data is simply missing from these images, so there is no hack to infer this information from other tags. In solving this, you also need to be aware of issue 553.

neurolabusc commented 1 year ago

Closing. The provided DICOMs are too impoverished to allow de-mosaicing. Solutions are:

  1. Export DICOMs without mosaicing.
  2. Have Siemens provide more meta-data for mosaics.
  3. Create custom script where users can provide missing details.