Field mapping ( Siemens scanners)- dcm2niix output 2 BIDS

dcm2bids

#1

Dear Siemens users,

  1. For non- dcm2niix users:
    So- what is the standard way to split these combined 4d series to magnitude and phasediff?
    Going through the whole sequence, getting the indices (of changes from phase to magnitude) and splitting by them is the only way, or there is some shortcut for this?

  2. When using dcm2niix:
    (Sorry for the newbie question, but-)
    When converting Siemens gre_field_mapping sequences to the nifti format by running dcm2niix, one finds for the relevant series the following files:
    < something >_e1
    < something >_e1_eq_1

< something >_e2
< something >_e2_eq_1
< something >_e2_ph

How should one transform these to the magnitude and phase nii-s- which is which?
(Any reference for documentation regarding these suffixes?)

(I’ll try to write here which is which, according to the JSON data by Sunday. till then- if anyone has any reference- it would be helpful)

Many thanks


#2

Please see the links for the final post of dcm2niix issue 194. You can also look at the dcm2niix file naming. In brief, the “_e2” tells you it is the 2nd echo and the “_ph” identifies the phase image. The output of your files depends on what you have requested the scanner to store for you, but field maps often store some combination of phase, magnitude, real and imaginary images. I would suggest you use the latest v1.0.20180622 release as this has become smarter at naming field maps (particularly for Philips users).


#3

Many thanks!

BTW- regarding-

_Eq is specific to CT scans. These scans can be acquired with variable distance between the slices of a 3D volume. NIfTI asumes all 2D slices that form a 3D stack are equidistant. Therefore, dcm2niix reslices the input data to generate an equidistant volume.

Is this not relevant for MRI, too?

Thanks again!


#4

So, _e1, _e2 and
matches the following option in BIDS?

8.3.5.1 Case 1: Phase difference image and at least one magnitude image
Template:
sub-<participant_label>/[ses-<session_label>/]
fmap/
sub-[_ses-<session_label>][_acq-][_run-<run_index>]_phasediff.nii[.gz]
sub-[_ses-<session_label>][_acq-][_run-<run_index>]_phasediff.json
sub-[_ses-<session_label>][_acq-][_run-<run_index>]_magnitude1.nii[.gz]

i.e.- e2_ph should be renamed to- “phasediff
and _e1 and _e2 should be renamed to magnitude1 and magnitude2 respectively?

@ChrisGorgolewski-
I understand that this sequence (fm2d2r) is supported by BIDS.
Is it also supported by fmriprep?
Also- in BIDS the “IntendedFor” isn’t obligatory.
Is it obligatory for fmriprep?

Thanks again!


#5

Yes phasediff should work.

Yes - until this is fixed: https://github.com/poldracklab/fmriprep/issues/783


#6

NIfTI requires that all slices in a 3D volume have equidistant slices. Many CT sequences acquire thinner slices near the brain stem and fewer slices at the top of the head. For these we need to interpolate equidistant scans. In theory, it is possible to acquire a volume with variable slice distances, but it is very unusual: changing the slice thickness changes the SNR and changing the slice gap changes the interference between slices. Typically if dcm2niix generates an _Eq file from a MRI sequence it suggests that not all the DICOM files were transferred.

As noted in the links I sent, the naming of your files will be specific to how you have your sequence set up and how you have the reconstructor set up - if you look at datasets like ADNI you will see that across time they acquired the same fieldmap sequence but changed which file they saved. dcm2niix should detect magnitude, real, imaginary and phase images, but their is no DICOM convention for difference maps (stored as Hz). So make sure to carefully inspect your scans to determine the identity of the images.


#7

Thanks for your answer.

Regarding _eq: no missing dicoms, as far as I’ve checked*, but I’ve noticed a very weird behavior:
the same Siemens fmap sequence (fm2d2r) was executed two times in the experiment.
The number of dicoms in the executions are the same for all field maps series.
For one run- an _eq file was created by dcm2niix and for another fmap run- no _eq file was created.
Do you have any explanation for such a behavior?
(no missing dcms, same sequence, different handling by dcm2niix)

Regarding the type of the data acquired- after I’ve checked the data again-
it seems that I have some phase images and some magnitude images (not phase diffs, as I’ve mistakenly written).
My way to descriminate between phase diff and phase images was that in phase diffs- there should be multiple echo times…
So I guess that dcm2niix could apply this logic too…?

Many many thanks!


FMRIPREP: field mapping data
Dcm2niix Node Nonzero Exit Code
#8

For Siemens users who get “_Eq” images: this occurs because Siemens scanners can generate the same series (0020,0011) and instance (0020,0013) number for the same slice acquired for two echoes. In this example, where the fieldmap had 36 slices, saving the data direct from the console would store 72 DICOM files, but when the images got exported the PACS archiving thought there were duplicates and only saved 36 (in this case, 5 from one echo and 31 from another).

This is not a fault of dcm2niix: it correctly identifies that the provided images from a given echo do not have equidistant slices. The Siemens files are technically legal (the DICOM standard does not require unique instance numbers), but it does disrupt many archiving systems. While it would be terrific if Siemens helped disambiguate their images, they have had consistent behavior for about a decade. Therefore, when this happens I recommend rescuing the original files from your scanner and validating/updating your storage system to handle this situation.


#9

Almost exact, though not the PACS- another program was not handling the files having the same name correctly.
@Chris_Rorden - you have helped us a lot!
Without dcm2niix- we might have missed this important issue! :clap: :clap: :clap:


#10

Hi,

Have you solved the issue?

Do you maybe have a suggestion on how to export the fieldmaps from the SIEMENS scanner correctly?

Best,

Dima


#11

Hi @Dmitriy_Desser,
Yes-
The problem was caused by files given the same name- as long as the archiving program is able to handle these (for instance- by adding a suffix to the additional file having same name)- the data may be used.
Best wishes


#12

Great! Thank you very much!

Best,

Dima