Dwi2fod error - cannot open .txt image (group response)

1

Dear Experts,

I’m running into trouble getting the dwi2fod script to open my group (or individual) FOD .txt files. I am using the following commands:

First for each individual subject:
dwi2response tournier -fslgrad ${currentsubject}_1_mrtrix_new_bvecs ${currentsubject}_1_mrtrix_new_bvals ${currentsubject}_1_Bias_Field_Corrected_dwi.nii.gz ${currentsubject}_1_response_function_tournier.txt -force

Secondly, I then create a group response function:
average_response *.txt Group_average_response.txt

I have subsequently opened the text files with shview and all seems great, however, when I attempt to use the group response with the dwi2fod command it errors out and cannot open the .txt file. (see screenshot for error)

Screen Shot 2016-11-08 at 11.50.11 AM.png2006×95 29.1 KB

I have low b value data (b=1000) and only 56 directions but the response function seems correct (see screenshot)

Screen Shot 2016-11-08 at 12.00.57 PM.png1115×976 53.2 KB

Thank you in advance for the help,

James

2

It looks like you’re missing a lone - after dwi2fod msmt_csd… This is the expected syntax for a single shell analysis:

dwi2fod msmt_csd input response output

Without the dash in place of input, dwi2fod thinks argument 2 (your response) is the input image. What I don’t understand is why the error message isn’t that it’s got too few arguments though…

3

I think I had that flag when I ran it originally but just in case I reran it with it and i’m still generating this error. I’ve highlighted the flag in purple:

Screen Shot 2016-11-08 at 1.06.42 PM.png1657×398 199 KB

4

Scrap this message. I was missing a “-” at the end of the flag. My apologies.

James

1 Like
5

What I don’t understand is why the error message isn’t that it’s got too few arguments though…

This all got reworked when msdwi2fod was merged into dwi2fod. Can no longer rely on the parser to check the number of arguments since it’s algorithm-specific, but some common tasks are still performed before branching out depending on the algorithm choice. So input image is opened here, whereas number of input arguments is only checked here.

One option might be to try {} catch the input header open, and concatenate the error message with something more useful / specific, e.g.:
[ERROR] expected first argument after algorithm choice to be the input DWI; instead received "..."
?

6

OK, makes sense. I think we can still check the numbers of arguments to make sure it’s even and >=4. That would have caught the mistake above.

Not convinced about trying too hard to provide a more useful error message here. It’s clear enough that the command is trying to open the response as if it was an image. There’s lot of ways the command arguments could get messed up, I don’t think it’s worth the effort to try to predict them all…