Half a brain lost after eddy?

Hi guys,

Since dwifslpreproc calls FSL’s eddy to do its thing, I figured I’d ask here about it here as well, to get more perspectives on the issue.

I have been performing eddy on some scans I have. The subjects are animal brains scanned ex-vivo (therefore very little movement between volumes/directions) so I expect little changes after eddy (my supervisor told me that we don’t need to apply topup for these scans, but nonetheless we still have to apply eddy before FDT and getting DTI values for stats). So I performed eddy using only the mandatory inputs (bvals, bvecs, acqp, index, mask and dti data) and for most scans this worked fine. I haven’t used any additional option like repol or anything. Only the mandatory commands.

The masks were not prepared using bet, though. Since bet was giving me aberrant results (apparently bet works well for human brains on skulls, and I’m working with animal scans without skull, namely ferrets, sheep and mice), I opted for using select_dwi_vols to extract all volumes for b4000, average them using fslmaths and then thresholding using fslmaths -thr at a value that created a mask capturing the whole brain. As mentioned before, this apparently worked fine for most scans as I could see in their eddy_out files.

However on some scans I experienced loss of a substantial amount of data, even when the subject showed little to no movement in the acquisition. The only movement experienced during the acquisition I show here, for example, is a slow shift of the brain towards the left, on a total of 81 volumes, which the mask is a bit bigger towards the sides (see top image below). But the output is missing half the data (see bottom image below). How can this be prevented?

On other scans I lost a bit of data even when the subject experienced no movement during acquisition (brain embedded in agar). Could in this particular case be due to field inhomogeneities (that should have been corrected using topup even when my supervisor told me we could safely skip it)? How sensitive is eddy to these inhomogeneities? I’m asking because the loss of data in that case coincided with a region that is a bit dimmer than the rest of the scan. But to be honest that’s just an observation since I’m really not sure what is causing the issue, and I find it strage because in other cases I experienced no loss of data even when there were these differences in brightness in some regions. The acquisition protocol is exactly the same for animals from the same species, but the process has failed in only a handful. The eddy command is also the same for all of them (since I performed eddy in a HPC using a script with a loop).

module load fsl
eddyfolders=`find $1 -name '*' -type d -maxdepth 1 -mindepth 1`
for SPEC in $eddyfolders
    cd "$SPEC"
    eddy --imain="${SPEC}.nii" \
    --mask="${SPEC}_mask.nii" \
    --index="${SPEC}_index.txt" \
    --acqp="${SPEC}_acqp.txt" \
    --bvecs="${SPEC}.bvec" \
    --bvals="${SPEC}.bval" \
    --out=eddy_out \
    cd ..

Thanks for your help and insights!!

Not sure how much I can help here, but just something to look into to try to figure this out:

  • the truncation of the data through the image volume like you’re showing is what I’d expect to happen is one or more of the volumes ends up seriously misaligned relative to the others following motion correction. If I recall correctly, eddy doesn’t fill in the data in regions where all the volumes don’t overlap. Take a look at the motion parameters if you have them, and see whether they’re sensible – they should correspond to minimal / no motion, but maybe one or two of them will stand out as being particularly off, which would explain this. Also, go through the corrected images and check whether any of them look really badly out of place (though for the latter, I suspect eddy's outlier rejection might mask the issue).

  • for the second issue, it’s a bit harder to figure out from your description what the problem is exactly, but it sounds to me like this might be a masking issue? Does the mask you supplied to eddy contain the affected regions?

Thanks for your insights, J-Donald =)

I’ve enquired around and have been told that this issue persisted in eddy up until v6.0.3 but it has been solved in v6.0.4. The version that is available in the HPC is v6.0.3 so I have asked to have it updated. The issue is apparently that eddy had issues distinguishing subject motion from simple linear drift (which happened to this particular dataset). I’ll see if things improve after update and then come back to this problem if required.