After preprocessing single or multiecho images in fmriprep, images load in FSL displaying voxel and MNI coordinate systems.
However, after denoising with XCP, images in FSL display only voxel and scanner space systems. I tried using niftiinfo to extract the header of the original image and then save the denoised image with this header, but surprisingly, this dodgy fix/test still didn’t seem to do the trick.
In the attached image, you can see that the image properties of preprocessed and denoised images appear identical, incl. sform and qform matrices, but the “S Form Code” is “MNI152” in the original preprocessed image, and “scanner anatomical” after denoising. Also, these fields seem to not appear in niiinfo. I could try other ways of finding and adjusting this field in the header, but not sure if that is the most sensible approach.
Do you have any suggestions on how to avoid this issue or restore the image display properties?
A NIfTI header can store two different spatial transforms for converting voxel indices into world space: the quaternion-based Qform and the matrix-based Sform.
The Qform encodes 9 degrees of freedom—rotation, scaling/zooms, and translation (each in three dimensions)—while the Sform can represent the full affine 12 degrees of freedom, including shears. In this sense, the Sform is a superset of the Qform.
The design intent was for a single NIfTI file to retain both its transform into native scanner space and its affine transform to normalized space (e.g., MNI152), with the xform code indicating which was which. Some tools handle differences in xform codes gracefully, in particular FSLeyes elegantly allows you to choose your desired display space. Unfortunately, not all tools are so astute and this feature caused confusion: some tools gave precedence to the Qform (e.g., older ITK tools, which cannot handle shears), while others prioritized the Sform.
To reduce ambiguity, many tools now set the Qform and Sform to identical codes and values (with any shears omitted from the Qform). This appears to be the case in your example. It is interesting that the Sform code is being downgraded—likely because promoting a Qform (which cannot store shears) to MNI space could be misleading.
When the NIfTI format was finalized, including two spatial transforms was controversial. It was an aspirational feature, but it exceeded the capabilities of many tools at the time. While the idea of having two representations is attractive, in your case they are identical, and maintaining both often complicates interoperability between software packages.
I would open a bug report with tedana (issue tracker). My guess is it’s just an oversight, since many tools do not make a particular effort to ensure accurate xform codes.
I’ll double-check, but tedana uses nibabel for reading & writing NIfTI files and should be just copying the transforms from the inputted to the outputted files & I haven’t seen this issue before within tedana. Any chance you can confirm that the files that are inputted into tedana have the Sform transform and the files immediately outputted after tedana do not?
