Dear all,
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?
Best regards,
Manuel
Hi Manuel,
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.
Cheers,
Dave
Hi David,
I understand what you mean, but my problem is different (I think). I’m using the following command:
mrresize -voxel 1 -interp sinc subject.nii.gz subject_RES.nii.gz
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.
Regards,
Manuel
@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.
Hi Donald,
I think is the direction of the axes, here is the mrinfo output of the raw data:
Image: “7004_diff.nii.gz”
Dimensions: 128 x 128 x 50 x 75
Voxel size: 2 x 2 x 2 x 7.3
Data strides: [ -1 2 3 4 ]
Format: NIfTI-1.1 (GZip compressed)
Data type: signed 16 bit integer (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 1 0 0 -118.1
-0 1 0 -152.5
-0 0 1 -71.93
comments: TractoR NIfTI writer v2.4.0
and after mrresize:
Image: “7004_diffRES.nii.gz”
Dimensions: 256 x 256 x 100 x 75
Voxel size: 1 x 1 x 1 x 7.3
Data strides: [ -1 2 3 4 ]
Format: NIfTI-1.1 (GZip compressed)
Data type: 32 bit float (little endian)
Intensity scaling: offset = 0, multiplier = 1
Transform: 1 0 0 -118.6
-0 1 0 -153
-0 0 1 -72.43
comments: TractoR NIfTI writ
mrtrix_version: 0.3.13-768-g3898921e
From my point of view, booth of them look fine, but when I open it with another viewing, the orientation of the axis is different.
Regards,
Manuel
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…?
Hi Donald,
Thanks, that’s probably the reason, the images are perfect but in different orientation, once I change the orientation all are perfectly aligned.
Regards,
Manuel
OK, good to know. Just out of interest, how did you change the orientation…?
Hi Donald,
I changed the orientations using convert3d, with the -orient option.
Regards,
Manuel
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, convert3d should 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:
Image: "7004_diff.nii.gz"
...
Data strides: [ -1 2 3 4 ]
...
and after mrresize:
Image: "7004_diffRES.nii.gz"
...
Data strides: [ -1 2 3 4 ]
...
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…
Hi,
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…
Regards,
Manuel
I’m pretty stumped by this… Any chance you could post the output of FSL’s fslhd on each of those images…?
Hi Donald,
fslhd for the raw file:
filename /mnt/usb-TOSHIBA_External_USB_3.0_20150819005525F-0:0-part1/TRACTOGRAPHY/RAW/DIFF/beforeUP/B0/7004_B0.nii.gz
sizeof_hdr 348
data_type FLOAT32
dim0 3
dim1 128
dim2 128
dim3 50
dim4 1
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 16
nbyper 4
bitpix 32
pixdim0 0.000000
pixdim1 2.000000
pixdim2 2.000000
pixdim3 2.000000
pixdim4 1.000000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.0000
cal_min 0.0000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 0.000000
time_offset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Aligned Anat
qform_code 2
qto_xyz:1 -2.000000 0.000000 -0.000000 135.918015
qto_xyz:2 0.000000 2.000000 -0.000000 -152.490677
qto_xyz:3 0.000000 0.000000 2.000000 -71.929497
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -2.000000 0.000000 0.000000 135.918015
sto_xyz:2 0.000000 2.000000 0.000000 -152.490677
sto_xyz:3 0.000000 0.000000 2.000000 -71.929497
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Posterior-to-Anterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+
file_code 1
descrip FSL5.0
aux_file
and for the resampled file:
filename /mnt/usb-TOSHIBA_External_USB_3.0_20150819005525F-0:0-part1/TRACTOGRAPHY/RAW/DIFF/RES/7004vol_0000.nii.gz
sizeof_hdr 348
data_type FLOAT32
dim0 3
dim1 256
dim2 256
dim3 100
dim4 1
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 16
nbyper 4
bitpix 32
pixdim0 0.000000
pixdim1 1.000000
pixdim2 1.000000
pixdim3 1.000000
pixdim4 7.300000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.0000
cal_min 0.0000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 0.000000
time_offset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 1.000000 -0.000000 -0.000000 136.418015
qto_xyz:2 0.000000 1.000000 0.000000 -152.990677
qto_xyz:3 0.000000 0.000000 -1.000000 -72.429497
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Left-to-Right
qform_yorient Posterior-to-Anterior
qform_zorient Superior-to-Inferior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -1.000000 0.000000 0.000000 136.418015
sto_xyz:2 0.000000 1.000000 0.000000 -152.990677
sto_xyz:3 0.000000 0.000000 1.000000 -72.429497
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Posterior-to-Anterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+
file_code 1
descrip FSL5.0
aux_file
There are differences in the qform orientation, but I really don’t know why.
Regards,
Manuel
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…