PhaseEncodingDirection in .json file

,
1

Dear all,

I am using dicm2niix to convert my dicoms to NIFTI. In the .json file, I am getting the PhaseEncodingDirection for my functional scan as “i”.

I am somewhat confused with this since the phase encoding for the data (as per our protocol) is A>P, which should normally be “j-”? One thing to note is that the data was acquired in the following orientation:
Data acquisition sequence is : Saggital > Coronal > Transversal
Sagittal R >> L
Coronal A >> P
Transversal F >> H

The PhaseEncodingDirection of “i” in the .json file for the functional scans is also causing problems during fieldmap distortion correction - the warping of the data is being done in the L/R axis and not the A/P axis.

I am not sure how to resolve this, and I am wary about manually changing the “i” to “j-”.

Does anyone know why dcm2niix is giving “i” instead of “j”?

The data in BIDS format is here: Dropbox - sub-ID01 - Simplify your life

Thank you so much.

1 Like
2

Please refer to the BIDS specification. These are sagittal sequences. Sagittal slices are natively saved to disk as column (i) = AP, row (j) = HF, slice (k) = LR. In contrast, axial slices are natively saved to disk as column (i) = LR, row (j) = AP, slice (k) = HF. Finally, coronal slices are natively saved to disk column (i) = LR, row (j) = HF, slice (k) = AP. As per the BIDS standard, images are not resliced so that slice timing always works in the slice (k) dimension.

Therefore, for Sagittal sequences, ‘I’ indicates AP phase encoding axis.

"ProtocolName": "gre_field_mapping_sag_2mm"
"InPlanePhaseEncodingDirectionDICOM": "ROW", 
"PhaseEncodingDirection": "i",

You can also see the the AP direction is the first (i) using fslhd:

sub-ID01_magnitude1
...
sto_xyz:1	0.000000 0.000000 2.000000 -79.000000 
sto_xyz:2	-4.125000 -0.000000 0.000000 123.369247 
sto_xyz:3	0.000000 4.125000 0.000000 -144.218826 
sto_xyz:4	0.000000 0.000000 0.000000 1.000000 
sform_xorient	Anterior-to-Posterior
sform_yorient	Inferior-to-Superior
sform_zorient	Left-to-Right

I do notice that you have a file named sub-ID01_phasediff.nii and another named sub-ID01_phasediff.nii.gz. Be aware that most FSL tools will not abide by this, as they can not discriminate between these two images:

fslhd sub-ID01_phasediff                                                 
Image Exception : #61 :: Multiple possible filenames detected for basename: sub-ID01_phasediff
Multiple possible filenames detected for basename: sub-ID01_phasediff

Axial sequences are dominant for EPI sequences in our field, though in practice there is nothing wrong with sagittal. It is possible that you have discovered some tool that is misbehaving, but it does look like dcm2niix is applying the BIDS specification correctly for your data.

acs21
acs21652×1576 139 KB

1 Like
3

@e0046902 are you sure that these fieldmaps belong to this BOLD EPI sequence. I would suggest acquiring the field map with identical properties (voxel spacing, resolution, angulation, etc). I notice your images have different voxel spacing and different resolution, resulting in a different field of view (FoV). I have never tried to use FSL’s FUGUE in with these variations. I do wonder if the change in the FOV leads the scanner to re-shim in order to provide the optimal homogeneity for the selected volume. This would change the physical values that the field map measures.

fslhd /Users/chrisrorden/Desktop/sub-ID01/fmap/sub-ID01_magnitude1.nii.gz 
...
pixdim1		4.125000
pixdim2		4.125000
pixdim3		2.000000
...
sto_xyz:1	0.000000 0.000000 2.000000 -79.000000 
sto_xyz:2	-4.125000 -0.000000 0.000000 123.369247 
sto_xyz:3	0.000000 4.125000 0.000000 -144.218826 
sto_xyz:4	0.000000 0.000000 0.000000 1.000000 

fslhd sub-ID01_task-meditation_bold.nii.gz 
...
pixdim1		1.100917
pixdim2		1.100917
pixdim3		1.100000
...
sto_xyz:1	0.000000 0.000000 -1.100000 68.750000 
sto_xyz:2	-1.100917 0.000000 0.000000 97.043587 
sto_xyz:3	0.000000 1.100917 0.000000 -135.242950 
sto_xyz:4	0.000000 0.000000 0.000000 1.000000
4

Dear Chris,

Yes, the fieldmap and EPI are from the same sequence. I understand from this link that the FOV of the fieldmap does not matter as long as it is acquired in the same orientation: Acquiring and using fieldmaps.

"The field map should be in the same orientation as the EPIs you are planning to correct (eg, axial), but does not need to have exactly the same geometry, field of view, or resolution."

In running fsl fugue, I am having to indicate unwarpdir= x- in order to get distortion correction in the AP/PA direction. I guess this is correct since x axis is the first dimension (which is AP) according to fslhd?

In fmriprep, however, the PhaseEncodingDirection of “i” in the EPI causes problems in the sense that the fieldmap distortion correction is being applied in the R/L direction. I have to manually change “i” to “j” in order to get distortion correction in the AP direction.

Thanks for your help with this.

Best,
Avi

5

I would always try to make the FOV and angulation match (and if possible the resolution). In my experience, adjusting the FOV will encourage the Siemens MRI to re-shim to optimize the field homogeneity for the selected region. If the shim changes, the actual field strength you are trying to measure will change. I concede that if both Jolinda and MJ say it is OK, the shim optimizations are probably not making a huge difference.

With FSL tools (which pre-date NIfTI) they often describe the data dimensions columns, rows, and slices as x,y,z. However, the NIfTI and BIDS specifications refer to these as i,j,k respectively. This is to distinguish the columns, rows and slices as saved to disk from the spatial directions. The NIfTI spatial coordinates x,y,z corresponds to L->R, P->A, I->S, and the SForm/QForm transform i,j,k to x,y,z.

Since both dcm2niix and FSL’s FUGUE seem to work as expected, it sounds like you have discovered an issue with fmriprep. I suggest you create an issue on Github.

6

Dear Avi and all!

Could you help me solve the problem? I have one fMRI (json: “PhaseEncodingDirection”: “i”, “ImageOrientationText”: “Tra>Cor(-21.6)>Sag(1.6)”) and three fmap - magnitude1 (json: “PhaseEncodingDirection”: “j-”), magnitude2 (json: “PhaseEncodingDirection”: “j-”), phasediff (json: “PhaseEncodingDirection”: “j-”).

During automatic Fmriprep processing, I get a heavily distorted fmri file. Did I understand correctly that I need to change “i” to “j” in fmri json-file for correct preprocessing?

Thank you so much.

7

Hi @mkhazova, and welcome to neurostars! Please open a new issue for your request under the Software Support category, making sure to fill in information in the pre-populated template.

Best,
Steven

8