Sorry I am not talking about the old viewer image, I am talking about the other brain data set further up, see post 9 in this thread, it was 2 days back.
I just realised something, for e.g. when I am making the tractography file through the tckgen command, do I have to specify the -grad encoding option then as well, because I didnt then, I just used it for the spherical convolution and estimate response function command. Could this have affected my analysis?
Cheers
Ah, yes. That one required a switch of the x & y components. If that comes from the same source, using the same sequence on the scanner, that is indeed not great. It’s actually worse than that again since things can get more complicated if the acquisition plane is tilted - the correct fix wouldn’t necessarily be a trivial flip or inversion of the components…
Not if you’re using an FOD-based tracking algorithm (the default). If you’d used the -algo tensor_det option or some other tensor-based approach, then you’d have needed it - but the chances are the command would have failed then anyway, telling you it couldn’t find the DW encoding…
So take home message for today is, I am going to have to resort to observing the images, and seeing which vector needs inverting and going from there? and run the estimate response command again…
Actually, given what you’ve shown me so far, I would personally recommend having a good chat with whoever provides you with the data, and making sure they verify everything they do and that what you get is correct. This is a major source of error, they really need to get it right.
Actually, probably not. We discussed this on another thread recently, and I think we were in agreement that the response should be OK.
So how do i incorporate the new encoding into the track?
OK another freaky thing just happend I used that
$ cat encoding.b | awk ‘{ print $1, $2, -$3, $4; }’
command
and all the values in the z vector I see on the screen when i type this are minus what is actually in the encoding file when i cross check it could this be the problem? for eg, using awk {…z value might be -3, but in real encoding file its 3. I dont know why it did this.
You’d need to run dwi2fod again with the updated encoding, but you should be able to use the same response you estimated earlier.
The whole point of that command is to invert the Z component… Note the -$3 in there. That’s the most likely problem with your current encoding file, this command is trying to fix it. See e.g. here for a intro to using awk - there’s plenty of tutorials online if you just search for them.
But just to complete these instructions, what you’d need to do is take the output and paste it into a new grad_fixed.b file. The simplest way to do this is to use I/O redirection, like so:
$ cat encoding.b | awk '{ print $1, $2, -$3, $4; }' > encoding_fixed.b
You can then try using that encoding_fixed.b file instead of your old one in dwi2fod, see whether that fixes things…
If it doesn’t work, you might need play around with that command by trying to invert other components (e.g. using -$1, $2, $3, $4 will invert the x component) or swapping then around (e.g. $2, $1, $3, $4 will swap x & y).
whoops silly me. Thanks a lot for your help. Appreciate it.