‘dwi2response dhollander’ script outputs error

Hi MRtrix3 experts,

I want to evaluate the performance of ‘dwi2response dhollander’ script on single-shell data with 2 unique b-value(s): 0 and 1000.
For this purpose, I’ve run the following command:

dwi2response dhollander dwi_denoised_eddy_unbiased.mif response_wm.txt response_gm.txt response_csf.txt

However, I got the following error inspecting the dwi2response-tmp-LNTX33 folder:

mrconvert voxels.mif /Volumes/WD_Elements/BROAD/DTI/Fixel_Based_Analysis/subjects/sub-52/dwi2response-tmp-LNTX33/voxels_sfwm.mif -copy_properties /Volumes/WD_Elements/BROAD/DTI/Fixel_Based_Analysis/subjects/sub-52/dwi2response-tmp-LNTX33/dwi.mif -append_property command_history "/Users/davidemomi/mrtrix3/bin/dwi2response \"tournier\" \"dwi.mif\" \"_respsfwmss.txt\" \"-sf_voxels\" \"1825\" \"-iter_voxels\" \"18250\" \"-mask\" \"refined_wm.mif\" \"-voxels\" \"voxels_sfwm.mif\" \"-tempdir\" \"/Volumes/WD_Elements/BROAD/DTI/Fixel_Based_Analysis/subjects/sub-52/dwi2response-tmp-LNTX33/\"  (version=3.0_RC3-206-g80288328)"

mrconvert: [ERROR] unknown option "-copy_properties"

Do you have any suggestions?

Thanks

Hi @Davide_Momi,

The error that you’re getting here is a bit strange: it indicates your local install has a version of the relevant scripts of the older method that relies on a functionality of mrconvert (the -copy_properties option) that however seems to not be present in your mrconvert. Could it be that you updated your local install at some point via git pull, but didn’t run ./build subsequently?

However, scientifically, you should be aware that this is in the mean time an outdated version of this algorithm that I would personally no longer recommend myself, as I’ve found that the subsequent CSD fit can be (sometimes drastically) improved by a newer, better version of the algorithm. I’ve presented this improved version recently in an ISMRM 2019 oral session. Here’s the relevant ISMRM abstract. I uploaded a video recording of the talk to YouTube for public access/viewing of the scientific findings as well.

As you only have single-shell (+b=0) data, I highly recommend using the 3-tissue response functions as output by the newer version of dwi2response dhollander with single-shell 3-tissue CSD (SS3T-CSD). Others have reported their experiences with the newer version of dwi2response dhollander combined with SS3T-CSD on very similar data (e.g. b=1000 specifically). Here’s some of that feedback (so you can anticipate what’s to be expected generally): https://github.com/3Tissue/MRtrix3Tissue/issues . So far, the results seems to be very encouraging and in line with my own experiences over the past years researching and developing these techniques.

To allow the scientific community consistent access to these particular methods so they can be reproduced reliably at the present time, I’ve made them available in a fork of MRtrix3, of which all details and information can be found over here. The documentation specific to the newer dwi2response dhollander and SS3T-CSD can be found over here. Feel free to report feedback (be it good, bad or in between; or any issues) as mentioned over there!

All the best,
Thijs

Hi @ThijsDhollander,

thanks for your follow up, it was really helpful. I just update the mrtrix3 and I was finally able to run the command

dwi2response dhollander dwi_denoised_eddy_unbiased.mif response_wm.txt response_gm.txt response_csf.txt

However the response_wm looks weird to me (see image below)

49

it supposes to be different right?

Moreover, even though I’ve updated mrtrix3 I wasn’t able to find the ss3t_csd_beta1 command. So I’ve basically downloaded the source code from this link:

and then I’ve just copied and pasted the ss3t_csd_beta1 into mrtrix/bin directory.

Do you think this is the correct procedure?

ps: I’ve preprocessed my data without Gibbs ringing removal. Do you think might be a problem? Should I preprocess the data from scratch?

Thanks

Davide

Hey Davide,

Yep, makes sense it would/should work now. However, to be clear wrt to what I mentioned above: while it now works, you’re still using the 2016 version of the algorithm now (without the 2019 improvements I referred to above). That’s ok, but it can certainly be improved upon, in my experience and that of collaborators.

No, that makes sense: what you’re seeing there is the WM response for b=0, which is indeed isotropic (a perfect sphere) at that b-value. You can see this is the first b-value of 2 total b-values in the response function by looking at the title bar of that window; i.e. where it says [ 1/2 ]. You were probably expecting to see the b=1000 part of it. :slightly_smiling_face: You can navigate between b-values in that viewer by using the left and right arrows on your keyboard. So just pressing the right arrow on your keyboard should reveal the b=1000 part, which should look like a medium-fat-ish disk(-ish). Definitely not a sphere though; you’ll see. :wink:

Sorry, this must’ve not been sufficiently clear from my above explanation; I kept it short on purpose to not bother people. SS3T-CSD is not available in MRtrix3, but only in that particular personal fork. It’s set up as such because it relies on specific functionalities which are only available in a certain state of the further development code. This fork is in that particular state, to allow the command to work reliably in the environment it expects. Copying and pasting the command into another install won’t work, for that very reason. Even if it would seem to work, it’s not reliable currently. To install this, you should create a separate install; the essence of the instructions for this fork are found here. If this is confusing, I hope this explanation would give some insight in where the fork is currently positioned version-wise. I’ll get in touch privately to help, if needed, with this bit; I’m not keen on triggering sensitivities over here unnecessarily.

This is not per se a huge problem. Until a few years ago, this correction step didn’t exist yet, so there’s lots of people who ran pipelines without it for sure. That said, I would always recommend this step though: it’s a very robust Gibbs ringing correction method, and if you’re interested in quantifying subtle or very local or specific effects, Gibbs ringing can certainly mess a bit with that in very local particular areas. So it’s in principle always a no-brainer in any preprocessing pipeline at this stage.

Cheers,
Thijs