 |
 |
Hi Thomas, OK, this makes sense and I'm glad that you don't need the nitty-gritty of the exact calculation of the translations, as this is what would take me a while to look up and explain. If you just want to do regression then I recommend using the .par values as these are about a more sensible centre (the centre of gravity) and are more decoupled. The ones from avscale (using the centre of rotation as the corner of the image) includes much more rotation information, but it is not exactly linear. The extra stuff would be in the form of sin(theta) or cos(theta) products and so you wouldn't expect them to span *exactly* the same space. However, for most small motions the relevant trigonometric functions are well approximated by just the angles and you tend to get dominant rotations in certain directions, and so often the added part is very close to linear. So I would expect that if you used one set of regressors to explain the other set then they would do a very good job and leave only a small fraction "unexplained". I hope that helps explain both the FSL and regression part. All the best, Mark On 1 Dec 2011, at 03:05, Thomas Yeo wrote: > Hi Mark, > > Thanks. I understand the discrepancy now. > > This whole issue came about because I was trying to understand more > about the preprocessing we perform for functional connectivity, where > we regress out the motion parameters obtained from the .par and the > rmsrel files. > > From what you said, using the .par file (rather than the matrix > outputs) for regression is probably more appropriate since the .par > decouple (to some extent) the rotation and translation parameters. I > am rusty on this, but from the regression point of view, one would > think it shouldn't matter as long as the regressors span the same > space, although having independent regressors should increase the > numerical stability of the regression. That said, I did check and the > translation parameters in the mat files span a different space from > the translation in the .par files... > > I am not sure if this is asking too much about the nitty-gritty of how > FSL works or whether this is basic regression 101 knowledge I should > already know. If there's a reference (or references) that I might want > to look at, please let me know. I am also not sure if all these > questions are boring everyone on the FSL list, so we can also take > this off the FSL list if you think that would be appropriate. > > Again, thank you for taking the time to answer my questions. > > Cheers, > Thomas > > On Wed, Nov 30, 2011 at 3:29 PM, Mark Jenkinson <[log in to unmask]> wrote: >> Hi Thomas, >> >> You are really delving into the inner workings of FSL now. >> Is there a particular reason for this? >> We have tried to provide higher-level tools for people to >> conveniently work with rather than have to explain the >> more complicated (and not as consistent) inner workings. >> >> The reason that the translations are different is because >> the centre of rotation is chosen differently inside mcflirt >> compared to flirt, but the matrices that are output are >> in flirt conventions (where the centre of rotation is the >> 0,0,0 coordinate). >> >> A different centre of rotation is used to get the parameters >> because it tends to reduce the coupling between the >> rotation and the translation parameters. >> >> Is this helpful? >> Is this enough? >> Maybe explain why you want to know this, as there may >> be a much better way of achieving your goal with tools that >> we already provide, rather than explaining all the nitty-gritty >> of how the code works. >> >> All the best, >> Mark >> >> >> >> On 30 Nov 2011, at 07:11, Thomas Yeo wrote: >> >>> Hi Mark, >>> >>> thank you! However, I think I am still missing something. In my case, >>> the translation parameters in .par file does not seem to match that of >>> the output matrix. See output below: >>> >>>>> mcflirt -in input.nii.gz -out input_mc.nii.gz -mats -plots -refvol 0 -rmsrel -rmsabs -report >>>>> head -n 2 input_mc.nii.gz.par >>> 0 -0 0 0 0 0 >>> 0 -5.36371e-05 0 -2.51772e-05 0.0353457 -0.0244103 >>>>> avscale --allparams input_mc.nii.gz.mat/MAT_0001 >>> Rotation & Translation Matrix: >>> 1.000000 0.000000 0.000054 -0.003990 >>> 0.000000 1.000000 0.000000 0.035346 >>> -0.000054 0.000000 1.000000 -0.018570 >>> 0.000000 0.000000 0.000000 1.000000 >>> >>> Rotation Angles (x,y,z) [rads] = 0.000000 -0.000054 0.000000 >>> >>> Translations (x,y,z) [mm] = -0.003990 0.035346 -0.018570 >>> >>> Thanks, >>> Thomas >>> >>> >>> >>> >>> On Tue, Nov 29, 2011 at 5:23 PM, Mark Jenkinson <[log in to unmask]> wrote: >>>> Hi Thomas, >>>> >>>> The rotation matrix is formed as such: >>>> R = Rx.Ry.Rz >>>> and the translations are put in the 4th column. >>>> This matrix multiplies the input coordinates >>>> to form transformed coordinates in the reference >>>> space. >>>> >>>> Given the amount of confusion about "radiological" >>>> and "neurological" ordering, I'm not touching >>>> "clockwise" with a barge-pole. You can take any >>>> flirt or mcflirt matrix and get the equivalent >>>> decomposition into parameters using: >>>> avscale --allparams >>>> >>>> This way you can find yourself a "clockwise" >>>> one (according to your definitions of this term) >>>> and see what the angles are like! >>>> >>>> All the best, >>>> Mark >>>> >>>> >>>> On 29 Nov 2011, at 04:49, Thomas Yeo wrote: >>>> >>>>> Dear Mark (or other FSL experts), >>>>> >>>>> to clarify and expand on this question about in 2009 about the .par >>>>> output of mcflirt, can I confirm that >>>>> >>>>> 1) rot_x is applied first, followed by rot_y, followed by rot_z, >>>>> followed by the displacement (trans_x, trans_y, trans_z)? >>>>> >>>>> 2) And that the rot_x is rotation about x axis in the clockwise >>>>> direction, etc. as suggested by Satra? >>>>> >>>>> Thanks, >>>>> Thomas >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Not quite - they are the parameters you need to align with >>>>> the reference volume (the middle of the timeseries in FSL). >>>>> >>>>> All the best, >>>>> Mark >>>>> >>>>> >>>>> On 9 Feb 2009, at 01:09, Satrajit Ghosh wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks. So am I correct in assuming the following: >>>>>> >>>>>> rot_x, rot_y, rot_z, trans_x, trans_y, trans_z >>>>>> >>>>>> rotations in radians and clockwise >>>>>> translations in mm >>>>>> >>>>>> These are scan to scan changes rather than cumulative (like SPM). >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Satra >>>>>> >>>>>> >>>>>> On Sun, Feb 8, 2009 at 1:57 PM, Xinian Zuo <[log in to unmask]> >>>>>> wrote: >>>>>>> the first three columns are rot and last three are trans. >>>>>>> >>>>>> >>>>> Hi, >>>>> >>>>> Is there a specification somewhere for the motion parameter estimates >>>>> (par file) of mcflirt? I'm looking for information such as which >>>>> fields are rotation, translation, what are the dimensions, is it scan >>>>> to scan motion or cumulative, etc. >>>>> >>>>> Thanks, >>>>> >>>>> Satra >>>>> >>> >