I had a look into your issue, and I think the problem is introduced earlier, at this point when we pad the image to have an even number of slices (otherwise topup will fail). The output image of that step is supposed to contain the DW encoding within its header, but it looks like that might not be the case for you.
We rely on the mrcat call to preserve the DW encoding table (which it should), but in some circumstances there are minor differences in precision that can be introduced by the way we handle certain aspects of b-value scaling, and I think this gets detected as a difference in the entries, resulting in the DW scheme information being labelled as ‘variable’ in the output image. We’ll need to investigate how to fix this in the next release…
In your case, it might be sufficient to strip the DW encoding information from the slice to be padded so that the subsequent call to mrcat doesn’t detect a mismatch, by adding -clear dw_scheme to the preceding mrconvert call, e.g. replace that line with:
run.command('mrconvert ' + dwi_path + ' -coord ' + str(axis) + ' ' + str(axis_size-1) + ' -clear dw_scheme - | mrcat ' + dwi_path + ' - ' + new_dwi_path + ' -axis ' + str(axis))
Hopefully that’ll fix it for you… Please give it a shot and let us know how it goes! If it works we’ll implement the fix on our side.
[NOTE: edited to add missing space mentioned in subsequent post]