There are a couple of differences between qform and sform that
are worth pointing out.

1 - qform is only rigid body with 6 degrees of freedom, whereas
     sform is a general affine transform with 12 degrees of freedom

2 - it is intended that qform represents the kind of orientation
        information encoded by the scanner, like what is commonly
        found in dicom files.  This relates the images data axes to
        scanner coordinate axes, but is not meant to represent a
        general conversion to standard coordinates.  Consequently
        qform only allows for rotation and translation (and reflection)
        and is meant to encode information like the slice orientation
        (sagittal, axial, etc) and the obliqueness.  However, since
        nifti files are in their infancy right now we didn't think
        people would have this information encoded soon, and so it
        became one of the things on the B-list of features to implement
        and so won't be available until the next release.

I will add an appropriate caveat to "FSLView always shows images
in radiological convention." as it seems to cause some confusion.
I also agree with Graham that radiological/neurological should be
about the viewing, not the data storage, but unfortunately it is
being applied to both - us included - to denote files where the
first bytes come from the right/left side respectively.
The desired behaviour is that a correctly formed file could be
stored either way around, and would display exactly the same.

All the best,

On 21 Oct 2004, at 17:02, Lazar Fleysher wrote:

> Dear Mark,
> Yes I understood the situation with the support of NIFTI qform.
> I guess, since sform is supported, I do not understand the difference
> between the two in terms of support. Frankly, I do not understand the
> difference between sform and qform either and why NIFTI supplies these
> two
> methods as they are identical to me
> (x,y,z) = Matrix * (i,j,k) + offset.
> Once again, thank you for your clarifications.
> Lazar
> On Thu, 21 Oct 2004, Mark Jenkinson wrote:
>> Dear Lazar,
>> The current FSL release is a beta release and we have
>> not yet taken advantage of the full set of possibilities that
>> the nifti file format creates.  Part of this is that we do not
>> use qforms in any of our processing at present.  We do
>> use sforms for calculating standard space coordinates,
>> as is implemented in the current version of fslview.
>> Therefore, at present all fsl routines work in ijk coordinates
>> in the same way that they always have before.  As Dave says,
>> the next version of fsl will be likely to support qforms.
>> I hope this is clear.
>> All the best,
>>     Mark
>> Lazar Fleysher wrote:
>>> Dear David,
>>> As far as I understand, qform is the prefered way to express
>>> orientation
>>> (Method 2 in nifti1.h).
>>> The question is if all FSL routines do not support qform or only
>>> fslview
>>> does not use it? Or all other FSL routines work in ijk coordinates
>>> so they
>>> do not care about the orientation, it will be the same through out
>>> the
>>> session?
>>> Thanks for your clarifications.
>>> Lazar
>>> On Thu, 21 Oct 2004, David Flitney wrote:
>>>> Okay. Your image has the transform expressed in the NIFTI qform
>>>> field,
>>>> the section related to scanner coordinates, and at present fslview
>>>> does
>>>> not know how/when to use this information. In this case fslview
>>>> behaves
>>>> identically to the older version. We intend to sort this out soon
>>>> and
>>>> the next version is likely to include proper support for use of this
>>>> transform.
>>>> --
>>>> Regards,
>>>> Dave
>>>> Dave Flitney, Computer Manager
>>>> Oxford Centre for Functional MRI of the Brain
>>>> E:[log in to unmask] W:+44-1865-222713 F:+44-1865-222717
>>>> URL: