<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hello</p>
<p><br>
</p>
<p>thanks for sharing, <br>
</p>
<p><br>
</p>
<p>There is a bit of confusion here, because there are 2 distinct
notions (that interacts)</p>
<p><br>
</p>
<p>1_ the fact to change the nifti header after an affine
coregistraiton: <br>
</p>
<p> this is the spm way against all other coregistration
software. The main advantage of changing the nifti header is that
you can visualize the result of your registration without the need
to interpolate (no resampling of the data). This is of minor
importance since at the end usually you spatially normalize your
data and other software combine the affine and the non linear
transformation in order to have only one resampling. (so both way
are equivalent)<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>2_ The fact to have 2 affine store in the nifti volume. <br>
</p>
<p><br>
</p>
<p>My point is that <br>
</p>
<p> _ I do not see, any good reason to do this, because at the
end you want to have one and only one affine associate to your
volume</p>
<p> _ if sform and qform are alway the same ... what the point to
store 2 affine ?</p>
<p> _ if they can be different, which one to choose (The initial
nifti definition is not clear about it) <br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>@rick after a SPM coregistration you end up with 2 different
affine, but this is not meant to be combine (the qform store the
original affine and the sform the new affine (after
registration)). So there is no need of combination</p>
<p><br>
</p>
<p>My experience is that I can have serious problem when I have 2
different sform/qform, so the best after SPM coregister is to use
fsl copysform2qform utility</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>I think that the best solution would be to remove one of the two
affine in the nifti header, so that there can not be any
ambiguity, but I guess there will be too much backard
incompatibilities ... So may be having sform and qform coding for
the same affine is the best way to go. But then it should be more
advertise, so that this is the default when writing nifti <br>
</p>
<p><br>
</p>
<p>But ok : one can live with imperfect nifti definition ... (<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 12/07/2021 17:05, Reynolds, Richard
C. (NIH/NIMH) [E] via Neuroimaging wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BLAPR09MB73958E904028A2289E216CD9F7159@BLAPR09MB7395.namprd09.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
<div style="font-family: Tahoma, Geneva, sans-serif; font-size:
12pt; color: rgb(0, 0, 0);">
<p class="p1" style="margin:0px;font:13px Menlo"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures">Hi
Romain,</span></p>
<p class="p2" style="margin:0px;font:13px Menlo;min-height:15px"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures"></span><br>
</p>
<p class="p1" style="margin:0px;font:13px Menlo"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures">As Demian
mentions, having the 2 transforms allows one to have a
dataset in both original space and standard space, for
example.<span class="Apple-converted-space">
</span>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.<span
class="Apple-converted-space"> </span>There was also an
advantage of not having to even store the transformed result
unless needed, possibly saving disk space.<span
class="Apple-converted-space">
</span>I don't know t</span><span
style="font-variant-ligatures: no-common-ligatures;">hat
anyone takes advantage of that anymore.</span></p>
<p class="p2" style="margin:0px;font:13px Menlo;min-height:15px"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures"></span><br>
</p>
<p class="p1" style="margin:0px;font:13px Menlo"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures">Also,
note that the qform and sform are not quite interchangeable.<span
class="Apple-converted-space">
</span>The qform transformation is not a general affine,
while the sform is. <span class="Apple-converted-space">
</span></span></p>
<p class="p2" style="margin:0px;font:13px Menlo;min-height:15px"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures"></span><br>
</p>
<p class="p1" style="margin:0px;font:13px Menlo"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures">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</span><span
style="font-variant-ligatures: no-common-ligatures;"> be
needed.</span></p>
<p class="p2" style="margin:0px;font:13px Menlo;min-height:15px"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures"></span><br>
</p>
<p class="p1" style="margin:0px;font:13px Menlo"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures">Most
packages write out transformations separately so that they
can be concatenated without repeated resampling/blurring of
the volumetric data.<span class="Apple-converted-space">
</span>In AFNI, the sform and qform are just ijk to xyz
transformations to put the data on a regular grid.<span
class="Apple-converted-space">
</span>As mentioned, registration transformations are
generally kept separate to be concatenated and applied.<span
class="Apple-converted-space">
</span>So the sform and qform are always identical after a
typical operation, as you mention.</span></p>
<p class="p2" style="margin:0px;font:13px Menlo;min-height:15px"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures"></span><br>
</p>
<p class="p1" style="margin:0px;font:13px Menlo"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures">If the
qform and sform are different after the SPM registration,
perhaps that registration</span><span
style="font-variant-ligatures: no-common-ligatures;"> transformation
was not applied, in which case you might want to extract</span><span
style="font-variant-ligatures: no-common-ligatures;"> it
into a text file.</span><span class="Apple-converted-space"
style="font-variant-ligatures: no-common-ligatures;">
</span><span style="font-variant-ligatures:
no-common-ligatures;">Note that since it is presumably
ijk-to-xyz, the sform </span><span
style="font-variant-ligatures: no-common-ligatures;">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.</span></p>
<p class="p2" style="margin:0px;font:13px Menlo;min-height:15px"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures"></span><br>
</p>
<p class="p1" style="margin:0px;font:13px Menlo"><span
class="s1"
style="font-variant-ligatures:no-common-ligatures">- rick</span></p>
<br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
VRomain <a class="moz-txt-link-rfc2396E" href="mailto:romain.valabregue@upmc.fr"><romain.valabregue@upmc.fr></a><br>
<b>Sent:</b> Friday, July 9, 2021 7:06 AM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:neuroimaging@python.org">neuroimaging@python.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:neuroimaging@python.org"><neuroimaging@python.org></a><br>
<b>Subject:</b> Re: [Neuroimaging] why 2 affine transforms in
the nifti</font>
<div> </div>
</div>
<div>
<p>Yes thanks for the reference, that is indeed the right place
to start, <br>
</p>
<p>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.</p>
<p>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 ...)</p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>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 !)</p>
<p><br>
</p>
<p>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 !)<br>
</p>
<p>is there any tools or use case, that need this 2 transforms ?</p>
<p><br>
</p>
<p>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 ...</p>
<p>if you stay with other coregistration tool, you just do not
care and stay with 2 identical affine stored in the header ...
<br>
</p>
<p><br>
</p>
<br>
<div class="x_moz-cite-prefix"><br>
</div>
<div class="x_moz-cite-prefix">Le 09/07/2021 à 11:13, Demian
Wassermann a écrit :<br>
</div>
<blockquote type="cite">
<pre class="x_moz-quote-pre">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 <a class="x_moz-txt-link-freetext" href="https://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields/nifti1fields_pages/qsform.html" moz-do-not-send="true">https://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields/nifti1fields_pages/qsform.html</a> ) 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
<a class="x_moz-txt-link-abbreviated" href="mailto:demian.wassermann@inria.fr" moz-do-not-send="true">demian.wassermann@inria.fr</a>
Associate Research Professor (CRCN)
Parietal Team
INRIA Saclay Ile-de-France
1 Rue Honoré d'Estienne d'Orves, 91120 Palaiseau
</pre>
<blockquote type="cite">
<pre class="x_moz-quote-pre">On 9 Jul 2021, at 10:51, VRomain <a class="x_moz-txt-link-rfc2396E" href="mailto:romain.valabregue@upmc.fr" moz-do-not-send="true"><romain.valabregue@upmc.fr></a> 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 - <a class="x_moz-txt-link-freetext" href="https://github.com/poldracklab/nitransforms" moz-do-not-send="true">https://github.com/poldracklab/nitransforms</a> <a class="x_moz-txt-link-rfc2396E" href="https://github.com/poldracklab/nitransforms" moz-do-not-send="true"><https://github.com/poldracklab/nitransforms></a>)
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
<a class="x_moz-txt-link-abbreviated" href="mailto:Neuroimaging@python.org" moz-do-not-send="true">Neuroimaging@python.org</a>
<a class="x_moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/neuroimaging" moz-do-not-send="true">https://mail.python.org/mailman/listinfo/neuroimaging</a>
</pre>
</blockquote>
<br>
<fieldset class="x_mimeAttachmentHeader"></fieldset>
<pre class="x_moz-quote-pre">_______________________________________________
Neuroimaging mailing list
<a class="x_moz-txt-link-abbreviated" href="mailto:Neuroimaging@python.org" moz-do-not-send="true">Neuroimaging@python.org</a>
<a class="x_moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/neuroimaging" moz-do-not-send="true">https://mail.python.org/mailman/listinfo/neuroimaging</a>
</pre>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Neuroimaging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Neuroimaging@python.org">Neuroimaging@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/neuroimaging">https://mail.python.org/mailman/listinfo/neuroimaging</a>
</pre>
</blockquote>
</body>
</html>