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…
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…
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.
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.