Dwipreproc uses its own created mask not the one I specified on -eddy_options

Hi,

I am running dwipreproc using the following command:

dwipreproc "$SUBJECT"_dwi_denoised.mif "$SUBJECT"_dwi_preproc.mif -eddy_options "--mask=../"$SUBJECT"_dwi_denoised_brain_mask.nii.gz --niter=8 --fwhm=10,6,4,2,0,0,0,0 --repol " -json "$SUBJECT"_dwi.json -rpe_header -nocleanup -force -info

it always uses the mask created by itself not the one I specified
here is what I see on the terminal:

eddy_openmp --imain=eddy_in.nii --mask=eddy_mask.nii --acqp=eddy_config.txt --index=eddy_indices.txt --bvecs=bvecs --bvals=bvals --out=dwi_post_eddy --mask=../BIO-ALS-701-043-BL_dwi_denoised_brain_mask.nii.gz --niter=8 --fwhm=10,6,4,2,0,0,0,0 --repol

there are two --mask specified and the one used inside the dwipreproc-tmp-* folder is NOT the one I specified in the -eddy_options argument.
Thanks,
Meena

@jdtournier

I’m afraid there is no means currently of passing your own mask through to eddy using this approach. The code internally generates its own mask and uses that, so passing an additional one via -eddy_options means it’ll just be ignored (I’m actually surprised it doesn’t cause eddy to abort, to be honest).

I’m not sure there’s any way to do this using dwipreproc, but this might be something that could be included in the next release if there’s a good rationale for it. What do you reckon, @rsmith?

Thank you @jdtournier for your reply! The issue with the mask created internally in my dataset is that almost half the brain is removed! However, the resulted _preproc file looks fine to me.

Indeed – we’ve just been investigating this exact issue, as reported in this topic. We have a fix on our development branch, which should be easily back-ported to master as well (it’s a one-line change). But given that’s we’re about to push a new release, I don’t think it’s worth fixing on master at this late stage.

Unfortunately, this seems to be a long-standing bug – affects all releases since 3.0_RC1:flushed:

I’ll provide more details on the other topic.

Separately to the half-brain brain masking issue, there is indeed a necessity for dwipreproc to be able to run with a manually-defined mask, as evidenced by the pre-existing issue listing. I have a project myself where I would prefer to be using such. So keep an eye on that page for updates. In reality I should have had dwipreproc throw an error if “--mask” was included in the input to -eddy_options precisely to avoid this ambiguity, I just never got around to it.