Request: Gradient Non-Linearity Correction

[pvelasco]

Hi Dev Team,

Would it be possible to incorporate the Gradient Non-Linearity Correction (a.k.a., Gradient Distortion Correction, or GDC) into fmriprep? Currently, I can run it on my own, and then run fmriprep on the unwarped images. However, I would like to be able to concatenate warps, and apply a single interpolation. Thanks!

[effigies]

I don't see any reason why this can't be done. The documentation indicates that you need either a .coef or .grad file. Could you describe the format of these files? That might help determine the best way to include them in a BIDS dataset.

By the NITRC entry, it looks like this applies to anatomical images, though, which don't really have much in the way of transforms applied. The only resampling done to them is if you have multiple, to create an anatomical template. So it's not obvious that we're going to pick up much in the way of reduced interpolations, but nonetheless, this seems like a reasonable thing to support.

Could you share more about your use case, and how gradunwarp fits into HCP and other pipelines?

[pvelasco]

Hi @effigies,

The .coef or .grad files are text files with the spherical harmonics that describe the magnetic fields created by the gradient coils in Siemens systems. They are considered protected intellectual property, so they cannot be distributed with the BIDS dataset. That said, you can ask Siemens for the file and they can give it to you. (In our case, we have a research agreement with Siemens, so we have access to the .grad file for our Prisma.)

The way I thought fMRIPrep would handle this limitation would be that the user passes the .coef or .grad file as an option, similar to what is done with the --fs-license-file. If the .coef or .grad file is present, fMRIPrep will run gradunwarp. If not, it will skip it.

The NITRC version is the original one, which is now stale. Since then, the people at Wash.U. have continue developing it. The use of this tool is to correct for the fact that the fields generated by the gradient coils are not perfectly linear, so when the scanner reconstructs images assuming that they are, errors are introduced. Basically, it's like your images have been warped. The more linear your gradient coil fields, the smaller the warp. This applies to all images, not just anatomical images, and the warp field (the amount of displacement at a given location) is the same for all of them.

Just to give you an idea of the magnitude of the warp, we are talking about 0.1-0.2mm at the cortical surface, for a good scanner. For other scanners it will be different. For scanner with head only gradient coils, it will be much larger.

So, for users who scan each subject once and use the anatomical images to register the functional images to a template, this tool doesn't add much: this warp is smaller than the susceptibility distortions, and they really don't care about the exact anatomy.

However, if you scan your subjects repeatedly (including repositioning), the warp fields for the different sessions will be different, and if you want the best alignment between sessions, you want to correct for these nonlinearities. Also, if you want to look at cortical thickness differences, gray matter volume, etc., you want the best accuracy possible and should correct for these nonlinearities.

This would be the first correction applied to all images for a given subject. By default, it outputs a trilinear-interpolated corrected image and the corresponding (absolute) warp field and jacobian. The HCP Pipelines then convert the absolute warp field to relative and apply a spline interpolation.

Also, note that Siemens scanners allow you to do a distortion correction for some of modalities (not sure if all of them). However, afaik, it only does a 2D correction within the slice. So the potential caveat of using this tool indiscriminately is that you apply the correction to images that have been somehow corrected.

[jocwilliams]

Hi @effigies ,

Would you know if this has been implemented yet? My lab is investigating using fMRIPrep as a standard preprocessing pipeline, and it would be terrific to be able to use this in a single fMRIPrep preprocessing step rather than using gradunwarp on unprocessed data first.

Thanks so much for your help! John

[Lestropie]

Hi all,

Bumping this issue in conjunction with @BahmanTahayori.

We are currently investigating the integration of gradient non-linearity correction into our own workflow. Having this functionality integrated into fmriprep is likely a much cleaner solution than our attempting to invoke it separately and pass data between tools, and doing so would avoid the smoothing effects of multiple sequential image interpolations. So we're checking in to see if anybody has made any progress in implementing such, and to start a more developer-focused conversation if ourselves or others are going to invest effort into it.

As far as I can tell, here's a list of items that one would want to address (noting that I'm myself looking into this for the first time so by all means amend / append):

1. Check JSONs to see whether or not the DICOM ImageType field indicates that gradient non-linearity distortion correction has already been applied by the scanner, & modulate behaviour accordingly.

2. For fMRI data:

   1. Generate deformation field on native fMRI voxel grid;

   2. Apply deformation field to empirical fMRI data (with desired interpolation), with resulting image data to be used where appropriate in subsequent calculations (e.g. inter-modal registration);

   3. When finally composing the multiple transformations from native data to each output space, include the gradient non-linearity deformation field at the start of that stack.

3. For anatomical data:

   1. Generate deformation field on native anatomical voxel grid;

   2. Apply deformation field to empirical anatomical data (with desired interpolation) to be used where appropriate in subsequent calculations (e.g. registration to template);

   3. Provide distortion-corrected data to FreeSurfer.

I would note that in the HCP Pipelines, for the anatomical images they perform not only gradient non-linearity distortion correction, but also B0 susceptibility distortion correction along the readout axis. The inhomogeneity field is estimated via FSL topup based on spin-echo EPIs with reversed phase encoding; but unlike DWI processing where the native output of topup is utilised directly by eddy, the inhomogeneity field is converted into a non-linear deformation field based on the readout axis and dwell time. Ideally, this calculation would also be integrated into fmriprep (and indeed smriprep), and the transformation would be composed with the gradient non-linearity correction into a single interpolation step. This is however a distinctly different image processing step to gradient non-linearity correction, so it should be deferred to a separate Issue if it is to be pursued. But I wanted to make sure both that the prospect of performing both corrections is recognised and that the distinction between them is established.

I would also note that there is some risk with @pvelasco's comment regarding how the gradient non-linearity coefficients may be provided to fmriprep. For some datasets there may be subjects (or indeed sessions) that were acquired on different scanners, and therefore the associated gradient non-linearity information would be different. If one were to perform batch processing of multiple participants in a single fmriprep invocation, there would be no guarantee from the perspective of the software that the user-provided gradient coefficient file is appropriate for all participants being processed. While instead integrating such data into the BIDS dataset would enable mitigation of such (since such a file could be stored such that it applies to the whole dataset, or individual subjects / sessions), inclusion of such files within a publicly distributed BIDS dataset is not permissible. Then again, a dataset but with such files missing should still be possible to process, just with the relevant corrections omitted from the pipeline. So there's a discussion to be had about where the compromise occurs (I'm not placing my vote in either box, just establishing the options available); and if such data were to be embedded in the BIDS dataset, we would need to look into the requisite augmentation of the BIDS specification.

So: has anyone out there invested energy into this? Am I overlooking anything?

Cheers Rob