I failed to run dwi2response.
It failed to generate a dwi_b0_mean file during the procedure. Here is the log file.
Command: dwi2response -quiet tournier dwi.mif wm_ss_response.txt -mask wm_mask.mif -voxels wm_sf_mask.mif
Command: dwiextract dwi.mif -shell 0.0 dwi_b0.mif -quiet
Command: mrmath dwi_b0.mif mean dwi_b0_mean.mif -axis 3 -quiet
mrmath: [ERROR] Cannot perform operation along axis 3; image only has 3 axes
dwi2response: [ERROR] Command failed: mrmath dwi_b0.mif mean dwi_b0_mean.mif -axis 3 -quiet
Any idea for this? Thanks in advance.
OK, looks like there’s only one b=0 volume in the data, and the command responsible for averaging the b=0 volumes fails because a single volume comes out from the previous command as a 3D image, so there is no 4th axis to average over. This feels reminiscent of a discussion we had a while back…
So to fix this will require modifying the script and/or the commands used; the following is for developers mostly…
One option is to make due
dwiextract outputs a 4D image even when there is only one volume to produce - that would be the simplest fix, and to be honest I’m surprised that’s not the default behaviour. Other option is to modify
mrmath to allow operations along non-existent dimensions where they make sense - i.e. treat them as singleton dimensions. In general, it might be good to implement both changes anyway, I think they both make sense individually anyway…
Thank you very much fro your reply.
I got your point. But I am afraid it’s tricky to me for modifying the dwiextract or mrmath and let them handle 3D image correctly in this case.
An alternative idea, can I resume the dwiresponse with the correct dwi_b0_mean.mif, given I can access all of temporary files? Is it possible to create a txt file to save the commands used in this procedure?
Sorry, I should have been clearer: most of the information was intended for the other developers, we’ll need to fix this internally. Otherwise, yes I assume you’d be able to resume from where it left off, but I’m not sure exactly what the process might be for this. No doubt one of the others can help out on that front…
Got it. Thank you. Anyway, I would like to try
-continue <TempDir> <LastFile> first.
OK, this shouldn’t be too hard for me to fix. The script is in fact already checking the dimensions of the
dwiextract output to see if the
mrmath call is required. However, it’s just checking to see if the image is 3D; it fails to recognise that the image is 4D but with a single volume. My guess is that
dwiextract only collapses the output to a 3D volume if there’s a single b=0 volume and the
-bzero option was used, but doesn’t do the same if you use
-shell 0. I should be able to push a fix or this in ~12 hours.
Thanks for the report!
Cool, thank you very much.
@Meng OK the script should be fixed now.
The problem wasn’t what I initially guessed: The script wasn’t detecting the number of image dimensions correctly, as it was calling
strip() instead of
split() on the axis dimensions provided by
mrinfo. So basically, a typo.
@rsmith, it works now. Thank you for your help.