questions > Weird CSA 'ProtocolSliceNumber' & Check that 2D images are not mirrored
Showing 1-2 of 2 posts
May 10, 2022 09:05 PM | Giorgio Papitto
Weird CSA 'ProtocolSliceNumber' & Check that 2D images are not mirrored
Dear community,
I used the following code to convert my DICOM files:
for x in {1..32}; do "THIS IS SUBJECT $x"; dcm2niix -o /sub_$x/func /rawdata_renamed/sub_$x/DICOM; done; echo "I'm done"
Once I looked at the output in the terminal I noted that for every participant I had the following warnings:
*WARNING n. 1: Weird CSA 'ProtocolSliceNumber' (System/Miscellaneous/ImageNumbering reversed): VALIDATE SLICETIMING AND BVECS
*WARNING n. 2: Check that 2D images are not mirrored.
I should I make sure that the slice timing is correct and that the images are not mirrored?
Best
I used the following code to convert my DICOM files:
for x in {1..32}; do "THIS IS SUBJECT $x"; dcm2niix -o /sub_$x/func /rawdata_renamed/sub_$x/DICOM; done; echo "I'm done"
Once I looked at the output in the terminal I noted that for every participant I had the following warnings:
*WARNING n. 1: Weird CSA 'ProtocolSliceNumber' (System/Miscellaneous/ImageNumbering reversed): VALIDATE SLICETIMING AND BVECS
*WARNING n. 2: Check that 2D images are not mirrored.
I should I make sure that the slice timing is correct and that the images are not mirrored?
Best
May 10, 2022 09:05 PM | Chris Rorden
RE: Weird CSA 'ProtocolSliceNumber' & Check that 2D images are not mirrored
The issue with the ProtocolSliceNumber is described here.
https://crnl.readthedocs.io/stc/index.html
The scans were specified on the console with reversed slice numbering. This only impacts how slices are ordered in the 2D mosaic, not how images are acquired. I would urge you to heed Siemens warnings on acquiring data this way. While I assume dcm2niix works correctly, I have not tested all the possible edge cases. You will want to rigorously evaluate the data to ensure it is correct. The big fear is that the slice timing numbers might be reversed or the diffusion gradients reversed.
For MRI image processing, we are only concerned with 3D scans, in general the 2D scans are localizers that are used to plan subsequent scans. I always use the dcm2niix -i y to ignore these scans.
https://crnl.readthedocs.io/stc/index.html
The scans were specified on the console with reversed slice numbering. This only impacts how slices are ordered in the 2D mosaic, not how images are acquired. I would urge you to heed Siemens warnings on acquiring data this way. While I assume dcm2niix works correctly, I have not tested all the possible edge cases. You will want to rigorously evaluate the data to ensure it is correct. The big fear is that the slice timing numbers might be reversed or the diffusion gradients reversed.
For MRI image processing, we are only concerned with 3D scans, in general the 2D scans are localizers that are used to plan subsequent scans. I always use the dcm2niix -i y to ignore these scans.