Hi,
Yep, it is the same rmsdiff.
The refvol determines the centre of the FOV (in mm) so you can use
any image from the functional time series as they all have the same FOV.
Cheers,
Mark
On Friday, August 15, 2003, at 07:55 pm, Zrinka Bilusic wrote:
> Thanks, that clarifies things...
>
> one more question - about rmsdif. Is rmsdiff the same algorithm that is
> behind rms values reported by mcflirt? In other words, if I have a
> series of MAT* files from a mcflirt run, and if I execute:
> rmsdiff MAT_0000 MAT_0001 vol0000
> that should give me the "estimated mean displacement" between vol0001
> and vol0000 (where vol0000 and vol0001 anre 0th and 1st volume in a
> functional run)? And that number should be the same as the first value
> in rel rms, as reported by mcflirt for the same functional series?
>
> For rmsdiff: Usage: rmsdiff matrixfile1 matrixfile2 refvol, I am
> assuming that refvol is the volume corresponding to transformation
> matrix in matrixfile1?
>
>
> thanks
> zrinka
> On Friday, August 15, 2003, at 02:35 AM, Mark Jenkinson wrote:
>
>> Hi Zrinka,
>>
>> There are two ways of dealing with transformations in mcflirt.
>> One is dealing with the matrix files (the *.mat ascii files produced
>> by
>> flirt
>> and mcflirt) and the other is dealing with mcflirt parameters in the
>> *.par file.
>> If you are dealing only with the matrix files, as generated with the
>> -mats
>> flag to mcflirt then the (0,0,0) mm coordinate is in the corner of the
>> (0,0,0)
>> voxel, exactly the same as for flirt and does not depend on the centre
>> of
>> mass. I would definitely recommend working with these matrices when
>> comparing methods as there is much less arbitrariness in how they are
>> constructed.
>>
>> However, for the parameters - yes - the translations are with respect
>> to
>> the centre of mass. Hence this is much more awkward to deal with and
>> use. The problem arises because the decomposition of the affine
>> matrix
>> into parameters is arbitrary. There are lots of perfectly acceptable
>> choices
>> and we have picked one that works well internally, as it is close to
>> decoupling
>> rotations from translations. It is also a little more intuitive to
>> look at the plots
>> when they are nearly decoupled. However, to convert between the
>> matrix transform and these parameters is much more difficult since you
>> need
>> to know the centre of mass, which we don't save anywhere.
>>
>> So can I suggest that you forget about the output of -plots and just
>> use the
>> -mats output, then the matrix is simple, the origin is always in the
>> corner
>> (the 0,0,0 voxel), as the "mm coordinate = voxel size * voxel
>> coordinate"
>> and the "new mm coordinate = matrix * old mm coordinate" for the
>> transformation.
>>
>> All the best,
>> Mark
>>
>>
>>
>> On Thursday, August 14, 2003, at 10:53 pm, Zrinka Bilusic wrote:
>>
>>> Hello,
>>> I am back to comparing transformation matrices from mcflirt and air
>>> and I have a question...
>>> oh, well...
>>>
>>> from some previous postings, I understand that fsl uses different
>>> coordinate system for
>>> "voxel" and for "mm". voxels are described with respect to image
>>> storage and the origin, or
>>> (0,0,0) voxel is the first (corner) voxel in the dataset. The mm
>>> coordinates are voxel
>>> coordinates multiplied by voxel dimensions. Also, transformation
>>> matrices are always given
>>> with respect to mm coordinates. But, the origin of mm coordinates (at
>>> least with regards to
>>> transformation matrices output by mcflirt) is not set to (0,0,0)
>>> voxel, but to the "center of
>>> mass" of the image.
>>>
>>> So, in other words, if I wanted to find a position of a voxel after
>>> transformation I would have
>>> to do the following:
>>> 1. transform old voxel coordinates into mm coordinates:
>>> old_mm=T*old_vox;
>>> 2. transform old mm coordinates into new mm coordinates:
>>> new_mm=XFM*old_mm
>>>
>>> where XFM is the transformation matrix from the .mat file. But what
>>> is T? Is it possible to find
>>> out what is the center of mass that mcflirt uses for each
>>> transformation?
>>>
>>> I believe that is the piece that I am missing in order to compare air
>>> and fsl transformations,
>>> because it seems that the only difference in the matrices is that air
>>> transformation matrices
>>> are always with respect to the first voxel in the dataset.
>>>
>>> Thanks!
>>> zrinka
>>
>>
> Zrinka Bilusic-Vezmar
> UCLA Brain Mapping
> 660 Charles Young Drive South
> Los Angeles, CA 90095
>
> 310-794-5060
> [log in to unmask]
> www.brainmapping.org
|