Incorrect conversion of DWI data

[hjmjohnson]

Chris,

I am working to convert data into the BIDS format, but using the dcm2niix tool is resulting in the following warnings:

/scratch/johnsonhj/local/bin/dcm2niix -f sub-aaa_ses-001_dwi -b -z -o $(pwd)/output ${DICOM_DIR}

Chris Rorden's dcm2niiX version 15Aug2016 (64-bit)
WARNING: CSA 'ProtocolSliceNumber' SUGGESTS REVERSED SLICE ORDER: SPATIAL AND DTI COORDINATES UNTESTED

The generated json file is:
{
"Manufacturer": "Siemens",
"ManufacturersModelName": "TrioTim",
"MagneticFieldStrength": 3,
"FlipAngle": 90,
"EchoTime": 0.088,
"RepetitionTime": 9.1,
"EffectiveEchoSpacing": 0.000400005,
"SliceTiming": [
4.4375,
9.0075,
4.3075,
8.875,
4.1775,
8.745,
4.0475,
8.615,
3.9175,
8.485,
3.785,
8.355,
3.655,
8.2225,
3.525,
8.0925,
3.395,
7.9625,
3.265,
7.8325,
3.1325,
7.7,
3.0025,
7.57,
2.8725,
7.44,
2.7425,
7.31,
2.6125,
7.18,
2.48,
7.0475,
2.35,
6.9175,
2.22,
6.7875,
2.09,
6.6575,
1.9575,
6.5275,
1.8275,
6.395,
1.6975,
6.265,
1.5675,
6.135,
1.4375,
6.005,
1.305,
5.875,
1.175,
5.7425,
1.045,
5.6125,
0.915,
5.4825,
0.785,
5.3525,
0.6525,
5.2225,
0.5225,
5.09,
0.3925,
4.96,
0.2625,
4.83,
0.1325,
4.7,
0,
4.57 ],
"PhaseEncodingDirection": "j-"
}

Is this something that I should be worried about?

Additionally, when I load this into the Slicer application, the images always are incorrectly oriented.

Any advice would be greatly appreciated.

Thanks,
Hans

[hjmjohnson]

@chrisfilo Chris, I am afraid the the dcm2niix dwi converted data supplied to BIDS is not correctly oriented. I also think that the gradient directions may not be correct.

I am trying to diagnose which of the DWI files may be incorrect.

[neurolabusc]

Hans,
1.) The TE, TR, and slice timings all look plausible. The thing causes my software to generate a warning is the order of the slice timing reported in the Siemens CSA headers' "MosaicRefAcqTimes" tag. Specifically, all the Siemens and CMRR sequences I have used generate one of three slice orders: ascending, descending, and interleaved ascending. However, your CSA header suggests that the data was acquired as INTERLEAVED DESCENDING. Since this order was not available on any of our systems, it was not included in our validation dataset
https://www.nitrc.org/plugins/mwiki/index.php/dcm2nii:MainPage#Diffusion_Tensor_Imaging
2.) Can you provide specifics describing why the BIDS data is incorrect? Are the TE/TR/Slice Order not what was requested on the console? Again, to my eye they all look plausible, but the slice order is highly unusual. Is this a Siemens product, CMRR sequence or something else? What version Siemens software are you using (with TrioTim I would expect B17 or B19 for US users)?
3.) Do be aware that TR, TE, and SLICETIMING are reported in SECONDS (not ms) as required by the BIDS format (http://bids.neuroimaging.io/bids_spec1.0.0-rc2.pdf).
4.) I would strongly suggest you do the validation I suggest in the Word document at
http://people.cas.sc.edu/rorden/mricron/dcm2nii.html
The trick is that the Siemens DICOM files report gradients with respect to the scanner, while neuroimaging tools require them reported with respect to the imaging plane.
5.) I would be happy to look at a dataset, send me an email with a link to a sample DICOM dataset as well as the PDF export of the sequence.

-c

[neurolabusc]

Hans,

a.) Since I do not use or maintain slicer, can you tell me if the NIfTI images appear to have the corrected image orientation when loaded in MRIcroGL and SPM. My software should preserve the spatial transform in the SForm and QForm, so tools that use these should correctly display your image.
b.) I assume your data is acquired with the participant Head First Supine (reported as "HFS" in the DICOM header), right?

[hjmjohnson]

@neurolabusc Thank you for the comments. They are very helpful.

1. OK
2. BIDS data is all OK. I wanted to communicate that I was trying to put data into the BIDS format. There is no issue with the side-car json or the file naming.
3. I was aware of this. Thank you for reminding me.
4. This is helpful. I am trying to analyze data using both ITK/NAMIC tools and dipy tools. I understand the NAMIC approach very well, but your documentation is useful for understanding how many other tools require the data descriptions.
5. I've sent a private e-mail to a dropbox site. This is VERY helpful. Thank you for taking a look at this data (1 study has 200 scan sessions, and we have many other studies as well). Over the years of working on a 32 site study, we collected many different scanner variants of DWI data. You may be interested in our testbed of 39 DWI data variants that we used for converting to NRRD format: http://slicer.kitware.com/midas3/folder/1111

a) I spoke too soon here. I made a mistake when loading the data.
b) Yes.

Thanks,
Hans

[neurolabusc]

Hans-
Thanks for this sample image. I can process these images fine with FSL (for example, using my nii_dtibatch scripts). The output tensors from FSL's FDT look fine. The images look fine with MRIcron, SPM, MRIcroGL and FSLeyes (each of which reorient visualizations based on the spatial transforms). The volume appears upside down with FSLview (which does not replace data based on spatial transforms) but FSLview does show the spatial labels "I"inferior and "S"superior correctly. I agree Slicer has an issue with these volumes, but that seems to be an issue with slicer.

I do want to say that these are highly unusual images, and I have never been able to generate images like this from any Siemens scanners. Like most Siemens EPI images the 2D slices are saved as a mosaic image. However, typically the inferior slice is saved in the upper left and the image position increases superiorly as you read the columns, rows (just like we read English, so the order for an 8-slice volume is [1 2 3; 4 5 6; 7 8 -] with numbers representing increasing superior position not acquisition order. However, with your scans the most superior slice is in the upper left, so the order is [8 7 6; 5 4 3; 2 1 -]. This is reported in the CSA 'ProtocolSliceNumber' field. While my software seems to preserve slice position and diffusion vectors for your data, I would strongly recommend you acquire validation data for this (both DTI data as well as fMRI if you plan to do slice timing).

I have updated this project to include a couple of commented lines:
//UNCOMMENT NEXT TWO LINES TO RE-ORDER MOSAIC WHERE CSA's protocolSliceNumber does not start with 1
//if ((dcmList[dcmSort[0].indx].CSA.protocolSliceNumber1 > 1) && (sliceDir == kSliceOrientMosaicNegativeDeterminant))
// sliceDir = -1;
Uncomment the last two if you want to try to flip the image and dti vectors. You will want to test this, and probably change the NIfTI slice order flag accordingly. I think your images are so unusual it may not be worth validating this: the current conversion seems fine it just looks funny on tools that do not handle the spatial transforms thoroughly.

[malaterre]

Adding cross reference: https://groups.google.com/d/msg/comp.protocols.dicom/hKNsgnjS1vs/yKTyOVwvAQAJ

[neurolabusc]

@malaterre and @hjmjohnson - I have now acquired a sample dataset, described and provided links to provide insight for reversed Siemens Image Numbering. The image below shows an example where the image numbering is reversed and acquisition was set to interleaved. In the middle of this volume the participant moved his head from the canonical position to the head rotated toward the shoulder. As you can see, the acquisition was still in the head-to-foot order, even though the slices are saved in the reverse order (with the top left image in the mosaic being the most superior rather than the most inferior). I acquired samples with both the Siemens product and CMRR sequences. Therefore, this suggests that changing the image numbering changes how slices are saved to disk, but not how they are acquired. This is contrary to what others had suggested. The latest version of dcm2niix (v1.0.20171021) reorders both the slices and the slice times in a way that should make SPM happy. To reiterate the Siemens white paper I cite "Do not use the mode H>>F because this complicates the numbering" - this change appears to only complicate things, and it does not provide a method to acquire descending interleaved images.