Hi Jon,
Unfortunately, nothing has really been strictly standardised in the
case that neither sform nor qform are set. There is a default sform
matrix - but its use is not prescribed and the meaning of the derived
mm coordinates is still explicitly left up to the application. The most
authoritative text on this is the original source document - nifti1.h -
which can be found in $FSLDIR/src/niftiio/
The relevant extracts are:
> ...
>
> The (x,y,z) coordinates refer to the CENTER of a voxel. In methods
> 2 and 3, the (x,y,z) axes refer to a subject-based coordinate
> system,
> with
> +x = Right +y = Anterior +z = Superior.
>
> ...
>
> METHOD 1 (the "old" way, used only when qform_code = 0):
> -------------------------------------------------------
> The coordinate mapping from (i,j,k) to (x,y,z) is the ANALYZE
> 7.5 way. This is a simple scaling relationship:
>
> x = pixdim[1] * i
> y = pixdim[2] * j
> z = pixdim[3] * k
>
> No particular spatial orientation is attached to these (x,y,z)
> coordinates. (NIFTI-1 does not have the ANALYZE 7.5 orient field,
> which is not general and is often not set properly.) This method
> is not recommended, and is present mainly for compatibility with
> ANALYZE 7.5 files.
>
> ...
Note that it is METHOD 1 which applies in your case, and that the
definition
of what +x, +y and +z mean in terms of anatomy are *not* specified
for this
case. Therefore it is up to each package to decide what to do. We
do something
consistent with how we used to treat Analyze files, which is to
assume that
they were ordered in the same way as the standard space templates, which
were always in RAS with respect to their mm coordinates, and LAS with
respect
to their voxel coordinates. By this | mean that going in the +x
direction would
be going towards the Right for the mm coordinates (the right side is
the most
positive x mm coordinate) while it is going towards the Left for the
voxel coordinates
(the left side has the greatest positive x voxel coordinate). We
felt that this
compatibility with the old Analyze files and the way that FSL used to
work (assuming
that all files within a pipeline were consistently ordered) was the
best thing to do.
I guess the worst part is that the nifti code which we use in the
library tends to
report these defaults for the sform when we don't use them. I like
using the fslhd -x
option as then you don't see the sform or qform if they do not
contain usable
information. Hopefully people will soon eradicate all files without
orientation information
from the world at large, but until then, this is how things are.
Hope this usefully clarifies things.
All the best,
Mark
On 30 Nov 2007, at 10:30, Jon Clayden wrote:
> Hi Mark, and thanks for the clarification.
>
> My impression from the Nifti specification was that when the
> qform_code and sform_code are both zero, the file is treated as if
> it had an sform matrix of
>
> ( pixdim[1] 0 0 )
> ( 0 pixdim[2] 0 )
> ( 0 0 pixdim[3] )
>
> which would mean that the data ordering corresponds to the Nifti
> default of RAS. Is this in fact not the case then, and instead the
> default orientation reverts to LAS in these circumstances for
> backwards compatibility?
>
> Jon
>
>
> On 29 Nov 2007, at 23:34, Mark Jenkinson wrote:
>
>> Hi,
>>
>> This stuff is all quite confusing I'm afraid, but I think I know
>> what is going on.
>> If you look at the full output of fslhd, you should see that the
>> qform_name is
>> Unknown and the qform_code is 0 (the former is a worded
>> description of the
>> latter). This indicates that this nifti file *does not contain*
>> orientation information
>> (assuming your sform_name is Unknown as well). Hence the fslhd
>> program
>> guesses the x_orient based on a default qform, which isn't useful
>> I'm afraid.
>> The alternative output with fslhd -x only shows you the sform and
>> qform when
>> they contain useful information - so maybe you'll find that better.
>>
>> In general it is dangerous to use nifti files without any
>> orientation information or
>> to use Analyze (as it has no intrinsic, standard orientation
>> information in it).
>> Internally to most fsl tools, such orientation-less files will be
>> treated as radiological
>> where it matters (e.g. in flirt) and things should work fine.
>> However, to be safer
>> it is best to encode the information in nifti file if you are sure
>> which way around the
>> axes are. You can change the nifti information with fslorient.
>> Note that you need
>> to set either the sform or qform code to a non-zero value first,
>> as otherwise it will
>> ignore all attempts to include orientation information. You can
>> check if you have
>> things correct by using FSLView which will label your axes based
>> on this info.
>>
>> I hope this helps make things clearer.
>> All the best,
>> Mark
>>
>>
>>
>> On 29 Nov 2007, at 21:05, Jon Clayden wrote:
>>
>>> Dear all,
>>>
>>> I'm confused about FSL's conventions for dealing with Analyze
>>> files. It says on the FSL site at <http://www.fmrib.ox.ac.uk/fsl/
>>> fsl/formats.html> that Analyze files are treated as being in
>>> radiological convention, i.e. LAS. However, if I convert an
>>> Analyze file to Nifti using fslchfiletype I get a header
>>> indicating that the file is *RAS*, as shown below. Moreover, the
>>> image data is unchanged, rather than being flipped left-to-right
>>> as seems to be the case with the header.
>>>
>>> Can anyone shed any light on why this is?
>>>
>>> Cheers,
>>> Jon
>>>
>>>
>>> $ ls basic*
>>> basic.hdr.gz basic.img.gz
>>> $ fslhd basic | grep -a file_type
>>> file_type ANALYZE-7.5
>>> $ cp basic.hdr.gz basic2.hdr.gz
>>> $ cp basic.img.gz basic2.img.gz
>>> $ ls basic*
>>> basic.hdr.gz basic.img.gz basic2.hdr.gz basic2.img.gz
>>> $ fslchfiletype NIFTI_PAIR_GZ basic2
>>> $ fslhd basic2 | grep xorient
>>> qform_xorient Left-to-Right
>>> sform_xorient Unknown
>>> $ diff basic.img.gz basic2.img.gz
>>> $
|