[RTM] ENH: Nonlinear warp-based susceptibility distortion correct

[effigies]

Closes #496

[effigies]

For the distortion atlas, the authors provide an unspecified template (I'll call the distortion template), I would guess a symmetric MNI template. My current strategy for getting a distortion atlas in the EPI ref space is:

• Find an affine transformation from the distortion template to the template in use by FMRIPREP
• Apply (distortion template -> template) + inv(T1 -> template) + inv(EPI ref -> T1) to distortion atlas

If we don't think an affine transformation is sufficient to go between templates, then I think it would make more sense to calculate a transform from the T1 to the distortion template and invert that, since we're going to go through the trouble of a nonlinear transform anyway.

Alternately, we can pre-calculate a (distortion template -> template) warp for each template we support.

WDYT?

[chrisgorgo]

I think affine is perfectly fine for this purpuse. BTW the template they used (defining the space) is this one http://neurovault.org/images/43982/ AFAIK.

…

On Fri, Jun 2, 2017 at 9:31 AM, Chris Markiewicz ***@***.***> wrote: For the distortion atlas <http://neurovault.org/collections/2426/>, the authors provide an unspecified template (I'll call the *distortion template*), I would guess a symmetric MNI template. My current strategy for getting a distortion atlas in the EPI ref space is: - Find an affine transformation from the distortion template to the template in use by FMRIPREP - Apply (distortion template -> template) + inv(T1 -> template) + inv(EPI ref -> T1) to distortion atlas If we don't think an affine transformation is sufficient to go between templates, then I think it would make more sense to calculate a transform from the T1 to the distortion template and invert that, since we're going to go through the trouble of a nonlinear transform anyway. Alternately, we can pre-calculate a (distortion template -> template) warp for each template we support. WDYT? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#544 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkp94S41UsyuutCWIB780fWuc5ePxEks5sADjEgaJpZM4NuVYr> .

[effigies]

Right, they used that template, but it's not clear if it's a standard template or if they created it from their collection of subjects. Not sure that it makes a difference for our purposes; just noting the situation.

[effigies]

How do I get the phase-encoding direction from the JSON file associated with a BOLD image? Just make sure I have the original filename and replace nii.gz with json? Or does pybids have some relevant magic?

Edit: Found it: bold_file_pe = layout.get_metadata(bold_file)["PhaseEncodingDirection"]

Another thing to consider: This atlas is only valid for anterior/posterior phase-encoding. In the event of an i/i- or k/k- image, we probably wouldn't want to use the atlas...

[chrisgorgo]

There are two things to consider:

• AFAIK distortions happen in the same place in the brain independently of the phase encoding direction. It only changes which way the tissue will be pulled/pushed. Thus I think we can use this atlas for both i/i- and j/j-
• most datasets without fieldmaps do not have any phase encoding information. In such cases it is worth assuming that the distortions happen in either i or j (because we already assume k is slice direction). There are two things we could do: 1) restrict ants to two direction - i and j (instead of one) 2) run ants twice once with i and once with j and see which gives better fit with bbregister

[effigies]

1. I've searched a bit, and can't find any articles that discuss the effect of PE direction on where artifacts occur. Presumably there's some effect, even though the "epicenters" might be consistent. ANTs' smooth deformation constraints may save us here. In either event, we can start from that assumption.

2. I suppose I'd rather go with the second option in cases where we don't know; that way we're not using an effectively different algorithm when we don't know. In this case, we should verify on datasets where we do know PE direction that our heuristic (e.g. bbregister min cost) selects the true one.

[oesteban]

Yes, theoretically the fieldmap is the same regardless the encoding direction. I don't think you'll find a scan with k/-k for PE since that's the B0 direction.

As regards the case of unknown PEs, as @effigies I'd say better going to option 2 (two registration processes). However, it shouldn't be that hard to look at the disagreement map of the T1 mask linearly mapped into EPI space and the EPI mask. Then project to X and Y. The PE axis should show a bimodal distribution in the PE axis and monomodal in the FE axis.

EDIT: maybe it is not that easy :( because in the FE axis it will probably be bimodal as well. We'll need to look at the width of those histograms.

[effigies]

Current status: This performs the warping as expected and generates a report (currently SyN-registered reference EPI to the inverted-T1-in-EPI space).

Still in progress:

• PE-direction guessing (switching to MapNode, followed by BBR-based assessment, though making sure this works with FLIRT-BBR will be necessary)
• Atlas-based restriction of SyN warp

[effigies]

This is just about ready. I'm going to work on some documentation today and plan to release 0.5.0 by tonight.

[chrisgorgo]

+1

…

On Wed, Jun 21, 2017 at 3:57 AM, Chris Markiewicz ***@***.***> wrote: This is just about ready. I'm going to work on some documentation today and plan to release 0.5.0 by tonight. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#544 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkp_VtjxzKRtf39pG-KTTdzc3prE80ks5sGPcTgaJpZM4NuVYr> .

[effigies]

Added to the SDC docs, in the fieldmap estimation section.

It may make sense to move this workflow out of workflows.epi into workflows.fieldmaps, and manage its selection in a similar way to fmap and phdiff, but I don't want to hold this up further right now. That refactorization can come along with stabilizing, after we've had a chance to test the functionality more broadly.