[Neuroimaging] why 2 affine transforms in the nifti

[VRomain]

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
> 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> 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>)
>>
>> 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
>> https://mail.python.org/mailman/listinfo/neuroimaging
>
> _______________________________________________
> Neuroimaging mailing list
> 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/20210709/899bc4d6/attachment.html>