Labelsgmfix left thalamus not labelled


#1

Dear MRtrix team,

I am using 5ttgen fsl and a freesurfer parcellation I run the commands below to get the corrected aparc+aseg.nii with fsl basal ganglia. However the resulting image the left thalamus is not labelled (see screen shot)

Thanks for your help

Peter

Commands:

labelconvert aparc+aseg.nii $FREESURFER_HOME/FreeSurferColorLUT.txt /usr/local/mrtrix3/src/connectome/tables/fs_default.txt node.mif -force
labelsgmfix aparc+aseg.nii T1.nii /usr/local/mrtrix3/src/connectome/tables/fs_default.txt nodes_fixSGM.mif -premasked -force


#2

However the resulting image the left thalamus is not labelled (see screen shot)

I don’t think that’s the only problem… :scream:

  • Pretty sure that great big red blob at the front of the brain might be the thalamus. And the cyan blob and little blue bits at the top of the image will be other basal ganglia structures.

  • The entire left hemisphere cortex is black and hence unlabelled.

Looks like you’re running labelconvert to produce file node.mif, but then feeding aparc+aseg.mgz as input to labelsgmfix. This has a couple of consequences. Firstly, the index values in aparc+aseg.mgz and fs_default.txt do not correspond to one another; hence structures are not being properly selected for replacement. Secondly, it looks like there’s a FIRST axis convention conversion problem, which results in the new parcellations being misaligned (not just shifted, but one or more 90-degree rotations). I haven’t seen this for quite a while; I do note however that you’re using pre-3.0_RC1 MRtrix3.

Rob


#3

Hi Rob,

Thanks, yes the registrations are way off, I have updated my version and used the node.mif but still having the same problem,

Can I check regarding the inputs for labelsgmfix? I am using the node.mif generated from aparc+aseg.nii from Freesurfer and regarding the T1 - I used the original T1 but now realize this is not in freesurfer space. I then tried the freesurfer T1 but fsl first failed.

I am assuming the registrations to diffusion are performed after the labelsgmfix?

Thanks again for all your help.

bw

Peter


#4

Thanks, yes the registrations are way off

I’d be wary of calling it a “registration”; the issue arises from inconsistent interpretation of image axes, there’s no “registration” step per se.

Can I check regarding the inputs for labelsgmfix?

So the input parcellation and T1 images don’t strictly have to be defined on the same voxel grid: FIRST provides its segmentations as surface meshes, which are converted from FIRST’s axis convention to scanner-space coordinates, and them mapped to the parcellation image voxel grid via the mesh2pve command. This process does however require that those two images be intrinsically aligned with one another in scanner space. I’m reasonably confident that the conversion from FIRST to scanner space coordinates is correct, so my suspicion is that FreeSurfer has done some form of axis conversion / permutation at the subject import step. But you’ll need to look very closely at your images at the input & output of all steps to figure out where the discrepancy is coming from. Make sure you use the “Overlay” tool in mrview to assess whether or not two images are aligned with one another; flicking between two images with the “snap to axes” option on snaps the camera position to each image as you switch, so may not give a faithful representation.

Normally my suggested quick solution would be to provide as the T1 image the orig.mgz file imported & saved by FreeSurfer, but:

I then tried the freesurfer T1 but fsl first failed.

:-/

I am assuming the registrations to diffusion are performed after the labelsgmfix?

Your main issue here is independent of inter-modal registration. Nevertheless, registration between T1 and DWI can happen before or after T1 processing. The trick is that if you perform any transformation of the T1 after processing, any images derived from that T1 need to undergo the same transformation; otherwise you will have aligned the T1 with your DWIs, but e.g. the parcellation image remains misaligned.

Rob


#5

Thanks Rob,

Will I use orig.nii.gz (I convert the file to .nii.gz from .mgz) i.e. labelsgmfix node.mif orig.nii.gz fs_default.txt nodes_fixSGM.mif -premasked -force

I get the following error;

Command:  run_first_all -s R_Thal,L_Caud,L_Pall,L_Puta,L_Thal,R_Caud,R_Puta,L_Accu,R_Pall,R_Accu -i T1.nii -b -o first
Command:  mrcalc parc.mif 0 -min sgm.mif
Traceback (most recent call last):
  File "/usr/local/bin/labelsgmfix", line 109, in <module>
    app.error('Missing .vtk file for structure ' + struct + '; run_first_all must have failed')
NameError: name 'struct' is not defined

However it works fine if I use brain.mgz, and the parcellation with brain.mgz also looks fine.

Because of this I had thought to use brain.mgz in place of orig.mgz however I run into problems using "5ttgen fsl brain.nii.gz 5tt.mif -force"
as i get an error with the 5tt.mif when trying to calculate the response functions.

Thanks again for all your help.

bw

Peter


#6

NameError: name 'struct' is not defined

OK, there’s a silly error in there with me using the wrong variable name, which is why you don’t get a more nicely formatted error message; but you can nevertheless tell from the message that FIRST isn’t happy.

However it works fine if I use brain.mgz, and the parcellation with brain.mgz also looks fine.

If you’re using brain.mgz, you should be running labelsgmfix with the -premasked option. This passes the message through to FIRST that the image has already undergone brain extraction, and this influences which template image is used for registration.

If the script works with brain.mgz but not orig.mgz, I’m guessing that you acquisition includes a lot of neck, and that this is subsequently throwing out the initial registration step in the run_first_all script. Purely a guess though.

Because of this I had thought to use brain.mgz in place of orig.mgz however I run into problems using
5ttgen fsl brain.nii.gz 5tt.mif -force
as i get an error with the 5tt.mif when trying to calculate the response functions.

You should also use the -premasked option if providing brain.mgz to the 5ttgen fsl script; otherwise it will try to itself run brain extraction, which may remove large volumes of brain, causing concomitant issues down the line when you try to subsequently use the 5TT image to derive something else (as I mentioned in another thread today, it’s important to trace back to the root of the problem, rather than focusing on the final symptom).

Rob


#7

Thanks so muc Rob, this works perfectly.

One other query: When running -

labelconvert aparc+aseg.nii.gz $FREESURFER_HOME/FreeSurferColorLUT.txt /usr/local/mrtrix3/src/connectome/tables/fs_default.txt node.mif -force

I get the error -

labelconvert: [WARNING] Image “aparc+aseg.nii.gz” stored as signed integer; it is preferable to store label images using an unsigned integer type

I checked the image and they all look like positive integers.

Thanks so much for your patience in answering all my questions.

bw

Peter


#8

Yes, I might need to decrease the verbosity of that warning. I recall the frustration caused at one point from some software providing a parcellation containing -1’s that was sending labelconvert haywire. Ideally if a type of image should never contain negative values, it should be stored using an unsigned type; but some image formats don’t actually support unsigned types, which makes that warning a bit harsh…