Motion correction disabled in config file?

[joey-scanga]

Hello,

I was just curious, what's the reasoning behind setting --estmov to 0 in the topup config file sdcflows uses for PEPOLAR correction?

It looks like there was an issue before where topup would run really slow #279 and the solution was to run RobustAverage to create a reference frame, align fieldmap frames to this reference, then feed into topup (correct me if this is inaccurate!), but these docs suggest you're supposed to use topup's internal movement-correction model so it can estimate the off-resonance field simultaneously: https://fsl.fmrib.ox.ac.uk/fsl/docs/diffusion/topup/FAQ/index.html#what-if-the-subject-moves-between-the-two-acquisitions

[effigies]

@oesteban will have looked into this more, but I can't be sure from that doc whether the internal motion model simply means "we align the images before estimating the field", or if there's a more subtle interaction of the motion parameters and the field.

A large out-of-plane rotation will change the field in a way that is not consistent with the field being constant in the space of the object. So when pairing the two images it is no longer true that there is a single field that can explain the distortions in both images. That is a second order effect though, and in general the estimated field is a useful representation even in the presence of large such rotations.

This makes me lean toward the former, and their spline-fitting model is not accounting for motion itself. I am curious if @pauldmccarthy knows any better.

Just to crossref relevant PRs:

• FIX: Revise the TOPUP workflow and related utilities #278 set --estmov to 0
• ENH: Calculate robust average of EPI inputs to TOPUP workflow #280 set up RobustAverage

[joey-scanga]

Definitely could see that being the case! I was just curious about this choice after comparing the sdcflows default topup config with what the dHCP pipeline uses... from what I gather dHCP is just using what they estimate to be the "best" fieldmap frame based on how the field looks after running topup on each frame, so the flag being set in that case probably makes no difference anyway (if I'm understanding correctly).

Thanks for the quick reply!

[pauldmccarthy]

Hi @effigies @joey-scanga, I'm not particularly knowledgeable about the topup internals, but I'm fairly sure that it simultaneously estimates both movement and field strength - i.e., the movement parameters form part of the cost function that is being minimised via nonlinear optimisation:

https://git.fmrib.ox.ac.uk/fsl/topup/-/blob/master/topup.cpp?ref_type=heads#L142-169

I can't comment on whether running motion correction before topup is advisable/preferable, but Jesper's (eddy/topup author) opinion has always been that everything should be modelled simultaneously.

Is there a chance that the performance degradations reported in #279 were due to an OpenBLAS-related performance issue that we resolved a few years ago, rather than due to the nature of the input data?

[oesteban]

I was just curious, what's the reasoning behind setting --estmov to 0 in the topup config file sdcflows uses for PEPOLAR correction?

We assume we're feeding realigned data already. Long-term vision is to replace topup with an ANTs-derived tool.

Short-term, this could be enabled, but would require some adjustments when the volumes are of different sizes and/or spatial resolution.

On top of that, if --estmov were enabled, we would not handle the estimated motion in generating the EPI references corrected for SD. We could use the ones produced by topup, but again, this increases the dependency surface on it and we want to move away from it.

I can't comment on whether running motion correction before topup is advisable/preferable, but Jesper's (eddy/topup author) opinion has always been that everything should be modelled simultaneously.

I agree, but, as I mention above, we currently don't handle the outputs. Maybe we should revisit that.