questions > Weird CSA 'ProtocolSliceNumber'
Showing 1-10 of 10 posts
Results per page:
Oct 18, 2017  01:10 PM | veronicas
Weird CSA 'ProtocolSliceNumber'
I am using dcm2bids which calls upon dcm2niix. When converting my functional scans I get the following Message:
Chris Rorden's dcm2niiX version v1.0.20170724 GCC4.4.7 (64-bit Linux)
Found 280 DICOM image(s)
slices stacked despite varying acquisition numbers (if this is not desired please recompile)

I read a couple of posts here and I get the impression that this has probably to do with Siemens CSA headers not being correctly specified.
I looked at the converted image in fslview and it seems fine (direction information is correct). fslhd tells me that acquisition has been correctly identified as "alternating_decreasing".
Is it safe to ignore the Warning?
I have also attached the resulting json file.

Thank you for clarifying,
Oct 19, 2017  10:10 AM | Chris Rorden
RE: Weird CSA 'ProtocolSliceNumber'
My software is generating this warning because I have never seen an image like this before, so you should excercise caution when processing the data. As you note, the image is correctly identified as 'alternating decreasing' slice order. However, Siemens images are typically stored to disk as a mosaic with the upper left being the most inferior slice and the lower right being the most superior, regradless of the order of acquisition. In this case, my software is not sure if this is correct, or if the upper left has the most superior slice. You will want to confirm the order of how slices are saved to disk, particularly if you want to perform slice time correction. If you want, you could send me a DICOM directly to my email address for me to validate. Otherwise, you will want to pay careful attention to this page

To quote the critical section of SPM12's slice timing help:
  Note that slice ordering is assumed to be from foot to head. If it is not, enter instead: TR - INTRASCAN_TIME - SLICE_TIMING_VECTOR'

In your case, I am not sure of the slice ordering of the raw data, as I have never seen this sitatuon.
Oct 19, 2017  01:10 PM | Chris Rorden
RE: Weird CSA 'ProtocolSliceNumber'
Hello, thanks for the sample images. As I suspected, the issue here is that the Siemens mosaic images are saved with the most superior slice saved in the upper left position. Fortunately, my software detects this and stores the images with the slice ordering from foot to head, which is what is assumed by SPM's slice timing routines. Assuming your data was acquired in INTERLEAVED DESCENDING order, you should have no problem slice timing these with my new slice timing script.
Oct 19, 2017  02:10 PM | veronicas
RE: Weird CSA 'ProtocolSliceNumber'
Wonderful! Thank you.
Oct 21, 2017  01:10 PM | Chris Rorden
RE: Weird CSA 'ProtocolSliceNumber'
  I have now acquired sample images and described Siemens image numbering. In contrast to what others have thought, it appears that changing image numbering changes how the images are saved to disk, but not how they are acquired. In other words, ASCENDING and INTERLEAVED axial sequences are always acquired in the foot>>head direction, regardless of image numbering. To quote the Siemens article I link "Do not use the mode H>>F because this complicates the numbering". The latest release of dcm2niix (v1.0.20171021) takes this into account when generating slice times, and the warning you get is a bit clearer 'Weird CSA 'ProtocolSliceNumber' (System/Miscellaneous/ImageNumbering reversed): VALIDATE SLICETIMING AND BVECS'.
Nov 22, 2018  06:11 AM | annabanana
RE: Weird CSA 'ProtocolSliceNumber'
Dear Chris Rorden,

i just found your post regarding the slice timing and image numbering in Siemens scanners. In my case the fMRI scanning procedure is interleaved. I checked the System/Miscellaneous/ImageNumbering in the MRI and unfortunatly it is posterior > anterior. When using your dcm2niix converter, I get the following warning: Weird CSA 'ProtocolSliceNumber' (System/Miscellaneous/ImageNumbering reversed). The slice timing in the .json data is now
0 15.375,00 0.0825, 16.175,00 0.1625, 1.7, 0.2425, 1.78, 0.325, 1.86, 0.405, 19.425,00 0.4875, 20.225,00 0.5675, 21.025,00 0.6475, 2.185,00 0.73, 2.265,00 0.81, 2.345,00 0.89, 24.275,00 0.9725, 25.075,00 10.525,00 25.875,00 11.325,00 2.67, 1.215,00 2.75, 1.295,00 2.83, 1.375,00 29.125,00 14.575
In the DICOM head the slice timing was reversed starting with the high values and ending with 0.
In your answer to Veronica your said "Fortunately, my software detects this and stores the images with the slice ordering from foot to head," When i understand correctly, this means that in my case the data in the nifti file is now ordered from anterior > posterior and thus the new slice timing starting with 0 in the .json is correct? And i can apply slice timing correction using these nifti files and .json data?

Thanks a lot!!
Nov 22, 2018  05:11 PM | Chris Rorden
RE: Weird CSA 'ProtocolSliceNumber'
  I would open up MRIcron and go to Preferences and make sure the "Reorient images" and "Rotate images" Checkboxes are unchecked - this will load your images as saved to disk. You can then confirm the slice order. I describe a simple method for confirming slice order on my web page
Nov 23, 2018  01:11 AM | annabanana
RE: Weird CSA 'ProtocolSliceNumber'
Thanks a lot for the quick reply!
I opened the data in MRIcron and unchecked the reorient image box. I could not find the rotate images check box though - where can i find this?
In the MIRcron Window-> Information the reorient section says that quaternion parameters and affine parameters are scanner position. In the fMRI section it says slice order is unknown. How else can I confirm the slice order in MRICRON of the NIFTI? I read your web page early but could not find out how to confirm slice order for the NIFTI after transforming from DICOM to NIFTI. Maybee I consequently overlook this, in this case I'm sorry..  I could only find out how to get the information for the DICOMS. The DICOM mosaics are coronar and ordered from the upper left being the most posterior to the lower right being the most anterior. This is in line with the MRI protocol: System -> Miscellaneous -> ImageNumbering posterior>anterior. However, as described earlier, the SliceTiming in the DICOM header and the .json have different orders. Thus I have to ensure the slice order change also with the conversion to NIFTI.

Thanks again for helping!!
Nov 23, 2018  05:11 AM | Chris Rorden
RE: Weird CSA 'ProtocolSliceNumber'
Hello, you may want to look at my comments on practiCal: the image numbering changes the order that slices are saved in the mosaic, not the order of acquisition.  Coronal is an unusual EPI acquisition: since the brain is shaped roughly like an American football, you can see the whole brain faster by acquiring axial or sagittal slices instead. Usually, coronal EPI are reserved for situations wher we are trying to get rid of artefacts. I validated the coronal acquisitions on our own Siemens scanner and you can see these images by looking at the dcm_qa validation dataset. It uses the method I mention on the web page I describe in the previous response: have the participant intentionally move their head during one EPI volume to validate slice order. Since your order is unusual, I would recommend you acquire this validation scan to ensure what is happening.

In MRIcron, unchecking the "reorient" and "rotate" options will show the data as saved to disk, so the Z-dimension shows your the order, with Z=1 being the first slice saved to disk.
Nov 23, 2018  06:11 AM | annabanana
RE: Weird CSA 'ProtocolSliceNumber'
Thanks a lot!!

if I remeber right, the coronar slicing, which was oriented using the hippocampus, was choosen to have a maximum high resolution of the hippocampus..
MRIcron, FLSview and SPM all show z=1 being the most anterior slice. So it seems that dcm2niix has reversed both, slice timing and slice order of the DICOMS.

Still I will check as you recommended. I will get the DICOM we have with a person moving out of the scanner, which will help for a final check.