dwipreproc: Rework odd axis dimension solution

[Lestropie]

Currently, if the SE-EPI image series provided to topup has one or more spatial axis with odd dimension, these images are cropped by dwipreproc; if this is not performed, topup crashes when it tries to downsample the images. However the resulting field is currently passed to eddy as-is (and this worked for my testing in the past). This situation now however results in eddy crashing with: "Image Exception : #3 :: Attempted to add images/ROIs of different sizes"

So, a few things then:

• Could simply perform a corresponding crop of the DWI input series as well, and this would probably work in most situations.

• It would however be better to pad the images by duplicating the outermost slice (for each problematic axis), then crop those padded slices out after eddy has completed.

• More fundamentally though, this would suggest that at some point, the output field from topup and the input DWIs to eddy are being concatenated and hence assumed to lie on the same grid. Therefore, if the two main inputs to dwipreproc (i.e. the DWI and the -se_epi option) are not on the same image grid, cropping / padding axes only solves one of a number of problems. The most general solution would be to use topup to estimate the field, register the input to topup to the input to eddy, re-grid the estimated field to that of the input DWIs, then run eddy. This is basically the second option described for #874. It is however made more difficult by the fact that the primary output from topup (i.e. the one that eddy actually uses) is parameterised as spline coefficients, and therefore resampling these spline coefficients based on a new voxel grid would be quite tricky.

What I thought may have been the best approach is:

• If the DWIs have one or more axes with odd dimension, pad appropriately.

• If provided separately, resample the SE-EPI images to the same voxel size & dimensions as the DWIs.

• Run topup.

• Perform rigid-body registration such that the corrected output from topup, when simulated to have the same phase-encoding as the first volume in the eddy input, is aligned with that first volume in the eddy input.

• Run eddy.

This however would only work if eddy were to honour the header transformation in the topup output field image (the one containing the spline coefficients). If it doesn't (as I suspect is the case, given that it appears to be concatenating this field with the DWIs), then this approach doesn't work.

So, thinking aloud, here's an alternative:

• Pad DWIs for odd dimensions as before

• Run topup on the native SE-EPI data (padding odd dimensions if necessary)

• Simulate what the topup corrected output image would look like if it had the same phase encoding as the first b=0 volume in the DWIs, and perform the rigid-body registration

• Resample the SE-EPI images to the (potentially padded) DWI voxel grid, incorporating the rigid-body transformation estimated in the previous step

• Run topup a second time, on these re-gridded SE-EPI images.

• Run eddy in the knowledge that the estimated field is both aligned with, and on the same image grid as, the DWIs.

• Remove padding slices if necessary.

:face_with_thermometer:

[Lestropie]

OK, this won't work either: It requires the ability to define an arbitrary orientation of the phase encoding direction in DWI image space, but topup doesn't allow the k-component of this direction to be non-zero.

So to make an approach like this work requires loading the field spline coefficients file, applying the estimated rigid-body transform, re-parameteristing the spline, and then saving new coefficients. Which would mean duplicating & augmenting FSL's spline field code... I have to draw a line in the sand at some point. I can fix the issue with odd axis dimensions, but I'm still stumped on #874.

[Lestropie]

Closed by #1159.