search

cselenyi / solenabugs

Solena Bug Tracking
GNU Lesser General Public License v2.1
0 stars 0 forks source link

MR_seg_fs not in line with MR_crop #29

Closed GinaGriffioen closed 1 year ago

GinaGriffioen commented 2 years ago

Just for one subject in my study, the seg_fs is not aligned with the MR_crop: it is moved for about 3 cm towards frontal in the sagittal plane. This is only the case in SPM and SPM, not in Vinci and freeviewer. It leads however till distorted TACs. In the rname_MR_crop.mat we find a big difference in the sagittal plane, see image. mat is the rname_MR_seg_fs.mat file and mat is the rname_MR_crop.mat file 2022-05-20 (1).

All the other subject don't have this issue. I already rerunned all the steps including freesurfer, but with the same result.

How to solve this issue?

cselenyi commented 2 years ago

Dear @GinaGriffioen , sorry for this problem! I have found the subject in your study folder and I have found the reason. It appears that 3 minutes after the subject's "r.._MR_crop.nii" file was created by the pipeline the image was manually reoriented in the SPM viewer, moving it forward 3 cm and slightly rotating it. You can see that there is an "r.._MR_crop_reorient.mat" file there which contains this (probably undesired) reorientation. SPM then "baked in" this reorientation into the .nii file itself. (A bit of background here: the space definition for the NIfTI images in SPM has 3 locations, each of which can be an alternative space definition: in the .nii image itself, in the header, there are 2 variants, called "mat0" and "mat", and then in the .mat file we have the additional alternative space definition (the one that you also shared above), which is a 4x4x2 matrix but only the first plane (i.e. val(:,:,1) above) is the one that counts, the other one is ignored. SPM tools and most of the pipeline steps know about these 3 locations and actually use the 3d place (the .mat file) if it exists to get the actual space definition for the image. If it's missing then it's using the space definition in the header (the "mat" field) ). So the baked in incorrect space definition then carried over into the FreeSurfer results as the freesurfMR step does not look at the .mat file but uses the .nii image only for FreeSurfer processing (as FreeSurfer itself does not know/care about the .mat file). But since the .mat file of the MR image was left untouched by the unwanted manual reorientation step, therefore when displaying the r.._mr_seg_fs.nii results on top of the MR image then you can see that they are not in register (since for displaying the MR image the viewer looks at the still correct .mat to get the space of the MR image). When you displace them in other software (such as Vinci or FreeViewer) they look fine since both have the baked-in incorrect space definition. So, after a long explanation :-) , you have 2 choices:

  1. Quick & dirty work-around: delete the r.._MR_seg_fs.mat (and r.._MR_seg_fs.DBBB9F0C) files and copy the r...MR_crop.mat to both of these filenames. Then you can run the pipeline from the steps after the freesurfMR step.
  2. Clean solution: Delete the whole contents of the ..processed\mr_ana folder (or move them to a backup folder if you want). Then run the step "cropMR4PET" in the pipeline. It should actually pick up your previously set reorientation & cropping settings for the "raw" MR image so you can just click the 'Reorient & Crop' to reproduce the r..._MR_crop.nii (and .mat) files. Then you can run the steps following that (including a rerun of freesurfMR).