Dear Alle,

Ged is correct that it is perfectly valid to have different a sform and 
qform
in the same file.  In fact, the point of having them both is so that 
they can
be different.  However, it is common that existing software does not fully
support all the various possibilities yet.  What particular piece of 
software
are you having trouble with?

As for the qform - Ged is not quite right.  The qform can only store a 6 DOF
transformation (via the quaternion to represent rotation and the 
translation part).
It is true that it scales the voxels, using the pixdim values, prior to 
applying
the 6 DOF transformation, but you cannot independently modify the scaling
without changing the pixdims, and so I would not consider this to store a
general 9 DOF transformation, since you can't keep the pixdims the same and
then add extra scaling of your choice via the qform.  If you think of it 
as a mapping
purely in world coordinates (ones in mm, not voxels) then it is more 
straightforward
to see that it is only 6 DOF, as it does *no* scaling in this space.

Finally, as Ged says, you can use avworient to copy qforms and sforms to and
fro, if that's what would be the best solution for you (and we've found 
it to be
a convenient solution for us to provide maximal compatibility at present).

All the best,
    Mark

Ged Ridgway wrote:

> Alle Meije Wink wrote:
>
>> Ah I think that's what the problem is. My program only checks (and only
>> reads and writes) the S-form. It's probably something to do with
>> avwmaths setting Q-form to be consistent with S-form, but then my
>> program applying new changes only to S-form so that the two are
>> inconsistent.
>
>
> Hi Alle,
>
> The problem must be something else, because it is entirely legitimate 
> to change the sform independently of the qform, and there may not 
> really be a notion of "consistency" between them.
>
> The qform allows a 9 DoF transformation (3 voxel-dimensions plus 3D 
> rotation and translation), which can for example provide the 
> DICOM-stored scanner/world coordinates (e.g. in mm from magnet 
> isocentre) for each voxel.
>
> The sform allows a 12 DoF transformation (full affine, i.e. allowing 
> skewed non-orthogonal axes), which is typically used to provide the 
> "standard space" world coordinates (e.g. mm in MNI space) for each voxel.
>
> So the two need not both be present, and if they are, they can 
> represent entirely different mappings. Presence or absence of the 
> qform (or difference from the sform) should not cause an error with a 
> NIfTI-compliant program.
>
>> Would there be an easy way to, if all images that I have are axial,
>> convert an S-form into a Q-form, to fill them in consistemtly? A
>> StoQform() operation, if you like.
>
>
> It shouldn't be necessary to copy an sform to a qform, since it should 
> be acceptable to not have a qform at all. I think you could do this, 
> if you really wanted to, using avworient.
>
> However, note that because the qform can only handle a 9 DoF 
> transformation while the sform can handle 12, it is not possible to 
> correctly map sform to qform *in the general case*. (though at 
> present, FSL/FLIRT uses separate text files for affine 
> transformations, so the sform more often than not ends up being a 
> simple 6 DoF voxdims+origin mapping).
>
> Hope this helps,
> Ged.