[ENH] New ConformImage interface #1868
Conversation
This interface is intended to be placed in the beginning of workflows, with the idea of checking and overwritting image orientation (to RAS), the data type, and the affine matrix.
Codecov Report
@@ Coverage Diff @@ ## master #1868 +/- ## ========================================== - Coverage 73.13% 73.09% -0.04% ========================================== Files 1065 1067 +2 Lines 53429 53509 +80 ========================================== + Hits 39075 39114 +39 - Misses 14354 14395 +41
Continue to review full report at Codecov.
|
| Do I understand right - that you're intending to get the images to RAS+ orientation (more or less) by using |
| Thanks very much @matthew-brett, that is the idea. I'd say a fair amount of software will dismiss these headers by default (e.g. when using ANTs to register two images nobody prevents you to manually set an initialization matrix you computed from the headers of the images, but normally it will align the centers of mass/volume of the two). This interface could be handy when you want to ignore these matrices. But practically speaking, yes, simplifying the metadata of the images is sometimes beneficial to simplify the whole workflow. This new interface would write the headers out, so that you can set them back if necessary. I will add a big warning on the documentation for this interface, to clearly state the concern you raised. With all that in mind, if your intention is to get rid of the sform and qform, this code (https://github.com/oesteban/nipype/blob/9a2ff5a8879a2dbda568d12fced23356cfd56d18/nipype/interfaces/utility/nifti.py#L151-L166) is correct? Does |
| data = nb.as_closest_canonical(nii).get_data() | ||
| aff = nb.as_closest_canonical(nii).header.get_base_affine() | ||
| hdr['qform_code'] = 0 | ||
| hdr['sform_code'] = 0 |
There was a problem hiding this comment.
my worry is with this setting. this brings us back to analyze days. if i'm given this file without any context, then i have no way of knowing what's left or right in the brain.
wouldn't it be better to use an sform code that aligns with a standard?
There was a problem hiding this comment.
This is why I asked @matthew-brett to look at this. If I'm not wrong, by using as_closest_canonical we are basically addressing this problem. That function makes sure the image is in RAS, and the rationale was as follows: if you are sure your image has no axis flipped, then you can project the axes (making the affine a diagonal matrix scaled by the pixel spacings).
There is some code, for the situation where you want LAS that intends to do the same. We could also implement other options when the axes are in canonical order.
| Hmm. So SPM, for example, will assume that a file without an affine is in LAS+ voxel order, but I believe you can change that interpretation with an SPM defaults setting. So, I can see that it might be safer to pull the images into some standard voxel orientation before starting the processing (if you can afford the cost of that operation), but I'm not sure I see the logic of discarding the remaining affine. Even if some software does not use it, other software (such as SPM) will. |
| I see. I'll add all these details in the documentation, particularly the SPM detail. Also, I'll add a big runtime warning when the option of trashing the original affine is enabled (it should be disabled by default). |
| I have posted this: nipy/nibabel#518 The idea for this interface is that you would specify the desired output orientation and rewrite the affine so that it is closest to that orientation. With a boolean option (false default), the removal of the s/q form matrices would be done (with a big warning showing up) |
| @oesteban - the days of the analyze format were so fraught with danger that i'm quite susceptible to seeing this through an emotional lens. would it be possible to do the canonical reorientation but still leave a specific qform or sform in place? |
| @satra - sure, that would be the default behavior of the interface |
| We could save the original sform/qform in the Nifti description field of the header. |
| @oesteban - is this still relevant, or can you simplify and directly use nibabel's |
| @satra I'll have a look soon |
| I think this is not a problem for now. Will open a new PR if something changes. |
4 participants
This interface is intended to be placed in the beginning of workflows, with the idea of checking and overwritting image orientation (to RAS), the data type, and the affine matrix.
It'd be great to hear from @matthew-brett about this PR:
Regarding the affines:
We are seeing how the sform and qform matrices are not homogeneously interpreted by software, and they are a potential source of errors. The idea of this node is that, when images enter the pipeline and since most of the software will not care much about these matrices (for instance, if you use ANTs and initialize aligning centers of masses you are defeating their purpose, right?), it is probably more stable to use the base affine, with the center at the center of the volume.
When the workflow ends, one can always re-set these matrices to the appropriate values depending on the coordinate system the images are referred to (there is an output to get the original headers backed-up).