On my Linux platform, the labels are white when FSLview is the active
window, and change to pink when the focus is moved to a different
window. So, as Mark noted, be careful about inferring any particular
meaning to the color of the labels.
cheers,
-MH
On Fri, 2011-12-30 at 14:24 +0000, Mark Jenkinson wrote:
> 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.
|