Hi Mark,
i had a sneaking suspician that foo was the culprit, i don't know how to calculate
this with qfrom & sform defined. The problem is i do not have an image with
the needed geometry to use to define -ref for applying the transform with flirt
or i would not be generating foo with fslcreatehd in the first place.
the freesurfer conformed space has a different orientation w.r.t. the axis than the native epi so
the dimensions needed for it to fit are different than the original epi. i.e. the orig is 39X63X63 and i make an image
foo with 63X63X63 with the origin specified as 0 for all so there is room for it to flip it on the side to fit , i.e. if i use
the original geometry the resulting image is croped because the 39 dimension needs to become 63 so it fits.
the only processing that is done is to split the original 4d with fslsplit( as i said the pink/white label difference is there
imediately after fslsplit but merge does not complain at this point if i immediately apply it) the only thing that happens
after that is applying the matrix output from bbregister to each volume with foo yes having unknown for both sform & qform,
then after that it complains on some but not all of the images.
i dont know how to create a volume with the target orientation having defined qform & sform, i have the .nii
in the correct orientation with the structural T1, but the dim is 1X1X1 and the epi needs to be 3.5X3.5X3.5.
if i could take that, maybe i could use fsledit and change the dims to 3.5 maybe that will work.
i will try that now, changing the dim should not effect any of the orientation info ?
thank you for the detailed reply
greg
On 12/30/11, 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.
|