 |
 |
Hi, No, this isn't a bug it is the new behaviour of FSL 3.2b which tries to treat analyze as similarly as the new nifti format. As a consequence we changed how the left/right handedness is specified - it is always right-handed for Analyze - see the FAQ for more info on this at: http://www.fmrib.ox.ac.uk/fslfaq/#general_lr As part of this, Analyze images are now always written out by FSL3.2b with a negative sign in the x dimension (pixdim1). This is normal and is used to indicate that these Analyze images should be considered to be the same ordering as the avg152T1 images which also have this convention (and always have had it). Note that Analyze images with a positive pixdim1 are treated by FSL as if the pixdim1 were negative when they are read in, so you cannot have a left-handed Analyze volume in FSL3.2b. The origin being non-zero is a consequence of the input image to flirt having standard space coordinate information (which in Analyze means a non-zero origin, and in NIFTI is specified by a valid sform matrix). So when your EPI is in standard space, it gets a non-zero origin, and when flirt transforms this image it tries to keep the coordinate information intact by transforming the non-zero origin. If you load the image into FSLView you will see that the mm coordinates will correspond to the same anatomical locations. Therefore the new EPI (resampled back from standard space) still carries with it standard space coordinate information. This is what we decided was the appropriate behaviour for flirt in this situation, as the nifti sform should also follow images around once their standard space coordinate mappings are known. I hope this answers your questions and that there are no problems caused by this behaviour. We realise that it is a change from previous behaviour, but we feel that it is an improvement and also helps to make the transition to the nifti format easier, which is what we expect almost all images to use in the short- to medium-term future. All the best, Mark On 18 Oct 2005, at 21:07, Xun Liu wrote: > I think I found a bug in flirt (FSL 3.2b). When I tried to transform an > image back from the standard space into the EPI space, the header > created > had the wrong information (the origin is not the same as the EPI's and > the > x axis is negative). I use ANALYZE as output file type. > > The command I ran is: > > /usr/local/fsl/bin/flirt -in c1-in-standard.hdr -applyxfm -init > standard2example_func.mat -out c1-in-example_func.hdr -paddingsize 0.0 > - > interp trilinear -ref example_func.hdr > > avwinfo standard > > dim2 109 > dim1 91 > dim2 109 > dim3 91 > dim4 1 > datatype 2 > pixdim1 -2.0000000000 > pixdim2 2.0000000000 > pixdim3 2.0000000000 > pixdim4 0.0000000000 > cal_max 0.0000 > cal_min 0.0000 > glmax 255 > glmin 0 > origin1 46 > origin2 64 > origin3 37 > file_type ANALYZE-7.5 > > avwinfo c1-in-example_func > > dim1 64 > dim2 64 > dim3 34 > dim4 1 > datatype 16 > pixdim1 -3.5000000000 <- > pixdim2 3.5000000000 > pixdim3 3.5000000000 > pixdim4 1.0000000000 > cal_max 1.0000 > cal_min 0.0000 > glmax 0 > glmin 0 > origin1 33 <- > origin2 34 <- > origin3 15 <- > file_type ANALYZE-7.5 > > avwinfo example_func > > dim1 64 > dim2 64 > dim3 34 > dim4 1 > datatype 4 > pixdim1 3.5000000000 <- > pixdim2 3.5000000000 > pixdim3 3.5000000000 > pixdim4 0.0000000000 > cal_max 0.0000 > cal_min 0.0000 > glmax 0 > glmin 0 > origin1 0 <- > origin2 0 <- > origin3 0 <- > file_type ANALYZE-7.5 > > When I tested this with FSL 3.1, it came out correctly. > > avwinfo c1-in-example_func > > dim1 64 > dim2 64 > dim3 34 > dim4 1 > datatype 16 > pixdim1 3.5000000000 <- > pixdim2 3.5000000000 > pixdim3 3.5000000000 > pixdim4 1.0000000000 > cal_max 1.0000 > cal_min 0.0000 > glmax 1 > glmin 0 > origin1 0 <- > origin2 0 <- > origin3 0 <-