Unreasonable registration result using antsRegistrationSyN.sh

[younghoo]

Operating system and version

Ubuntu 22.04.5 LTS

CPU architecture

x86_64 (PC, Intel Mac, other Intel/AMD)

ANTs code version

2.6.2-g52bc0ab

ANTs installation type

Downloaded Github release binaries

Summary of the problem

Dear experts,

I am trying to register a T1 image (skull-stripped, denoised, and bias-field corrected) to the MNI152 T1 template using antsRegistrationSyN.sh. However, the warped T1 image shows anatomically unreasonable deformations in some regions, as indicated by the red arrows.

When I use antsRegistrationSyNQuick.sh on the same image, the output looks more normal.

I have been using ANTs (v2.2) for a long time, and only noticed this strange behavior after recently updating my ANTs package.

Thank you for any help.

Fig1. T1 image in native space:

Fig2. T1 image in MNI space using antsRegistrationSyN.sh:

Fig3. T1 image in MNI space using antsRegistrationSyNQuick.sh:

Commands to reproduce the problem.

## Using antsRegistrationSyN.sh
antsRegistrationSyN.sh -d 3 -f ${MNIbrain} -m ${sour_dir}/t1_brain_bfc.nii.gz -o ${targ_dir}/t12MNI -n 1 -t 's' -x ${MNIregmask}
## Using antsRegistrationSyNQuick.sh
antsRegistrationSyNQuick.sh -d 3 -f ${MNIbrain} -m ${sour_dir}/t1_brain_bfc.nii.gz -o ${targ_dir}/t12MNI -n 1 -t 's' -x ${MNIregmask}

Output of the command with verbose output.

my_log.txt

Data to reproduce the problem

Sorry that the current data could not be shared publicly.

[younghoo]

To provide a reproducible example, I tested the registration on a T1 image from a public repository. This successfully reproduced the same unreasonable warping shown in my own data, as shown in the figures below. The raw data and preprocessed image for this test case is attached.

Fig 1. T1 image in MNI space using antsRegistrationSyN.sh:

Fig 2. T1 image in MNI space using antsRegistrationSyNQuick.sh:

Data: raw image (t1.nii.gz) and preprocessed image (t1_brain_bfc.nii.gz)

t1.nii.gz

t1_brain_bfc.nii.gz

[ntustison]

Can you provide more detail as to what you mean by the registration being "unreasonable"? For example, are the Jacobians negative? Or is it something else?

[younghoo]

Hi @ntustison, thank you for your reply. Regarding the deformations in the regions marked by the red arrows, I am uncertain if they truly represent an issue. However, my observation is that the warped gyri/sulci in these areas appear unusually thin and sharp, which seems less anatomically plausible. In contrast, the same structures produced by the SyNQuick version look smoother and more natural.

[ntustison]

Okay, if you don't have anything to point to that's systematic, I don't know that there's anything to fix. There is a built in diffeomorphic constraint in SyN that limits the registration from producing negative Jacobians, but there's nothing that would prevent "thin and sharp" gyri/sulci. I'm also not aware of any recent changes that would've changed SyN behavior.

[younghoo]

1. I have tested the registration with ANTs v2.2.0, and the warping pattern observed in v2.6.2 does not appear in this earlier version.

2. The SyNQuick script produces satisfactory results. May I use the SyNQuick output for formal analysis?

[gdevenyi]

I think the change here is likely the default SyN gradient/CC change from 0.1 and CC[4] to 0.2 and CC[2]

[cookpa]

I think the change here is likely the default SyN gradient/CC change from 0.1 and CC[4] to 0.2 and CC[2]

Yes, this is likely it. This can be reset with -g 0.1 -r 4. @younghoo if you're interested, you can try these options and see if you can get something closer to the earlier result.

As to SyN.sh vs quick, another important difference is the metric. Quick uses Mattes for deformable registration, which is MUCH faster but may be suboptimal. It's not really possible to tell conclusively from a single case, and the optimal parameters will surely differ across application domains, but in general I have heard from different users that CC is better for the deformable stage.

I notice also that the usage was not updated for the radius in the scripts, I will make a PR.

[younghoo]

Thank you, @gdevenyi and @cookpa ! I tested the registration with the parameters -g 0.1 -r 4, and the output yielded results more consistent with those from the older version. I believe this has solved my problem.

[cookpa]

Thanks for testing! The changes to the CC radius were made based on BRATS evaluation by @ntustison (#1828). I had wanted to update the step size for some time also, just based on my own usage and other community evaluation that has suggested a larger step size than 0.1 is best for SyN.

The CC radius might be the most influential here. There's some cost in computation time and it's possible that some local deformations will be missed out as a result of the larger radius, but if you're consistently seeing too much deformation it might be the right choice.

[gdevenyi]

P.S. my personal experiments have arrived at 0.4,4,0 and CC[4], but with a very different scale pyramid than the default ANTs configuration.