Hi Chiara,
We also have a GE 3T scanner and topup works fine even if the last column acqparam.txt is set to 1's
We use A/P P/A PE directions so acqparams 1's and -1's are in second column (just like the FSL wiki page).
For L/R R/L, it would be 1's and -1's in the first column.
Best,
Danny Kim
________________________________________
From: FSL - FMRIB's Software Library [[log in to unmask]] On Behalf Of Jesper Andersson [[log in to unmask]]
Sent: Wednesday, September 28, 2016 8:28 AM
To: [log in to unmask]
Subject: Re: [FSL] problems with Topup on GE sequence
Dear Chiara,
if you email me your exact topup command line and put all the files alluded to in that command in a tar-ball and upload that to
https://oxfile.ox.ac.uk/oxfile/work/extBox?id=72139C7E463068D5F
I can have a look for you.
Jesper
On 28 Sep 2016, at 16:43, Chiara Pinardi <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Dear Jasper,
I checked the datain file and there are no problems in it; in the script the configuration file is present and the file is physically present on the pc, so I'm afraid that the last possibility is some problems with the reversion of the phase encoding direction.
The strange thing is I'm sure that I gave the command for the inversion on the scanner (I personally changed the value of the variable "pepolar" from 0 to 1 and this would correspond to the inversion) and if we check with fslview the two images are different, namely have a different distortion.
Any hint for verify the phase encoding direction in a different way?
2016-09-28 14:55 GMT+02:00 Jesper Andersson <[log in to unmask]<mailto:[log in to unmask]>>:
Dear Chiara and Sjoerd,
I don’t think the ETL can be the culprit here. Giving the wrong value for the fourth column of the --datain file would not affect the results in terms of how well the images are corrected. It would only affect the scaling of the _fieldcoef output.
Typically when topup doesn’t work it is because one thinks one has input two volumes with different PE, when in fact they have the same PE. Or one has put a non-zero value in the wrong column of the --datain file. Or one has run it without a configuration file.
Jesper
On 28 Sep 2016, at 14:36, Chiara Pinardi <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Hi Sjoerd, thank you for the reply.
I will try this method for the calculation of the ETL: my ETL value was taken in the CVs menu (as EPS), maybe I had chosen the wrong acronym.
As you are an expert GE user, I've another question for you: the value of EPS I found was "684" (I interpreted it as "0.684 ms") and the formula I used is (EPS*ETL*0,001). Is it correct?
Chiara
2016-09-28 12:52 GMT+02:00 Sjoerd Vos <[log in to unmask]<mailto:[log in to unmask]>>:
Hi Chiara,
ETL could be the guilty part here, but it depends a bit on your acquisition. I'm using topup on data from a GE scanner as well, and have no problems with it so it should work. The thing is, it's not specifically the ETL that's influencing the magnitude of distortions, because the ETL can be shortened by doing partial fourier acquisition which does not influence distortions. The best way I found to calculate the relevant ETL is by taking the phase resolution and divide by the parallel imaging factor along that axis, so for instance 128/2, and then multiply that by the echo spacing. All these things are in the dicom header.
HTH,
Sjoerd
|