Siemens XA60 warning slice timing

[ndolf]

Describe the bug We recently started acquiring data on a Siemens Magnetom Prisma Fit (software version syngo MR XA60). We export our data using the enhanced dicom format and the scanner uses the latest release of the multi-band accelerated EPI sequences developed by CMRR. We get several warnings on slice timing when running dcm2bids. According to a colleague the source of the warning can be traced back to the function checkSliceTiming.

Should we worry about this?

Thank you!

Warnings

WARNING | Chris Rorden's dcm2niiX version v1.0.20240202 MSC1929 (64-bit Windows) Found 1140 DICOM file(s) slice orientation varies (localizer?) [0 1 0 0 0 -1] != [1 0 0 0 0 -1] CSA slice timing based on 2nd volume, 1st volume corrupted (CMRR bug, range 680..1350, TR=679 ms) Convert 1 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\007_sub-01_fmap-gre_acq-siemens_20240924142759_e2_ph (104x104x69x1) Convert 1 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\004_sub-01_GIfMI_T1_MPRAGE_20240924142759 (230x230x60x1) CSA slice timing based on 2nd volume, 1st volume corrupted (CMRR bug, range 0..4272.5, TR=1500 ms) Convert 381 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\010_sub-01_FUNC_RUN3_20240924142759 (104x104x72x381) Convert 1 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\002_sub-01_GIfMI_T1_MPRAGE_20240924142759 (256x256x176x1) Convert 1 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\003_sub-01_GIfMI_T1_MPRAGE_20240924142759 (230x230x60x1) Warning: Slice timing appears corrupted (range 0..6990, TR=7.5 ms) Convert 1 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\001_sub-01_localizer_20240924142759 (512x512x3x1) CSA slice timing based on 2nd volume, 1st volume corrupted (CMRR bug, range 0..4272.5, TR=1500 ms) Convert 372 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\009_sub-01_FUNC_RUN2_20240924142759 (104x104x72x372) CSA slice timing based on 2nd volume, 1st volume corrupted (CMRR bug, range 0..4272.5, TR=1500 ms) Convert 373 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\008_sub-01_FUNC_RUN1_20240924142759 (104x104x72x373) Slices not stacked: echo varies (TE 7.38, 4.92; echo 2, 1). Use 'merge 2D slices' option to force stacking CSA slice timing based on 2nd volume, 1st volume corrupted (CMRR bug, range 680..1350, TR=679 ms) Convert 1 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\006_sub-01_fmap-gre_acq-siemens_20240924142759_e2 (104x104x69x1) Convert 1 DICOM as E:\Data Simone\BIDS_Data_V2\tmp_dcm2bids\sub-01\006_sub-01_fmap-gre_acq-siemens_20240924142759_e1 (104x104x69x1)

Version INFO | Running the following command: dcm2bids -d sourcedata/sub-01/ -p 01 -c code/dcm2bids_config.json INFO | OS version: Windows-10-10.0.19045-SP0 INFO | Python version: 3.11.10 | packaged by Anaconda, Inc. | (main, Oct 3 2024, 07:22:26) [MSC v.1929 64 bit (AMD64)] INFO | dcm2bids version: 3.2.0 INFO | dcm2niix version: v1.0.20240202 INFO | Checking for software update INFO | Currently using the latest version of dcm2bids. INFO | Currently using the latest version of dcm2niix.

[neurolabusc]

I see you are using the current stable branch (v1.0.20240202) which pre-dates XA60. Searching prior issues reveals that some XA60 DICOM tags are not truthful. Can you please test with the current development branch (v1.0.20241022) which includes kludges to handle these. I would also suggest you contact the Siemens Research Collaboration Manager to get the service patch once it is released.

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix ....

[ndolf]

Thanks Chris for the swift reply! Can you give more detailed instructions to run the development branch on Windows? I was able to download from github but next don't manage to get it to work with make/cmake.

[neurolabusc]

You can get a precompiled copy of the latest dcm2niix from AppVeyor:

1. go to the dcm2niix web page
2. click on the AppVeyor build:passing badge
3. click on the win link for Windows
4. click on artifacts button
5. click on the dcm2niix_win.zip file to download

[ndolf]

sorry Chris, I don't get this to work.

I downloaded the zipped folder from appveyor as suggested then went to the terminal:

cd C:\Users\ndolfen\Downloads\dcm2niix_win
python -m pip install dcm2niix
dcm2niix 

output: 100%|███████████████████████████████████████████████████████████████████████████████| 448k/448k [00:00<00:00, 45.9MB/s] Extracting: 100%|███████████████████████████████████████████████████████████████████████████| 946k/946k [00:00<?, ?B/s] Compression will be faster with C:\Users\ndolfen\AppData\Local\Programs\Python\Python312\Lib\site-packages\dcm2niix\pigz.exe in the same folder as the executable Chris Rorden's dcm2niiX version v1.0.20240202 (JP2:OpenJPEG) (JP-LS:CharLS) MSC1938 (64-bit Windows) usage: dcm2niix.exe [options]

What do I do next? I think I simply don't know how to run dcm2niix from the command line without going back to the other dcm2bids version.... (I tried a few things but without success)

[neurolabusc]

You can run it like any command line option. See the manual for details. So a minimal usage would be:

dcm2niix E:\Data Simone\Path\To|DICOM\Folder

[ndolf]

It was because of the space in the path name - but I don't manage to install and run the proposed version - it keeps giving me v1.0.20240202. Any chance I could just share the data with you?

[neurolabusc]

@ndolf can I suggest you reach out to the Siemens Research Collaboration Manager associated with your center to validate the conversion. It looks to me like all the warnings reflect issues introduced by XA60 where kludges to the development branch of dcm2niix should resolve the issues. However, I do not have access to or experience with XA60, so this is outside my expertise. It is the responsibility of your RCM is to mitigate this issue and ensure you get the patch that ensures you create valid DICOMs. Hopefully, they will also provide a tool to fix existing DICOMs to ensure they are valid and of archival quality. This is a limitation of the DICOM images generated by this manufacturer, not dcm2niix (which assumes DICOMs are valid and truthful).

[pvdemael]

I work with @ndolf . I was able to compile the dev version and test on a Macbook M3 Pro running Sequoia. Is this due to XA60 or rather the CMRR implementation?

Below is the output of the dev branch and the current stable branch respectively for a single functional run.

(testenv) ➜  sub-01-sorted ./dcm2niix -b y -f %s_%z_%p FUNC_RUN1_Series0008
Chris Rorden's dcm2niiX version v1.0.20241025  Clang16.0.0 ARM (64-bit MacOS)
Found 373 DICOM file(s)
Warning: Issue870: Slice timing range of first volume: range 0..4272.5, TA= 4272.5, TR=1500 ms)
Warning: Issue870: Slice timing range of 2nd volume: range 14692.5..16112.5, TA= 1420, TR=1500 ms)
Convert 373 DICOM as FUNC_RUN1_Series0008/8_FUNC_RUN1 (104x104x72x373)
Conversion required 0.732352 seconds (0.442258 for core code).

(testenv) ➜  sub-01-sorted dcm2niix -b y -f %s_%z_%p FUNC_RUN1_Series0008
Chris Rorden's dcm2niiX version v1.0.20240202  Clang16.0.0 ARM (64-bit MacOS)
Found 373 DICOM file(s)
CSA slice timing based on 2nd volume, 1st volume corrupted (CMRR bug, range 0..4272.5, TR=1500 ms)
Convert 373 DICOM as FUNC_RUN1_Series0008/8_FUNC_RUN1a (104x104x72x373)
Conversion required 0.671759 seconds (0.497579 for core code).

The diff of the corresponding JSON files:

        "BodyPart": "BRAIN",                                  |         "BodyPartExamined": "BRAIN",
        "StudyDescription": "Sequence Region Customer Sequenc <
        "ImageType": ["ORIGINAL", "PRIMARY", "FMRI", "NONE",  |         "ImageType": ["ORIGINAL", "PRIMARY", "FMRI", "NONE"],
        "TablePosition": [                                    <
                0,                                            <
                0,                                            <
                -0      ],                                    <
        "ConsistencyInfo": "66010002",                        <
        "ConversionSoftwareVersion": "v1.0.20241025"          |         "ConversionSoftwareVersion": "v1.0.20240202"
(base) vpnk153:FUNC_RUN1_Series0008 pvdemael$ diff -y --suppress-common-lines 8_FUNC_RUN1a.json 8_FUNC_RUN1.json 
        "BodyPartExamined": "BRAIN",                          |         "BodyPart": "BRAIN",
                                                              >         "StudyDescription": "Sequence Region Customer Sequenc
        "ImageType": ["ORIGINAL", "PRIMARY", "FMRI", "NONE"], |         "ImageType": ["ORIGINAL", "PRIMARY", "FMRI", "NONE", 
                                                              >         "TablePosition": [
                                                              >                 0,
                                                              >                 0,
                                                              >                 -0      ],
                                                              >         "ConsistencyInfo": "66010002",
        "ConversionSoftwareVersion": "v1.0.20240202"          |         "ConversionSoftwareVersion": "v1.0.20241025"

[neurolabusc]

@pvdemael the behavior you are describing is a duplicate of issue870 - you can see error with the provided XA60 dataset phantom_check_MBfactor_TerraX_XA60.zip. Specifically, both the CMRR and product DICOMs report the incorrect slice timings for the first volume of multiband data. Siemens has acknowledged the problem, so you should contact your Siemens Research Collaboration Manager to ensure you get a patch. This is a limitation with the images and not dcm2niix. The warning is warranted. I do believe the hludge included in the development branch of dcm2niix mitigates this problem, but my sample set is limited and I would not consider your DICOMs archival quality.