Dcm2niix identifying EPI orientation incorrectly?

Software Support
,
1

Summary of what happened:

I am trying to use dcm2bids to convert some DICOMs to NIFTI format before running fmriprep. For the EPI scans, the protocol states Sagittal R >> L, Coronal A >> P, Transversal F >> H (or I >> S), and Phase Encoding Direction A >> P. Therefore, I believe the .nii file should be LPS orientation and the json file should have “PhaseEncodingDirection”: “j”
For the field maps, Sagittal R >> L, Coronal A >> P, Transversal F >> H and Phase Encoding Direction R >> L. So, should be “PhaseEncodingDirection”: “i”
However, after running dcm2bids, I get LAS as the EPI orientation and j as the pe direction, and i- as the pe direction for the field maps. I’m not sure why this is, but I’m thinking perhaps because we’re using a tilted acquisition, it’s confusing dcm2bids’ method for determining orientation. When I view the image in AFNI it seems like it’s LPS (i.e. coordinates are positive in left, posterior and superior regions), however after some reading I think this may be the way AFNI visualizes all images, is that right?
When I then run fMRIPrep, it tells me the orientation is LAS and phase encoding direction is Posterior-Anterior, but the distortion correction looks ok.

Command used (and if a helper script was used, a link to the helper script or the command generated):

dcm2bids: dcm2bids -d ${raw_dir}/${subj}/${ses}/DICOMs -p "${subj}" -s "${ses}" -c ${config_dir}/bids-config_${subj}_${ses}.json --forceDcm2niix
with config file as follows:
{
	"descriptions": [
		{
			"dataType": "anat",
			"modalityLabel": "T1w",
			"criteria": {
				"SeriesNumber": 10
			}
		},
		{
			"dataType": "fmap",
			"modalityLabel": "magnitude1",
			"intendedFor": [
			3,
			4,
			5],
			"criteria": {
				"SeriesNumber": 4,
				"EchoTime": 0.01
			}
		},
		{
			"dataType": "fmap",
			"modalityLabel": "phasediff",
			"intendedFor": [
			3,
			4,
			5],
			"criteria": {
				"SeriesNumber": 5,
				"EchoTime": 0.01476
			}
		},
		{
			"dataType": "func",
			"modalityLabel": "bold",
			"customLabels": "task-affvis",
			"criteria": {
				"SeriesNumber": 6
			},
			"sidecarChanges": {
				"TaskName": "affvis"
				}
		},
		{
			"dataType": "func",
			"modalityLabel": "bold",
			"customLabels": "task-facegender",
			"criteria": {
				"SeriesNumber": 8
			},
			"sidecarChanges": {
				"TaskName": "facegender"
				}
		},
		{
			"dataType": "func",
			"modalityLabel": "bold",
			"customLabels": "task-facememory",
			"criteria": {
				"SeriesNumber": 2
			},
			"sidecarChanges": {
				"TaskName": "facememory"
				}
		}
	]
}

Version:

dcm2bids v2.1.9

Environment (Docker, Singularity, custom installation):

Conda

Please let me know if there’s any other information that might be useful! I feel like I may be missing something important.

2

Your description is underspecified. It might be helpful if you can share a sample image with my institutional email and perhaps your protocol PDF. By definition, the slice direction for Sagittal is always R <-> L, Coronal A <-> P, and Transversal F <->, but you never say if the data was acquired as axial, coronal or sagittal slices. You also did not say if the data came from GE, Philips or Mediso.

I am going to go out on a limb here and speculate that your data was acquired as axial slices on a Siemens scanner running VE11 software, and you applied a lot of pitch angulation to the slice direction when planning the scan. In this situation, the Siemens console will adjust your phase encoding from A>P to R>L. You can see this on the scanner console as you adjust the angle. Likewise, with phase reversed sequences where you set one scan to have AP and the other to have PA, the console can swap the second scan to RL. This is a known feature of Siemens software that has caused a lot of issues for unsuspecting individuals. I suggest that dcm2niix is faithfully reporting data as acquired, rather than how the acquisition was specified prior to angulation. Visual inspection of the data should confirm this hypothesis.

3

Just to clarify, the default behavior of Siemens scanners is that the phase encoding direction of a scan will be changed if you change the angulation of your image. Consider a scan that is planned as a axial scan with an A>>P phase encoding direction. In acquiring the scan, one might decide to change the pitch of the slice angulation to increase coverage of the cerebellum, so the oblique slice plane is somewhere between an axial and a coronal scan. As this angle is increased, the software may automatically switch the phase encoding from A>>P to R>>L because it is trying to avoid the phase wrap from the neck.

Again, dcm2niix is interested in preserving the details of how the image was actually acquired. This is a strength and not a weakness of dcm2niix. However, it does illustrate that users need to be vigilant when planning their designs - the software can make adjustments that were not expected and have unintended consequences. There will be a Siemens Research Collaboration manager assigned to your center that can help you plan your studies and explain the complex interactions of the different settings.

4

Thank you so much for your detailed explanations @neurolabusc, they’re really helpful and make sense. The data was acquired as axial slices using a Siemen’s Avanto so I think your assumptions are correct. I’m checking with the person who set up the protocol to see whether they know if this PE switch is the case with the way it’s set up.

I was using a custom function written by the scanner team previously to convert my DICOMs to NIFTI but they no longer maintain it so I switched to dcm2niix, so I assumed dcm2niix was reporting incorrectly but it sounds like perhaps not!

You mentioned visually inspecting the data to confirm how the data was acquired; this feels like a silly question, but what do I need to check in order to confirm?

5

Here is an image that shows axial acquisitions with both AP an RL phase encoding. While the amount of spatial distortion is similar, the RL has a bigger impact on the appearance of the symmetry of the brains hemispheres, so most people feel they look more distorted.

6

Thanks, I’ve been able to confirm that the PE direction is A>P and the tilt of the acquisition isn’t switching this to R>L (thankfully)

However, I think my original question is still unresolved:

  • when I run 3dinfo on a nii.gz file output by dcm2bids, it says the images are LAS orientation
  • the json sidecar output by dcm2bids has PhaseEncodingDirection: j
  • my understanding is that the phase encoding direction is therefore P>A (because LAS means the image increases from P-A in the j direction… j- would be A>P because it’s going from the highest index to the lowest)

Is that correct or have I misunderstood?

If I read the DICOMs using SPM, it reads the 0051,1013 ‘PositivePCSDirections’ tag as +LPH (Siemens seem to use H instead of S). The previous custom function I was using to convert DICOMs also read the orientation as LPS so I think LPS is the correct orientation. This would mean that PhaseEncodingDirection: j indicates A>P phase encoding, as expected.

Overall, it seems like something is causing the A-P direction to flip when converting to dicom to nifti but I’m not sure why or how to resolve this. How do I tell whether the actual image orientation is wrong, or just the header information is wrong, and what is the solution in either case? Or am I missing something completely?

7

For an axial EPI acquisition, columns (i) are RL, the rows (j) are AP and the slices (k) are IS. So a pair of series with AP and PA should create PhaseEncodingDirection in j, with opposite polarity. It is actually arbitrary for topup which you label j and j-. Below I show a reference dataset from a spin echo sequence (a gradient echo will show similar distortion but signal will also be lost rather than merely moved).

PA_APx

Be aware that DICOM and NIfTI use different polarities for spatial dimensions. Furthermore, a DICOM image puts the first line at the top of the screen, with subsequent lines below (the way we write English), whereas NIfTI puts the first line at the bottom of the screen with values ascending upward on the screen (the way we draw the Y dimension in a cartesian graph).

8

As an aside, you can coerce dcm2niix to copy DICOM voxel data directly by disabling lossless rotation of 3D images (-x i) and not reversing row order (-y n):

dcm2niix -x i -y n /path/to/DICOMs

dcm2niix is actually a bit faster in this mode, and these modes are lossless (since the transforms are stored in the NIfTI sform/qform). I would in general discourage doing this as these modes are less well tested (e.g. PhaseEncodingDirection , DWI bvec issues) and images will be displayed in a bizarre fashion in tools that ignore the spatial transforms.

2 Likes
9

Thank you so much Chris! Really appreciate your detailed responses- I think I understand now and will just leave the output as dcm2bids puts it so it’s in line with NIFTI conventions, but really useful to also know how to stop it from flipping the AP!