 |
 |
Mark, Thanks for a very clear explanation. I have a couple of question on the correct method to convert DICOM data to NIFTI. a) I am currently converting the dicom orientation and patient position to the s-matrix and leaving qform code to zero. I was thinking that currently FSL does not use q-form information so I should store it in S-matrix. IS this correct or accceptable according to NIFTI concept. b) In order to minimize confusion with FSL what is the best way to convert a Sagital image to NIFTI format. I was thinking of converting it to radiological coordinates and storing the appropriate s_matrix - so that fslview would show (x,y,z) in nIFTI notation but the data would be stored in radiological coordinates. Maybe I should not worry about this at all and store the data in the order the scanner presents it and simply store the correct s-matrix or the q-quaterns. I am glad that you all have created the NIFTI standard. Thanks, Arvind On Sat, 4 Dec 2004 10:23:37 +0000 Mark Jenkinson <[log in to unmask]> wrote: > Dear Arvind, > > This is a slightly tricky situation but things are >working > as expected. > >Firstly, I want to emphasize that the sform matrix is >about > how to map voxel coordinates to *standard space >coordinates* > and therefore does not have to use the same spacing as >the > voxel sizes at all. The reason for this is if you have >a > scan of an individual with, for example, a small head, >then > their image will need to be scaled up to fit the >standard > brain. Hence they will have a voxel dimension which >tells > you about how big their brain was, and a value in the >sform > which tells you about how big the voxel spacing needs to >be > *after* scaling up to the standard brain. It is >necessary > to have both sets of information and to keep them >separate. > So in your case it is fine that the sform in the flirt >output > does not have a 1.5mm spacing in z. > > Secondly, flirt uses the reference volume to assign the > number of voxels and the voxel size in the output image. > It also copies the sform from the reference volume if it > is set. However, if it is not set, but the sform of the > input image is set, then it will *transform* the sform >of > the input image so that it is appropriate for the output > image. This is a more unusual situation, as normally >the > input image doesn't have an sform set, but the reference > one does (e.g. if it is the standard image). But we try > to preserve the sform information when we can, and so >you > are in the situation where the input sform is used, but > requires transformation. > > This transformation can be explained as follows: > Let the sform matrix of the input volume be Si. > Let the sform matrix of the output volume be So. > Let the transformation between the input and output be >M. > It is necessary that the following equation hold for > consistency: > Si = So * M > This is because Si maps input coord to standard coord >while > M maps input coord to output coord and So maps output >coord > to standard coord. > > Therefore if you specify Si in the input image, and M >with an > applyxfm, you must solve for So, which gives: > So = Si * M^(-1) > As a consequence, in your case, you end up multiplying >the > z component of the sform matrix by 2, as this is the 3,3 >entry > in M^(-1). > > Again, just to reiterate, this only occurs if the sform >matrix > of the reference volume is not set. If the reference >sform is > set, then the output image just gets a copy of the >reference > sform matrix, since this is what you want if you are >transforming > to a standard space image with a well defined standard >coord system. > > I hope this makes this clear. > > All the best, > Mark > > > > On 4 Dec 2004, at 01:32, Arvind caprihan wrote: > >> Hi, >> I am trying to understand the role of reference volume >>and the >> transformation matrix in 'flirt', and I am confused. >> >> The input file is head_t1 (256x256x150) from the test >>data suite. It >> has a >> sto_xyx matrix of >> >> sto_xyz:1 -0.976562 0.000000 0.000000 122.070251 >> sto_xyz:2 0.000000 0.976562 0.000000 -116.210884 >> sto_xyz:3 0.000000 0.000000 1.000000 -71.000000 >> sto_xyz:4 0.000000 0.000000 0.000000 1.000000 >> >> I have made a zero2.nii file with avwcreatehd with >>dimension >> 128x128x75 >> and the corresponding pixel size 1.95x1.95x1.5. >> >> The transformation matrix rs2.mat is >> 1.0 0.0 0.0 0.0 >> 0.0 1.0 0.0 0.0 >> 0.0 0.0 0.5 0.0 >> 0 0 0 1 >> >> The R(3,3) = 0.5 >> >> I then apply: >> flirt -in head_t1 -ref zero2 -out utest2 -applyxfm -init >>rs2.mat >> >> The output has the dimensions of the ref-volume zero2. >> This is >> correct. >> The pixdim(z) is 1.5 - which corresponds to ref-volume. >> The sto_xyz >> matrix >> is: >> >> sto_xyz:1 -1.950000 0.000000 0.000000 122.070251 >> sto_xyz:2 0.000000 1.950000 0.000000 -116.210884 >> sto_xyz:3 0.000000 0.000000 3.000000 -71.000000 >> sto_xyz:4 0.000000 0.000000 0.000000 1.000000 >> >> Now although the pixeldim(z) is 1.5, the sto_xyz >>indicates it is 3.0. >> If >> you look at the image in fslview, the z-values changes >>by 3 mm for a >> unit >> change in k-index. >> I am thinking that the pixdim(z) should be 3 mm - then >>everything >> would be >> consistent. >> >> Thanks, >> >> Arvind >> New Mexico Resonance