Dhollander response function estimation

Dear MRTrix team,

I am trying to estimate the response function using the dhollander algorithm. I am getting an error but am not able to pin point exactly why. It could be because of the bright region at the back of the head that can be seen in a b=0 image but I wasn’t sure. Could you kindly help me fix this issue?

The command I ran is the following

dwi2response dhollander dwi.mif wm.txt gm.txt csf.txt

The error screenshot is below.


I also posted the dwi.mif here.

Thanks so much for your help!
Sincerely,
Nagesh

Hey Nagesh,

Hope you’re going well! :wink:

This looks like the algorithm runs out of voxels in the quest to find the SF WM response probably. I’ll take a look by running it offline and let you know what’s the problem exactly. Thanks for mentioning the particularly strange region; I’ll keep an eye on it in particular. I’ll report back in a few moments. :slightly_smiling_face:

Cheers,
Thijs

1 Like

Alright, that was funny. It’s not a problem with those brighter intensities, Nagesh. Also ignore my guesses above; it’s something else entirely.

The problem is caused by 2 volumes in the dataset that can’t be assigned to a shell: volumes 21 and 22 have a b-value of 350, unlike the rest of the data which roughly has shells for b=0,1000,2000,3000. So best to check what’s up with those volumes, and whether their b-value should’ve been different. In any case, it runs without issues to completion if you first remove those volumes, e.g. via:

dwiextract dwi.mif newdwi.mif -shells 0,1000,2000,3000

…and then run everything (dwi2response dhollander as well as any further processing, e.g. dwi2fod msmt_csd) on newdwi.mif.

I tested both steps: got great responses (checked all internal workings of dwi2response dhollander: all works robustly without issue on your data) and good CSD results using those responses. Nagesh, do check whether those 2 volumes should’ve had a different b-value or something. But if you don’t need them, get rid of them with the above command to resolve all problems. :slightly_smiling_face:

Cheers & take care :wave: ,
Thijs



The exact reason why it crashed initially can be traced back to a bug in dwi2fod msmt_csd, which seems to produce all zero outputs under the very specific conditions of volume(s) not being able to be assigned to a shell combined with at least 2 tissues. No issues if it’s just one tissue. :man_shrugging:

1 Like

Hey Thijs,

Thank you so much for such a quick response and great fix, and actually checking the data all the way through the CSD! Such help is unparalleled elsewhere in my professional world, Thijs!

Yes, I had seen that warning about two volumes not being assigned to a shell and after googling around, read Rob’s post here and assumed that it would have be taken care of automatically, thinking they would be internally rejected by the processing. Thanks for also pinpointing where the crash actually originated from! But yeah, I think such care should be taken at the input level.

We actually have more volumes with b=350 but the reason there are only two here is because of the outlier based volume filtering from eddy_quad in FSL. I will be careful to check that there are enough volumes left at each shell with this filtering process and if there are too few (say less than six) to form a shell, we will completely remove that b-value data.

Thanks again for such an invaluable help, my friend, and hope all is well with you and your loved ones too!
Sincerely,
Nagesh

1 Like

Hey Nagesh!

No worries at all. :slightly_smiling_face:

Just briefly:

Yeah, it should’ve actually worked. It seems to be a very particular, incredibly specific bug. See here in the meantime: dwi2fod msmt_csd : all zero output when nonassignable volume(s) to shell(s), with at least 2 tissues · Issue #2129 · MRtrix3/mrtrix3 · GitHub . So far it’s still a bit of a mystery what exactly happens.

Regardless though, it’s indeed a good idea to fix up the data up front; especially in your context:

In that case, it might otherwise variably have a b=350 “shell” or not, depending on the number of outliers. You don’t really need the b=350 data by the way. If anything, such low b-values rather cause issues with a 3-tissue CSD fit sometimes. If you’re aiming to set up an automated pipeline that should behave relatively consistently, you could consider to simply remove the b=350 data even before preprocessing (eddy, etc…). But if the scenario is more (semi-)supervised, you can of course check manually after eddy if there’s enough volumes. :slightly_smiling_face:

No worries at all. All good here, even though we’re locked down once more in Melbourne. :wink: But friends & family both back in Belgium as well as over here, are all well!

Cheers,
Thijs

Hey Thijs,

Thanks so much! Just wanted to followup to learn a bit more!

So far it’s still a bit of a mystery what exactly happens.

Yes I have been following that issue! Thanks and kudos to you and Donald for such a thorough investigation! Another reason it makes me have so much faith and confidence, and pleasure in using MRTrix3.

In that case, it might otherwise variably have a b=350 “shell” or not, depending on the number of outliers. You don’t really need the b=350 data by the way. If anything, such low b-values rather cause issues with a 3-tissue CSD fit sometimes. If you’re aiming to set up an automated pipeline that should behave relatively consistently, you could consider to simply remove the b=350 data even before preprocessing ( eddy , etc…). But if the scenario is more (semi-)supervised, you can of course check manually after eddy if there’s enough volumes.

Got it! For consistency, I will simply exclude the b=350 for this analysis. Just to understand more, are you saying we don’t need the b=350 in estimating the response function? Would low b-values cause issues to the 3-tissue CSD fits because it is harder to distinguish between the three different types of FODs at such low b-values? Or is there a different deeper reason?

All good here, even though we’re locked down once more in Melbourne. :wink: But friends & family both back in Belgium as well as over here, are all well!

Wonderful to know that you are all doing well. COVID’s truly a complicated situation and it is convolving so many issues in the U.S. most likely because it’s an important election year here. I think I should avoid long political comments on this platform but it seems to me that Melbourne made a much, much wiser decision by locking down for the second time. Hoping the world recovers from all the COVID effects relatively soon!

Thanks again!
Best,
Nagesh

Hi Nagesh,

There was indeed a bug that your particular dataset triggered. I’ve just pushed a fix for it here – I’d appreciate if you could confirm that it fixes the issue for you too (seems to on my system):

git checkout master
git pull
./build

and try dwi2response again.

[EDIT: the fix has already been merged to master]

Hi Donald,

Yes it works now on my end now even without removing the two b=350 volumes. I will still remove the b=350 volumes for my analysis but the code works now!

Thanks again for all your help.
Best,
Nagesh

1 Like

Great to hear, thanks for the feedback!

1 Like