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 Likes
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!
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!
Yes phasediff should work.
Yes - until this is fixed: https://github.com/poldracklab/fmriprep/issues/783
1 Like
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.
1 Like
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!
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.
1 Like
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,
Have you solved the issue?
Do you maybe have a suggestion on how to export the fieldmaps from the SIEMENS scanner correctly?
Best,
Dima
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
Great! Thank you very much!
Best,
Dima
1 Like
@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…
Thanks for the help.
Hi @atersakyan,
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…)
Many thanks
@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.
Thank you all for the help.
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.
Thanks, @Chris_Rorden!
This is our current strategy, though still- it could have been coded in dcm2niix.
@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.
3 Likes
Reviving this thread to ask about how to distinguish a raw phase map vs. phase difference image. @Chris_Rorden : dcm2niix produced an e2_ph image with two Echo Times listed. Is this evidence that this is indeed a phase difference image ? The sorted phase series appears to have 37 dicom files in a 37 slice acquisition, and with dicom_hdr I can only see “Echo Time 2”.
Thanks @Steven . Does this mean that the scanner directly saved the phase difference image ? As I mention there were only 37 dicom files (37 slices in volume). The reason I wasn’t sure was because I could only extract TE2 from the header for each dicom file – giving the impression that these are TE2 raw phase maps as opposed to phase difference map. On the other hand, dcm2niix somehow knows what TE1 is and includes it in the json sidecar file.