When I use some of the commands (like mrresize or 5tt2gmwmi) the orientation of my images changes, it’s not a big deal, I can easily solve it, but I was wondering if there is a command to avoid this and what’s the reason for this. Maybe all the operations are performed in the MNI space?
What do you mean by orientation of your images changes? Do you mean the transform in the image header is modified? If so, then this is expected behaviour. mrresize should modify the image grid, but ensure the image itself remains in the same location in scanner space. This means that the 3 values in the right column of the transform that designate the position of the 0,0,0 voxel centre (with respect to the scanner space origin) are modified. A different voxel size means it’s centre must be in a different (slightly shifted) scanner position, given the FOV must remain the same (or close as possible if defining the new grid with -vox).
Let me know if this does not make sense, or if you are talking about something different. Happy to clarify with a diagram if needed.
Also, this has nothing to do with MNI space.
My images are going from 2x2x2 to 1x1x1, everything works fine, but I open the image with ITK-Snap and I found that the orientation of the original (RAI code) is RPI, and the resampled one is LPS. As I said is not a big deal, but I was curious to know the reason or if there was a flag in the command to solve this.
@mblesac: can you provide the output of mrinfo for both input and output? I’m just a bit confused about how RPI / LPS maps onto our strides. Does RPI refer to the location of the corner voxel, or to the direction of the axes…?
Otherwise, I can’t see anything in there that would modify the strides or the transform (i.e. anything that might affect what you call the orientation). If you post the above information, it might help to narrow down what’s going on.
So this looks entirely self-consistent to me… Maybe you can try running mrinfo with the -norealign option to see exactly what the transfom information was in the NIfTI header (MRtrix3 does otherwise massage this information somewhat before using it to make everything consistent with anatomical axes). But given what you’ve shown, I don’t see that this will make any difference - I expect the outputs to match with each other (although they’ll probably be different from what you show here).
However, there’s a bunch of unused fields in the NIfTI header that may be set and/or interpreted by whatever other software package you’re using. MRtrix3 does set a couple of these fields, which may explain the differences. The reason these fields are set is mostly historical - that’s what they seemed to be set to in all the Analyse data that I’d come across so far (and also what SPM set these values to at the time, probably around 2005…), so it seemed sensible to make sure they remained as-is. But technically, they shouldn’t be interpreted by a NIfTI-1 compliant viewer: the standard quite explicitly specifies them as unused - while MRtrix3 does fill some of the values on write, it completely ignores them on read.
So that’s my best guess as to what might be causing the discrepancy. But I don’t think it’s a bug in MRtrix3… Does this mean the images are displaying differently in your other viewer, or just that the orientation is reported as being different…?
Thanks for the update. I’ve had a look through the documentation for convert3d’s -orient option, and I can’t make sense out of what you show. As far as I can tell, convert3dshould do what I’d expect it to, but it doesn’t match up with what seems to actually happen.
Looking at the output of mrinfo that you provided earlier in this post:
These suggest that the orientation should be interpreted by convert3d as LAS for both images - the only difference from the NIfTI-default RAS is the inversion of the x-axis. But neither of these match what you stated earlier on:
So I’m not sure what would cause this discrepancy. The only thing I can think of is that your other viewer is interpreting some (deprecated and unused) flag in the NIfTI header. But if that’s the case, it would explicitly not be NIfTI-compliant: the NIfTI standard states quite explicitly that ‘NIFTI-1 does not have the ANALYZE 7.5 orient field, which is not general and is often not set properly’. The reasons for not using that field are discussed for example on this page, under the section ‘The Problem With hist.orient Field’, which highlights the issues associated with it for the old Analyze format. In fact, given that the byte offset to this entry in the old Analyze header is now within the NIfTI qform code, I can’t see how you can interpret a proper NIfTI image that way, it’s just not possible. So maybe that’s not what the problem is, I just can’t think of any other semi-sensible interpretation…
I don’t know the reason behind this miss match of the orientations. Attached is a screnshoot of how they look in the ITK-Snap viewer (left is the raw image, right the up-sampled image). This was a problem to realize some registrations, but after reorient the image, everything works fine. I don’t know if more people found this problem…
OK, there was a bug in the qform output in MRtrix3, which was discussed at length in this thread, and I was hoping was fixed with this commit on April 22. If your install is older than that, there is a good chance updating might fix it (git pull && ./build). However, it might be that the fix I’d committed didn’t actually completely address the issue - the original problem seemed to persist in that thread, although I was unable to reproduce it. If updating doesn’t fix it, it would be good if I could have access to the data to investigate further.
So this would address the discrepancy between the qform and the storm in the output, which sounds like the problem. The RAI code in ITKsnap matches what fslhd reports, and gets the wrong inferior-superior direction in the output. The most likely explanation is that ITKsnap is reading the (incorrect) qform and ignoring the sform (MRtrix3 uses the sform preferentially)…
By the way, I notice that earlier on, I used LAS to describe what ITKsnap refers to as RPI, etc. The issue is that I expect for example L to mean ‘towards the left’, whereas ITKsnap expects it to mean ‘from left to right’ - the exact opposite. I’m not sure who’s right here - probably not me… But the point is there’s no disagreement, at least as far as the input image is concerned. The problem really seems to be confined to the incorrect qform…