Mrconvert sanitise dw_scheme

1

I am attempting to preprocess datasets from a GE system using dwifslpreproc.

It is failing when eddy throws an error as it is unable to determine the hyperparameters.

Reading other posts on this forum it seems this error occurs due to entries in the dw_scheme of the mif header with zero vector components but non zero b-value i.e:

0,0,0,2500

My current work-around is to:

  1. Convert DICOM data to mif with mrconvert

mrconvert DCM dwi.mif

  1. Export the gradient table using mrinfo with the -dwgrad option

mrinfo dwi.mif -export_grad_mrtrix grad.b

  1. Edit the gradient file manually in a text editor (saving as grad_corrected.b)

  2. Converting the DICOM data to mif with the -grad option to load in the corrected gradient file

mrconvert -grad grad_corrected.b DCM dwi_corrected.mif

Is this the best approach or does a tool exist to sanitise the dw_scheme in the mif header directly?

Many thanks in advance for your help/advice

Stephen

2

I think it might be a bit more complicated unfortunately. If we assume the gradient information is correct, then the obvious question is what does it mean to have a non-zero b-value with a zero direction vector? When you edit your DW scheme, what do you replace that entry with? I assume you’d be setting the b-value to zero, given that there is no information about the direction of the DW gradient? That would be fine if that volume corresponds to a b=0 image that just happens to have the wrong DW information, but in my experience, that’s probably not what’s going on.

When I’ve come across this, it’s invariably been with Philips DICOM data, where for some reason they’ve decided to insert an additional volume at the end, which I’m guessing is a synthesized trace-weighted DW image (i.e. compute mean diffusivity from the data, then compute image of expected signal assuming isotropic diffusion with that mean diffusivity) – if anyone has better information on this, please let me know!

But the main point is: this volume is not a b=0 image, and clearly has a different contrast. By editing the DW scheme, you are providing corrupt estimates of the b=0 signal, which will go on to affect your results down the track (e.g. FA, MD, and multi-tissue CSD outputs) – assuming you have indeed been assigning these volumes a b-value of zero.

Assuming this also applies to your data, the better approach here is to remove the offending volume, which can be done using e.g. (for a 66-volume dataset where the last one is problematic):

mrconvert DCM dwi.mif -coord 0:64

For reference, this is an issue that we have been discussing, and it’s not clear what the best strategy is for dealing with it. We could make sure the DICOM conversion strips out these volumes, but I’m uncomfortable with the idea of our conversion quietly removing data, when there could legitimate reasons to keep them. We could make our code resilient to the presence of these entries, but it won’t help 3rd party tools or our interactions with them (as is the case here). We can ensure our scripts (like dwifslpreproc) strip out these volumes when interacting with eddy and any other external tools, but it might still cause problems for users who need to interact with 3rd party tools more directly. We’re open to suggestions here…

3

Donald

Thanks for your really helpful response, I don’t personally have any experience of Philips data so hadn’t encountered the issue with synthesized trace images before.

In this specific case, I know the volumes identified are definitely are b=0 volumes so I’ll continue manually.

Stephen

1 Like