[Neuroimaging] why 2 affine transforms in the nifti

Mon Jul 12 11:05:11 EDT 2021

Hi Romain,

As Demian mentions, having the 2 transforms allows one to have a dataset in both original space and standard space, for example.  The main package to use this is SPM, I believe, which might repeatedly modify the sform to get the volume into standard space without altering the data, thus without repeatedly interpolating and therefore blurring the data.  There was also an advantage of not having to even store the transformed result unless needed, possibly saving disk space.  I don't know that anyone takes advantage of that anymore.

Also, note that the qform and sform are not quite interchangeable.  The qform transformation is not a general affine, while the sform is.

At this point most people are using non-linear registration, which cannot be done through a simple affine, and so the qform/sform distinction might no longer be needed.

Most packages write out transformations separately so that they can be concatenated without repeated resampling/blurring of the volumetric data.  In AFNI, the sform and qform are just ijk to xyz transformations to put the data on a regular grid.  As mentioned, registration transformations are generally kept separate to be concatenated and applied.  So the sform and qform are always identical after a typical operation, as you mention.

If the qform and sform are different after the SPM registration, perhaps that registration transformation was not applied, in which case you might want to extract it into a text file.  Note that since it is presumably ijk-to-xyz, the sform cannot simply be applied on top of the qform.  It might be good to verify with the SPM folks how to properly extract the registration transformation, such as by multiplying the sform by the inverse of the qform.  The order would be important.

- rick

________________________________
From: VRomain <romain.valabregue at upmc.fr>
Sent: Friday, July 9, 2021 7:06 AM
To: neuroimaging at python.org <neuroimaging at python.org>
Subject: Re: [Neuroimaging] why 2 affine transforms in the nifti

Yes thanks for the reference, that is indeed the right place to start,

so ok it is recommended to use qform for the "subject space", and the sform for "standard space" but note that this is set by the [sq]form_code  and nothing prevent you to do the opposite of the recommendation with sform_code=1 and qform_code=2 for instance.

the doc, say you may need the both depending on the use case, but no way to know which one to use if both [sq]form_code are >0 (ok it is depending on the use case ...)

Just as an example of inconsistency, when you convert from dicom to nifti, you usually get both sform and qform set, with [sq]form_code to 1. but if you write an image with sitk, only the qform is set.

Many coregistration tools (fsl, freesurfer, ants, niftireg) make the choice to do not change the nifti header and to write the coregistration affine in a separate file, so for them, I do not see a need of 2 affines ... (this is the best choice to avoid any confusion, and then you can have as many registration to as many template you wish !)

Only spm (as far as I know), decide to change the nifti header after a coregistration. It has the advantage, that they then do not need to compose affine and non-linear registration (you can directly apply the non-linear field, because thanks to the header change, the affine registration is already applied) ... but even for that there is no need of 2 transform: (they could also change the affine, if there was only one in the header !)

is there any tools or use case, that need this 2 transforms ?

May be I am concern because I made the wrong choice to use spm coregister at the first place (old habit take time to change ...). When I mixt with other tools for other task, I may end up having problems ...

if you stay with other coregistration tool, you just do not care and stay with 2 identical affine stored in the header ...

Le 09/07/2021 à 11:13, Demian Wassermann a écrit :

Dear Romain,

I think that you refer to the qform and sform transforms. If I’m not wrong the main idea of storing these two transforms is that qform transforms between voxel space and subject space in mm, and that sform transforms between voxel space and a “standard space” such as ACPC, or talairach (see https://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields/nifti1fields_pages/qsform.html ) so you’d encode the output of a linear registration towards such standard space. Then there is of course the issue of poor documentation and then the way the data is used despite the standard’s intent

Best
Demian
--
Demian Wassermann, PhD, HdR
demian.wassermann at inria.fr<mailto:demian.wassermann at inria.fr>
Associate Research Professor (CRCN)
Parietal Team
INRIA Saclay Ile-de-France
1 Rue Honoré d'Estienne d'Orves, 91120 Palaiseau

On 9 Jul 2021, at 10:51, VRomain <romain.valabregue at upmc.fr><mailto:romain.valabregue at upmc.fr> wrote:

Hello

As suggest by oscar I open a new thread, since there may be nothing to do with Nibabel CZI grant

So to resume, I sometimes get  troubles when playing with different software, because of the 2 affines stored in the nifti file.

(some software thing one should only read / write the sform, other the qform, so it is easy to get to inconsistency, that will just scratch your results)

Thanks @ oscar to point out the nitransforms repo - https://github.com/poldracklab/nitransforms <https://github.com/poldracklab/nitransforms><https://github.com/poldracklab/nitransforms>)

I'll have a closer look, this is indeed an important objectiv

I am curious, to know why it was a clever idea to store 2 affine ? ( I probably miss the point ... )

>From what I understand, it was meant to get an history of the registration made on the data. The only software I know that use it, is spm coregister function. they update the sform and keep the qform. Ok we can come back, but if for any reason one have to coregister a second time, then the information is lost (because they chose to update the sform, and the qform take the old sform value ...)

_______________________________________________
Neuroimaging mailing list
Neuroimaging at python.org<mailto:Neuroimaging at python.org>
https://mail.python.org/mailman/listinfo/neuroimaging

_______________________________________________
Neuroimaging mailing list
Neuroimaging at python.org<mailto:Neuroimaging at python.org>
https://mail.python.org/mailman/listinfo/neuroimaging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/neuroimaging/attachments/20210712/2b75ce01/attachment.html>