Dear Lulu

Would you please share the script which could rotate the bvecs table after running "Eddy" tool for me ? I also want to correct the corresponding bvecs table after running Eddy. 

Many Thanks

Best

Paul

---

Date: Mon, 14 Oct 2013 20:38:12 +0800
From: [log in to unmask]
Subject: Re: [FSL] questions on eddy and topup preprocessing
To: [log in to unmask]

 

Dear Jesper,

 

        Sorry about the mistake, I wrote  the X as a N*3 matrix. 

 

Yours,

Lulu

 

At 2013-10-14 20:24:55,"Jesper Andersson" <[log in to unmask]> wrote:

Dear Lulu,

         Thanks so much for your quick reply. X is the full 3*N matrix, and I changd the formula to mulitiply X(:, a). It still gave me such error information

"??? Error using ==> mtimes
Inner matrix dimensions must agree."

 

Since RX, RY,RZ are three 3*3 matrix, and so was their multiplication's inverse, while the X is a 3*N matrix (N is full volume, in our experiment, it's 63). When we multiply two matrix the row of the first matrix must be matched to the column of the second matrix. And in the formula now, they are not matched.  Is there something wrong I misunderstand?

You need to confirm that Rx Ry and Rz are indeed all 3x3 matrices, and that X is 3xN. If that is the case inv(Rx*Ry*Rz)*X(:,1) should be a valid operation.

 

One more question: since our data was scanned in three acquisitions, and each has a b0 image (obtained by Siemens, dcm format), when I tried to merge all dcm files into a 4D.nii.gz file using mricron, I found that the software would change all dcm files into three 4D.nii.gz file. So I used the flag fslmerge to merge them into one 4D file. Is this an appropriate way, or there are some other ways to change the dcm files into one 4D file in case of losing information?

Is there an fslmerge flag in mricron or do you mean that you run the application fslmerge after you have run mricron? Either way I don't see a problem with it. Any conversion from DCM to nifti will cause a loss of information, not because of the conversion softwares but simply because of the nifti format.

Jesper

  

 

Yours,

Lulu

2013/10/14 Jesper Andersson <[log in to unmask]>

Dear Lulu,

Thanks for your reply, I encountered some new problems. Since our data was scanned in three acquisitions, and each has a b0 image (obtained by Siemens, dcm format), when I tried to merge all dcm files into a 4D.nii.gz file using mricron, I found that the software would change all dcm files into three 4D.nii.gz file. So I used the flag fslmerge to merge them into one 4D file. I wonder that if this was ok, or there are some other ways to change the dcm files into one 4D file in case of losing information?

I finished doing eddy using method above, and obtained the eddy_corrected_data file and the txt file, but I encountered some problems about how to rotate the bvecs file. I read the manual here http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/EDDY/Faq, but I still couldn't understand how to do rotate the file with my limited knowledge of scripting. We wrote script below and found that the dimension of X is 3 * n_volumes, while the dimension of "inv(RX*RY*RZ))"is 3*3. Since formula has been pre-multiplication, I found it may not be able to multiple them(maybe I misunderstood this). Would you please give me some suggestions about this?

%abstract the fourth, fifth and sixth volume from the txt file obtained in the last step.

Y1=Y(:,4);

Y2=Y(:,5);

Y3=Y(:,6);

% Then calculate

for a=1:1:63

RX=[cos(Y1(a)) sin(Y1(a)) 0;

-sin(Y1(a)) cos(Y1(a)) 0;

0 0 1];

RY=[cos(Y2(a)) sin(Y2(a)) 0;

-sin(Y2(a)) cos(Y2(a)) 0;

0 0 1];

RZ=[cos(Y3(a)) sin(Y3(a)) 0;

-sin(Y3(a)) cos(Y3(a)) 0;

0 0 1];

x'(a)=(inv(RX*RY*RZ))*X

Is X here the full 3xN matrix? If so those are the b-vectors for all the volumes whereas R only pertains to the current volume. You need to multiply X(:,a) instead.

Please test this code carefully before using it so that you are sure you have gotten all the signs right.

end

If I finished using eddy, do I also need to run applytopup?

No, eddy does also the job of applytopup.

Jesper

Thanks in advance!

Yours,

Lulu

2013/10/10 Jesper Andersson <[log in to unmask]>

Dear Lulu,

I checked the qform/storm in these three b0 images, and found that qform of b0_19.nii.gz image scanned by the 19 orientation gradient table was different  from the other two. I listed them below. Is there any way for me to solve this problem?

 

(1)  b0_19 orientations:

qto_xyz:1 -1.718750 0.000000 -0.000000 109.325317
qto_xyz:2 0.000000 1.691586 -0.301044 -80.299522
qto_xyz:3 0.000000 0.304364 1.673132 -40.676346
qto_xyz:4 0.000000 0.000000 0.000000 1.000000 (2)  b0_20/21 orientations: qto_xyz:1 -1.718750 0.000000 -0.000000 107.975891 qto_xyz:2 0.000000 1.691586 -0.301044 -81.648949 qto_xyz:3 0.000000 0.304364 1.673132 -40.676346 qto_xyz:4 0.000000 0.000000 0.000000 1.000000

It looks like there was some small repositioning of the subject between the two runs. For the future, try to avoid that if possible. For now I don't think that is a problem. I think the message from fslmerge would just have been a warning to let you know what had happened, but that it still merged the files. It should be easy for you to check using fslview. It means there will be a change in position in the data, but hopefully eddy will be able to detect and correct that.

But, it is still not clear to me if you have acquired data with different blip directions? As I said, your acqparams.txt assumes you have, and it is also the only way in which you will be able to correct for susceptibility distortions.

Jesper

2013/10/7 Jesper Andersson <[log in to unmask]>

Dear Lulu,

I was trying to do pre-processing with our high angular resolution diffusion data from Siemens 3T.The acquisition was divided into 3 consecutive scans of 5 minutes each, to improve the comfort of the subject. They consisted of three blocks of 19, 20 and 21 orientations each. Each of these three acquisitions have one b0 images.

I read the manual of fsl's tool 'eddy' and 'topup', and I think that our data could be correctd(eddy current and suscepbility problem) by these two tools (Am I right?).

I extracted three b0 images, and tring to merge them together, but it gave me an error:

'fslMerge fault:Inconsistent orientations for individual images when attempting to merge.

Merge will use voxel-based orientation which is probably incorrect -*PLEASE CHECK*!'

I am not sure that if this problem is related to my gradient orientation, and if this problem would influence my following processing.

I don't think this has to do with your gradient directions. It sounds either like a round off error in the voxel size fields, or the storm/qform is different. I suggest you use fslhd to check those things.

Another problem is about the acqparams.txt file. Since we have three b0 images, and our phase encoding direction is R>>L, EPI factor is 128, echo spacing is 0.85 ms, I wrote the acqparams.txt file like this

" 1 0 0 0.108
-1 0 0 0.108
1 0 0 0.108
-1 0 0 0.108
1 0 0 0.108
-1 0 0 0.108"

Is this the right way to write the acqparams file for our three b0 images?

There is documentation about how to write these here http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/TOPUP/Faq and here http://fsl.fmrib.ox.ac.uk/fsl/fslwiki/EDDY/Faq.

However, it is not clear from your description if you acquired b=0 scans with reversed phase encode blips. Your acqparams file implies you have six b=0 files acquired R->L, L->R, R->L, L->R,  R->L, L->R in that order. Is that correct?

Jesper

  

Thanks in advance!

Lulu