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.
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.
@ins0mniac2 you should check your scanner console and make sure you are saving both magnitude and phase reconstructions. You can see this in your Siemens sequence PDF as Magn./Phase.
Thanks @neurolabusc . Pretty sure we are. Data sorted into folders by series look like this (sequence supposed to have 37 slices):
Folder 1 : 37 dicom files (magnitude image, checked visually) – some echo 1 , some echo 2. dcm2niix detects the issue and makes “Eq” files.
Folder 2 : 37 dicome files (phase image, checked visually, but not certain whether raw phase or phasediff). dcm2niix is happy, creates e2_ph files, json has both Echo Time 1 and Echo Time 2, although I can only see one Echo Time (TE2) in the headers on all files using dicom_hdr.
Since dcm2niix detects both the echo times for the phase image, it is clearly a phase difference image. Since you have only 37 images with the Eq, it is clear that some magnitude images from one echo overwrote some of the images from another echo. It is clear that some tool that handled these images only looked at instance number (0020,0013), mediaObjectInstanceUID (0002,0003) to detect duplicates. You want to check the provenance of these images to identify the tool and remove it. Your situation is just like Siemens series 2 and 3 from this repository. While the DICOM standard does not require unique instance numbers (hence your data is technically legal), in my experience it is the leading cause of data loss by Siemens users. I strongly urge you to contact the Siemens Research Collaboration Manager associated with your center and lobby them to resolve the problem at the source.
Thanks @neurolabusc! These are old data but the local imaging folks have been alerted. My only remaining question is – what header field is dcm2niix looking at to extract both TE from the phase difference series ?
