Different phase encoding polarity using mrinfo and json_export flag

snp2003 · March 20, 2020, 5:44pm

Dear experts,

I am processing ADNI data and performing EPI distortion correction using epi_reg as it has fieldmap only in the form of phase/mag scans. I used mrconvert to convert DWI dicoms to .mif along with its -json_export flag. In order to find phase encoding direction I did mrinfo of extracted DWI image and also compared it with exported json file. Unfortunately, I see different polarity of phase encoding direction, please see below.

 mrinfo DWI.mif
************************************************
Image:               "DWI.mif"
************************************************
  Dimensions:        116 x 116 x 80 x 55
  Voxel size:        2 x 2 x 2 x ?
  Data strides:      [ -1 -2 3 4 ]
  Format:            MRtrix
  Data type:         unsigned 16 bit integer (little endian)
  Intensity scaling: offset = 0, multiplier = 1
  Transform:                    1           0          -0      -115.4
                                0           1          -0      -101.8
                               -0          -0           1      -86.85
  EchoTime:          0.056
  FlipAngle:         90
  MultibandAccelerationFactor: 1
  PhaseEncodingDirection: j-
  RepetitionTime:    7.2
  SliceEncodingDirection: k
  SliceTiming:       3.58999991,0,3.68000007,0.0900000036,3.76749992,0.180000007,3.85750008,0.267500013,3.94749999,0.357499987,4.0374999,0.44749999,4.12750006,0.537500024,4.21750021,0.627499998,4.30749989,0.717499971,4.39750004,0.807500005,4.48750019,0.897499979,4.57749987,0.987500012,4.66499996,1.07749999,4.75500011,1.16499996,4.84499979,1.255,4.93499994,1.34500003,5.0250001,1.43499994,5.11499977,1.52499998,5.20499992,1.61500001,5.29500008,1.70500004,5.38500023,1.79499996,5.47249985,1.88499999,5.5625,1.97500002,5.65250015,2.0625,5.74249983,2.15249991,5.83249998,2.24250007,5.92250013,2.33249998,6.01249981,2.4224999,6.10249996,2.51250005,6.19250011,2.60249996,6.28249979,2.69250011,6.36999989,2.78250003,6.46000004,2.86999989,6.55000019,2.96000004,6.63999987,3.04999995,6.73000002,3.1400001,6.82000017,3.23000002,6.90999985,3.31999993,7,3.41000009,7.09000015,3.5
  TotalReadoutTime:  0.0336
  command_history:   mrconvert S574073 DWI.mif -json_export DWI_mif.json -export_pe_table pe_mif.txt  (version=3Tissue_v5.2.8)
  comments:          002_S_0413 (002_S_0413) [MR] Axial DTI
                     study: ADNI3 Basic Prisma ADNI3 Basic [ ORIGINAL PRIMARY DIFFUSION NONE ND NORM MOSAIC ]
                     DOB: 21/06/1930
                     DOS: 21/06/2017 13:48:54
  dw_scheme:         0,0,0,0
  [55 entries]       0,0,0,0
                     ...
                     -0.070209229999999997,0.99701636999999999,0.032078339999999997,1000
                     0.42905900000000002,0.76815146000000001,-0.47523843999999998,1000
  mrtrix_version:    3Tissue_v5.2.8

cat DWI_mif.json
************************************************
{
    "EchoTime": "0.056",
    "FlipAngle": "90",
    "MultibandAccelerationFactor": "1",
    "PhaseEncodingDirection": "j",
    "RepetitionTime": "7.2",
    "SliceEncodingDirection": "k",
    "SliceTiming": "3.58999991,0,3.68000007,0.0900000036,3.76749992,0.180000007,3.85750008,0.267500013,3.94749999,0.357499987,4.0374999,0.44749999,4.12750006,0.537500024,4.21750021,0.627499998,4.30749989,0.717499971,4.39750004,0.807500005,4.48750019,0.897499979,4.57749987,0.987500012,4.66499996,1.07749999,4.75500011,1.16499996,4.84499979,1.255,4.93499994,1.34500003,5.0250001,1.43499994,5.11499977,1.52499998,5.20499992,1.61500001,5.29500008,1.70500004,5.38500023,1.79499996,5.47249985,1.88499999,5.5625,1.97500002,5.65250015,2.0625,5.74249983,2.15249991,5.83249998,2.24250007,5.92250013,2.33249998,6.01249981,2.4224999,6.10249996,2.51250005,6.19250011,2.60249996,6.28249979,2.69250011,6.36999989,2.78250003,6.46000004,2.86999989,6.55000019,2.96000004,6.63999987,3.04999995,6.73000002,3.1400001,6.82000017,3.23000002,6.90999985,3.31999993,7,3.41000009,7.09000015,3.5",
    "TotalReadoutTime": "0.0336",
    "comments": "002_S_0413 (002_S_0413) [MR] Axial DTI\nstudy: ADNI3 Basic Prisma ADNI3 Basic [ ORIGINAL PRIMARY DIFFUSION NONE ND NORM MOSAIC ]\nDOB: 21/06/1930\nDOS: 21/06/2017 13:48:54",
    "dw_scheme": "0,0,0,0\n0,0,0,0\n0.43989815999999998,-0.33589560000000002,0.83286457999999997,1000\n-0.50804800000000006,-0.39628845000000001,-0.76474993999999996,1000\n0.14905657,-0.029167149999999999,-0.98839831,1000\n0,0,0,0\n0.56873286000000001,-0.71889256999999995,-0.39967024000000001,1000\n0.85194135000000004,-0.49273362999999998,0.17722699,1000\n0.14967976999999999,-0.42318463000000001,-0.89359421000000006,1000\n-0.39273444000000002,0.61961973000000004,0.67958145999999997,1000\n-0.73417931999999997,0.67150330999999996,0.10032070999999999,1000\n0.10245296,-0.76195592000000001,-0.63947385999999995,1000\n-0.18153580999999999,-0.23584774,-0.95468354,1000\n-0.0063826999999999998,0.79189503000000006,-0.61062395999999997,1000\n0.58592253999999999,0.77770852999999995,0.22773727999999999,1000\n-0.23924466999999999,0.91302335000000001,0.33037883000000001,1000\n0,0,0,0\n0.72041087999999998,-0.077146670000000001,-0.68924344000000004,1000\n-0.30029454999999999,-0.60058904000000002,0.74102354000000004,1000\n0.21523517,0.32601148000000002,-0.92053812999999995,1000\n0.15779425,0.58392465000000005,0.79632449000000005,1000\n0.35299735999999998,-0.68359548000000003,0.63881946000000001,1000\n-0.72240572999999997,0.13024057,-0.67909306000000003,1000\n0.78358406000000003,0.21103417999999999,0.58434635000000001,1000\n0.89609450000000002,-0.19314595000000001,0.39963660000000001,1000\n-0.23536652,0.91566581000000002,-0.32582044999999998,1000\n0.53192472000000002,0.83492535000000001,-0.14126427,1000\n0,0,0,0\n0.95507788999999998,0.26990809999999998,-0.12237621999999999,1000\n-0.46894637,0.26454781999999999,0.84267669999999995,1000\n-0.50867753999999998,-0.15774050000000001,0.84638363000000005,1000\n-0.82684857,-0.56102216000000005,-0.039691560000000001,1000\n-0.83448279000000003,-0.23042341,0.50054323999999994,1000\n-0.98982846999999996,0.12624163999999999,-0.065594780000000005,1000\n0.60907120000000003,0.43733569999999999,-0.66164171999999999,1000\n-0.73246217000000002,0.42271435000000002,0.53367739999999997,1000\n-0.94699842000000001,-0.20561542999999999,-0.24681243,1000\n0.89638494999999996,-0.38572007000000003,-0.21843525999999999,1000\n0,0,0,0\n0.74069297000000001,0.51961941,0.42587494999999997,1000\n0.45362595,-0.89113277000000002,-0.010290819999999999,1000\n0.12693903000000001,0.89855247999999999,0.42010713,1000\n-0.28302844999999999,-0.95019275000000003,-0.13049413000000001,1000\n-0.93593168000000004,0.07270625,0.34459498999999999,1000\n-0.089242269999999999,0.49946596999999998,-0.86172484999999999,1000\n-0.38259896999999998,-0.73187321000000005,-0.56389707,1000\n-0.66193073999999996,0.51412504999999997,-0.54545670999999996,1000\n0.58913243000000004,-0.75462454999999995,0.28890279000000002,1000\n-0.75377070999999995,-0.57402092000000005,0.31989020000000001,1000\n0.49238493999999999,0.055345419999999999,0.86861615999999997,1000\n0,0,0,0\n-0.14872740000000001,-0.95529717000000003,0.25551342999999999,1000\n0.16160287000000001,-0.14824474000000001,0.97565776000000004,1000\n-0.070209229999999997,0.99701636999999999,0.032078339999999997,1000\n0.42905900000000002,0.76815146000000001,-0.47523843999999998,1000"
}

I also used dcm2niix to convert dicoms and compared the field with its extracted json file, which showed ‘-j’ as phase encoding direction similar to one exported by mrinfo. Besides, I performed EPI distortion correction with both positive and negative directions and reviewed unwarped images. Unwarped images look better when applying correction with +ve direction, please see attached screenshot.

What phase encoding direction should I use to correct for EPI and then for eddy correction using dwipreproc, and should I rely on mrinfo or exported json file?

rsmith · March 22, 2020, 9:51am

Welcome Sneha!

There’s a number of layers of complexity to this issue. If anyone wants to see the scope of the confusion, GitHub #1843 is the latest on this from a development perspective.

Right now I would advise to not trust the MRtrix3-generated JSON contents. The current handling of such on master is not quite right, especially if using in conjunction with an image format other than NIfTI or (God forbid) Analyse.

Besides, if you are using .mif images, there should not be any need to generate JSON files: anything that can read a .mif image will be able to read the contents of the header of that image, which is basically the functionality that the utilisation of JSON files duplicates.

Where the current JSON handling is not quite right (and I’ve had to put a lot of effort into trying to get right for the coming update) is the interaction that the handling of JSON files has with some of MRtrix3’s internal image data handling, specifically the way that it tries to make the three image axes correspond to L-R, P-A and I-S respectively even if the acquisition wasn’t axial or if the data are not stored in that order on the file system.

It’s also worth noting that:

If the phase encoding direction is tracked within the image header, there’s no need to provide such to dwipreproc explicitly: just use the -rpe_header option.
The outcome of dwipreproc would (I think) be identical regardless of which direction you provide. Since eddy current correction is based on registration, all that matters is the axis. Even for -rpe_pair and -rpe_all, all that negating the phase encoding direction does is correspondingly negate the values of the estimated field offsets; in the correction of geometric distortions arising from such, the negation cancels itself out.

Rob

snp2003 · March 23, 2020, 3:20pm

Thank you Rob for this detailed explanation. I understand the complexity of acquisition related to three image axis. This is one of my struggle too when I am automating my pipeline, as phase encoding may differ in terms of numerous factors.

If the phase encoding direction is tracked within the image header, there’s no need to provide such to dwipreproc explicitly: just use the -rpe_header option.

If I use this option, will not dwipreproc default it to topup for distortion correction? Unfortunately, ADNI only acquires (that too in my understanding only for Siemen’s data) fieldmap scan in the form of phase/mag image. This was the key reason for me to use epi_reg outside of MRtrix3 to correct for distortion correction using phase/map acquired fieldmap.
Besides, if you see the screenshot I attached in earlier email, distortion correction is better in “+j” (which is fsl’s y+) direction which is opposite to the one saved in the DWI.mif’s header ("-j" direction). In that case, would it matter if I use “+j” for distortion correction, and “-j” for eddy correction?

The outcome of dwipreproc would (I think) be identical regardless of which direction you provide. Since eddy current correction is based on registration, all that matters is the axis. Even for -rpe_pair and -rpe_all , all that negating the phase encoding direction does is correspondingly negate the values of the estimated field offsets; in the correction of geometric distortions arising from such, the negation cancels itself out.

Seeing the o/p of unwrapped images, I might not be sure of we may see identical o/p from dwipreproc. I would understand that we may see some percent of error in our metric calculations, also see https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4845159/ for reference, which is one of my concern.

Thanks again,
Sneha

rsmith · March 29, 2020, 9:11am

If I use this option, will not dwipreproc default it to topup for distortion correction? Unfortunately, ADNI only acquires (that too in my understanding only for Siemen’s data) fieldmap scan in the form of phase/mag image. This was the key reason for me to use epi_reg outside of MRtrix3 to correct for distortion correction using phase/map acquired fieldmap.

If -rpe_header is used, dwipreproc will perform whatever it deems appropriate given the phase encoding (& diffusion encoding) information it finds in the header. If there is no phase encoding contrast present in the DWIs, and no spin-echo EPIs provided via the -se_epi option, then it will decide that it does not have the requisite information with which to run topup, and will not attempt to do so.

I unfortunately still have not put the effort into supporting gradient echo-based field map estimation and correction within dwipreproc (as it would be preferable to provide the estimated field to eddy rather than correcting for such first). It’s on my list though.

Besides, if you see the screenshot I attached in earlier email, distortion correction is better in “+j” (which is fsl’s y+) direction which is opposite to the one saved in the DWI.mif’s header (“-j” direction). In that case, would it matter if I use “+j” for distortion correction, and “-j” for eddy correction?

Sorry, I went down the wrong train of thought there. If you are estimating a field map using gradient echo phase differences, and then applying that field to DWI data, then the sign of the phase encoding direction will matter.

In trying to re-convince myself that my latest changes to the phase encoding direction handling are correct on the dev branch, I reminded myself of how easy it is to get confused myself with this stuff, even after having written the code. Running mrconvert -json_export and observing one phase encoding direction, and running dcm2niix and observing the opposite phase encoding direction in the JSON, does not necessarily indicate an error. This is because:

The phase encoding direction is specified relative to the 1D layout of data within the image (intended specifically for NIfTI);
That layout is handled by the more general framework of strides in MRtrix3;
On image load, MRtrix3 will automatically reinterpret non-axial data by altering the image strides in order to produce a near-axial transformation without having to re-sample the 1D image intensity data.

As examples:

If MRtrix3 produces an image with strides -1,-2,+3 and a phase encoding direction of j-, whereas dcm2niix produces an image with strides -1,+2,+3 and a phase encoding direction of j, they are both correct
If you run mrinfo -json_import, the reported phase encoding direction might not be the same as what’s stored in the raw text JSON file

That’s notwithstanding the acknowledgement that the current handling on master is not quite correct. One of the problems with the current master branch is on point 3. If the phase encoding information is present in the image header, then it’s easy in the code to apply the same transformation to the phase encoding direction. However if you provide the phase encoding information via a JSON import, that transformation’s already been performed… Yet another reason to embed sidecar data in the image header rather than JSONs

I would understand that we may see some percent of error in our metric calculations, also see Choosing the polarity of the phase-encoding direction in diffusion MRI: Does it matter for group analysis? - PMC for reference, which is one of my concern.

From a quick glance this looks like the influence of phase encoding direction during acquisition on output metrics, which will be in part due to which brain regions get expanded vs. contracted due to the same inhomogeneity field having opposing effects. Whether or not specification of the phase encoding direction polarity has an effect on eddy specifically is a different question.

Rob

snp2003 · April 24, 2020, 11:39pm

Hi Rob,

Sorry for delayed response and thank you for detailing this. With newer production release I see in the change log that phase encoding information from the json file has been resolved, and I see that exported json file now correctly reflects phase encoding direction from same data set I shared above. Will this take care of the issue I experienced before, or should I still rely on header information than the json file?

rsmith · May 3, 2020, 12:29pm

… phase encoding information from the json file has been resolved …

I’m going to be in a lot of pain if it’s not

Note however that the confound of whether phase encoding information is tracked in the image header v.s. a JSON file is … complex. As such, knowing this question was coming, I wrote this new section in the documentation just for you.

snp2003 · May 6, 2020, 8:09pm

I’m going to be in a lot of pain if it’s not

I sincerely hope not

Note however that the confound of whether phase encoding information is tracked in the image header v.s. a JSON file is … complex. As such, knowing this question was coming, I wrote this new section in the documentation just for you.

Perfect, thanks a bunch