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?
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
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).
_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.
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?
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.
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…?
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.
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!
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
@brai, I have similar fmap naming and output (2 magnitudes and 1 ph). I was wondering if your e2_ph had 2 echo times or just 1? Mine has 1 so I’m not sure if the difference in phase can be calculated…
What you probably have is a phase diff image, and the conversion simply doesn’t write one of the TE’s to the json of the e2_ph.
@Chris_Rorden, Is there an option to test this conversion of the data for Siemens scanners so that the 2nd TE would be written to the json?
Currently- one has to update the json after the conversion by dcm2niix.
@ChrisGorgolewski : another option for fmriprep users- to add a feature to fmriprep to take the TE’s from the magnitude images so that siemens users won’t have to rewrite the jsons from dcm2niix (wish I’ll be able to contribute this feature…)
@brai
That’s what we think is going on as well. The json of e2_ph has a field called "EchoNumber: 2 " (which is the same as _e2) so it seems it just needs the first EchoTime/Number in it.
We were planning on editing the json to include the first TE as well, but just wanted to make sure we had a phase diff image/json.
You can get the echo times from the magnitude images. dcm2niix does not report this in the difference image, as the information is not stored in the difference DICOM.
@brai dcm2niix relies on the information supplied in the DICOM header. The Siemens difference fieldmaps only report one echo time and do not appear to have any flags that reveal that they are derived from subtracting two different echo times. From the perspective of dcm2niix, they are indistinguishable from a raw phase map from a single echo time. Feel free to lobby your Siemens Research Collaboration Manager to include this useful information into future versions of their DICOM images. I would be happy to support this feature. The limitation is with the images themselves, not dcm2niix.
