Dear Gregory,
It is the full contents of the qform and sform matrices that are checked
by fslmerge when looking for inconsistencies. So it isn't enough just to
look at the xorient, yorient and zorient fields. You need to look at the
numbers in the matrices themselves.
It sounds like you've checked on the left-right issues and that these
are fine. So that is good. However, this warning would also be output
if the origins encoded in the qform/sform matrices are different (or if
the axes are angled differently). Depending on what exact processes
you've run the images through this may have correctly occurred. In
the application of motion correction, if each volume starts with the
same qform/sform and then is spatially transformed, it is more than
likely that these would change, reflecting the new coordinate system.
If that is the case then this is fine and you can just ignore the warning.
I'm not sure if you use images output from FreeSurfer or any other
manipulations of them with FSL tools or otherwise, but if you look at
them carefully with fslview and fslhd then you should be able to work
out whether the changes are a problem or simply due to an expected
and correct modification of the qform/sform that reflects spatial
transformations.
One thing that you have said that I want to pick up on is the issue
of white/pink writing for the labels in FSLView. It is *NOT* the case that
these colours reflect whether it is "radiologically" or "neurologically"
stored. It reflects whether there are valid or "unknown" qform/sform
matrices. On some platforms the labels disappear when both qform
and sform are "unknown", while on other platforms the labels change
colour (to gray or red/pink). When both qform and sform are "unknown"
(based on the qform_name and sform_name field from fslhd) then
FSL reverts to its defaults to determine left-right orientation (assuming
that the image is stored in "radiological" ordering). As this is dangerous
(since we have no way of knowing if the defaults are correct) the labels
in FSLView are changed to reflect this lack of certainty.
It is certainly not a good thing to work with images where both qform
and sform are "unknown". I suspect that your image "foo" below has
this and I would recommend fixing that, either by generating it in a
different way (say fslroi) or by copying information from another
image (e.g. fslcpgeom). Inspect the results with fslhd and fslview to
make sure that it is doing what you want. This may, or may not, have
an impact on the warning above, but I would recommend doing it
anyway.
Hope this helps to clarify the situation for you.
All the best,
Mark
On 29 Dec 2011, at 19:39, Gregory Kirk wrote:
> hi fsl'ers,
>
> when doing a fslmerge -t foo *
>
> i get
>
> WARNING:: Inconsistent orientations for individual images when attempting to merge.
> Merge will use voxel-based orientation which is probably incorrect - *PLEASE CHECK*!
>
> the situation is.
>
> a have a set of 230 volumes that were created from an epi 4d data set
> that was split with fslsplit
>
> i am doing a motion correction experiment applying bbregister to each epi timepoint.
>
> so i apply the transform from bbregister to each time point using flirt with
> flirt -in $epi_volume_path/vol${i}.nii.gz -applyxfm -init $transforms_path/tran.${i}.mtx -out $out_path/reg_${i}.nii.gz -paddingsize 0.0 -interp trilinear -ref /study/aa-scratch/TEENEMO/rest/challenge_freesurfer/surface_analysis/run_all6/foo.nii.gz
>
> with foo.nii.gz a volume i create with
> fslcreatehd <xsize> <ysize> <zsize> <tsize> <xvoxsize> <yvoxsize> <zvoxsize> <tr> <xorigin> <yorigin> <zorigin> <datatype> <headername>
>
> i get multiple of these warnings
>
> i isolate 2 volumes that get the error
> i.e. fslmerge -t foo vol10.nii.gz vol17.nii.gz gives the error and look at the headers, they both say
> RADIOLOGICAL and all the orientation info
> qform_xorient Anterior-to-Posterior
> qform_yorient Superior-to-Inferior
> qform_zorient Left-to-Right
>
> and
> sform_xorient Anterior-to-Posterior
> sform_yorient Superior-to-Inferior
> sform_zorient Left-to-Right
>
> are exactly the same.
>
> also i make marks in the right hemi of the input images of both and verify there is not
> a left right flip.
>
> looking at the transforms applied to both images they have the same sign
> and only tiny differences in the values as expected.
>
> i noticed that the two volumes show up with the L R labels white in one
> and pink in the other, usually that means one is radiological the other
> is neurological, but as i say fslorient gives RADIOLOGICAL for both.
>
> the original voles before applying the transform also have this pink/white difference in the labels.
>
> i noticed that the volume i created with fslcreatehd does not has
> sform_xorient Unknown
> sform_yorient Unknown
> sform_zorient Unknown
>
> when i run fslmerge -t foo vol10.nii.gz vol17.nii.gz
> on the original images produced by fslsplit it does not give an error.
>
> somehow the .nii created by flirt has something that throws a flag
>
> also i checked not only that there is no L?R flip but that the AP IS is correct and the direction
> of increasing coordinates for x,y,z is the same. the merged results seem to be correct as far as i can see
> but of course i would like to know for sure there is nothing wrong before analyze the data.
|