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 <-
|
