[Neuroimaging] [nibabel] sform/qform flipping left - right in the affine and (possibly) fsl

Jean-Christophe Houde jean.christophe.houde at gmail.com
Mon Jun 27 09:06:50 EDT 2016


Just a quick note: qform_code = 0 normally means that it is not set, so I'm
surprised to see some values in your last qto_xyz...

2016-06-27 8:04 GMT-04:00 Samuel St-Jean <stjeansam at gmail.com>:

> So, to add a more practical example to what I outlined above, seems like
> saving a dataset in this manner preserves the sform, but changes the qform.
> According to the doc, they should both provide the same information in
> reconstructing the affine (possible from different origins). So I compared
> the header of an original nifti file and the same thing after saving it
> without headers, and here are the interesting parts.
>
> - sform is identical
> - sform name changed from
>
> sform_name     Scanner Anat
> sform_code     1
>
> to
>
> sform_name     Aligned Anat
> sform_code     2
>
> - some qform fields went from
>
> qform_name     Scanner Anat
> qform_code     1
> qto_xyz:1      1.796652  0.000000  0.000000  -115.754318
> qto_xyz:2      0.000000  1.795833  -0.054337  -90.885376
> qto_xyz:3      0.000000  0.054236  1.799180  54.572971
>
> to
>
> qform_name     Unknown
> qform_code     0
> qto_xyz:1      1.796652  0.000000  0.000000  0.000000
> qto_xyz:2      0.000000  1.796652  0.000000  0.000000
> qto_xyz:3      0.000000  0.000000  1.800000  0.000000
>
> Which leaves me wondering what is to be trusted in these fields. Seems
> like the translation of origin in qform changed (and the name is unknown,
> so nibabel ignores it on loading), but the sform name changed without
> changing the actual matrix and now has the translation of the qform. Is
> there a way to know how these fields are consistent when recreated by
> nibabel versus the original provided in the (now stripped) header? Or maybe
> the fsl suite just does not respect some convention I am unaware of (like
> trusting undefined qform over sform or something else like that), which is
> also possible, and would fall out of scope of this mailing list.
>
> Samuel
>
> 2016-06-24 8:35 GMT+02:00 Samuel St-Jean <stjeansam at gmail.com>:
>
>> Hello,
>>
>> So this is probably gonna look as a confused question because I still do
>> not fully understand the issue myself. Anyway, reading upon
>> https://github.com/nipy/nibabel/pull/90 and playing with loading a nifti
>> and saving it back, it seems like sometimes the affine, sform and qform do
>> not fully agree upon something and end up overwriting each other.
>>
>> This also seems to only happen with data that went through fsl, like the
>> HCP datasets. So basically a normal pipeline involving nibabel is like
>>
>>
>> volume = nib.load('my_data.nii.gz')
>> data = volume.get_data()
>> affine volume.get_affine()
>>
>> ## Do stuff on data
>>
>> nib.save(nib.Nifti1Image(data, affine),'my_new_data.nii.gz')
>>
>>
>> Note how I did not save the header in this case. Now, for almost all
>> cases, this works fine and a new header get created. And now for the
>> question :
>>
>> Is it a bad idea to strip out the header (since dtype, pixdim and other
>> things might change depending on the processing involved)?
>> Is it possible to save back exactly the same header / sform / qform so
>> that data won't be flipped in e.g. fslvew afterward? Is it just because
>> software don't play well together or there is an unseen issue I don't get
>> here?
>>
>> I also remember a few years back playing the whole afternoon with get/set
>> qform and sform rewriting our affines everytime, so I though might as well
>> ask everyone since we never fully figured out the logic between what sets
>> the affine in the header and why.
>>
>>
>> Thanks for reading,
>>
>> Samuel
>>
>>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20160627/14b05cad/attachment.html>


More information about the Neuroimaging mailing list