Dear AFNI developers and experts,
I encountered an issue that I had not quite expected in the behaviour of 3dresample. I found a way around this (using another tool) but wanted to post it here anyway in case other people experience the same issue.
Essentially, I have a functional image (pre.nii.gz) at an oblique angle that I want to upsample.
So I use:
3dresample -input pre.nii.gz -prefix pre_resampled.nii.gz -dxyz 1 1 1
I think the pre_resampled.nii.gz output somehow has a different oblique angle. Indeed, when I load pre as underlay and pre_resampled as overlay, AFNI tells me: “The underlay/overlay pair of datasets (…) have oblique angle difference of 22.60 degrees.” When I click away that message the images do show up in alignment in AFNI. However, other tools disagree. For example fsleyes shows the two images as being wildly out of alignment (see attached figure). Also, when I do further processing with this such as applying transforms with this resampled image as a reference (using antsApplyTransform) the result is images that are cut.
I suppose this may somehow be the intended way for 3dresample to work, but for me it was unexpected, so I wanted to mention it here.
The afni GUI only shows the cardinal representations of the data, not at an oblique angle. When you apply the 3dresample command, it resamples the cardinal representation and removes the oblique angle information from the header. The original and resampled datasets will overlay each other inside the afni GUI, but not in GUIs that “turn” the data to show the data obliquely. You can see more information about how AFNI deals with obliquity here:
To make all packages, deal with the data in the same way, you could potentially remove the obliquity information to make it appear cardinal to all software with 3drefit. Best to do that on a copy rather than the original data.
Hi Daniel Glen, thanks so much for responding, I understand a bit better now what is going on.
Is there a reason that 3dresample removes the oblique orientation information from the header? I know it doesn’t make a difference for the AFNI display, but it does make a difference in analysis pipelines, especially with other software (e.g. ANTS). For instance, I applied a transformation that correctly registered an image to the original functional, but then failed to register it to the resampled functional. Actually worse than that: it didn’t give an error but it produced a clipped version of the transformed image, because now part of the image was out of the (non-oblique) field of view. It was a long road to track that down and I imagine I may not be the only one to naively assume that 3dresample would conserve the header information.
3dresample removes the oblique transformation matrix
because it is no longer correct. It is nothing particular
to 3dresample, but applies to basically every program
that would perform such an operation.