How to pad a slice to data for topup

1

Hi
I am trying to use topup.
When I do so I get the error message
Topup: msg=topup_clp::topup_clp: Subsampling levels incompatible with image data.
which googling tells me could be because my data has an odd size in one direction - which my data has and I also recall that dwifslpreproc complained about that and informed me that it pads a slice…

Sooooo. I could fire up matlab and do my some wizz stuff padding a slice. But that seems cumbersome when actually not working in matlab atm.

command line approaches?
M.

2

Have you tried mrgrid pad?

3

In dwifslpreproc I use an mrconvert call to grab the first slice, and then mrcat that with the original image. That code was written before mrgrid was, hence the hack.

Couple of other notes:

  • FMRIB’s solution to this in 6.0.0 seems to have been to provide alternative topup config files, one of which does not perform downsampling and hence does not require even axis sizes. I have a change coming hopefully in 3.1.0 that enables providing dwifslpreproc with a configuration file that it should then provide to topup.

  • If the issue is along the slice encoding axis, and you’re intending to perform slice-to-volume correction, and you’re intending to execute EddyQC, the padding approach is no good. In dwifslpreproc, I explicitly add the padded slice to the same slice group as that of the duplicated slice, so that eddy_cuda is happy. However, EddyQC demands that each slice group have the same number of slices. So either I’d need to instruct dwifslpreproc to modify all of eddy's outputs (not just the DWI output) to remove all trace of the padded slice, or a topup config file that doesn’t invoke downsampling needs to be used (see point above).

    I’ll take this opportunity to deter people from using acquisitions with an odd slice count… :pleading_face:

4

Hi Robert
Well yes all three of your conditions are true.
I hear your recommendation of using even slices…
That might work for the future, but not the past.
The alternative of course is cropping a slice, right?
That should solve all these issues…
M.

5

The alternative of course is cropping a slice, right?
That should solve all these issues…

dwifslpreproc I believe did crop in order to reach even axis sizes once upon a time; but I changed it to padding because unlike cropping it doesn’t result in a loss of information in the output image.

Also, cropping would not resolve the odd-slice-count → padding → EddyQC issue: you’d still have a non-square slspec matrix, you’d just be reducing the number of slices in one of the groups by 1 rather than increasing.