Hi Greg,

Try fslcpgeom with your 1x1x1 image as the source and your
current 3.5x3.5x3.5 "foo" image (as created by fslcreatehd) as 
the destination.  This should give it valid qform/sform settings
without changing the dimensions.  I think that everything from
then on should work fine.

All the best,
	Mark




On 30 Dec 2011, at 16:52, Gregory Kirk wrote:

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