Using the Brainnetome Atlas for Parcellation

Hi everyone!

I have a question regarding the usage of the Brainnetome Atlas in MRtrix. So far I have worked with the Desikan-Killiany and the Destrieux Atlas to create connectomes, which was fairly straightforward. However, with the BN Atlas I encountered a weird issue while preparing the atlas files for the connectome generation. I tried to follow the instructions from the BATMAN Tutorial (Appendix) but I keep running into an error.

I have the annotation files ready (lh.BN_atlas.annot and rh.BN_atlas.annot) and when I open them in freeview it all looks perfectly fine (node names are all present and based on BN atlas). So, I am trying to use the freesurfer command mri_aparc2aseg --old-ribbon -s my_subject --annot BN_atlas --o BN_atlas.mgz. Using the outcome file for tck2connectome gives me an error stating that basically all my nodes are missing. When I check the BN_atlas.mgz with freeview it seems like the node names are now based on the FreesurferColorLUT instead of the BN_atlas LUT. It appears as if the mri_aparc2_aseg command is messing it up, but I have no clue why. Using labelconvert make things even worse, removing all the nodes from the file.

Is there anyone who has used different atlases than Desikan or Destrieux who knows why this error occurs and what I could do about it? Thank you very much in advance!

1 Like

Hi @theNeuropsychologist,

I’m most definitely not experienced with FreeSurfer, and it’s entirely likely that there’s a better method than what I’m currently using. I succeeded in supporting the Brainnetome atlas in my own tool, using mris_ca_label, mri_label2vol and mri_ca_label; see code here. IIRC with this technique the appearance of the voxel-based cortical delineations is kind of “speckly” compared to *aseg.mgz, owing to the way that it generates intermediate surface layers and looks for their intersections with the voxel grid, so presumably somewhere in that software there’s a better approach than what I’m doing. But it at least works well enough for connectome construction, it just doesn’t look very nice.

Cheers
Rob

1 Like

Hi Rob,

thank you very much for your reply! I will try your approach and hopefully, I can make it work this way.

Best
Lars

Hi Rob,

So I just tried your approach and up until the “overlapping mask labels” part it, all worked out quite well. Indeed the outcome looks a bit “speckly” but for now that is absolutely fine I think. I just had some trouble understanding the code from line 2301 on. From what I understand, the first mrcalc command calculates the cortical overlap between the two hemispheres, the second mrcalc (line 2308) does the same for the subcortical areas and with the final mrcalc (line 2319) the three .mgz files (lh, rh, subcortex) are merged and output as “aparc.BN_Atlas+aseg.mgz”, taking into account potential overlap. Is this (somehow) correct, or am I completely on the wrong track here?

Also, if I am just interested in the cortical parcellation (BN Atlas 210), may I just leave out the second mrcalc command (line 2308)?

Thank you very much for your help! It is the first time, since a few days, that I finally make some progress with the BN Atlas.

Best regards
Lars

Hi Rob,

(I figured it all out and it worked like a charm! I can finally use the Brainnetome Atlas for my analysis. Thank you so much!)

edit:
Unfortunately, I encountered another error. The final “aparc.BN_Atlas+aseg.mgz” file looks good in freeview but I am not able to use mrconvert to convert it to the .mif format. It gives me a memory allocation error on both my macbook and my linux workstation (killed: 9 on macbook / terminate called after throwing an instance of ‘std::bad_alloc’ on Linux). Is this something you have encountered before Rob? Do you have any idea what I could do about it? Maybe re-do the whole analysis?

Best
Lars

Hi Lars,

My initial hypothesis was that you had encountered this issue, for which I have posted a code fix but that fix has not yet been included in a tag release. If that were the case, the problem is specifically the creation of an MGH / MGZ file from MRtrix3 that contains the new FreeSurfer colour table format, and so there’s various ways that you could avoid that specific combination of circumstances. But if that were the case, I would expect freeview to yield a memory error just as mrconvert does. So if it is true that FreeSurfer commands can read the file but MRtrix3 can’t, there’s a chance it might be some unrelated issue. You could also check to see if freeview opens the image but mri_info crashes, which woud suggest that freeview simply isn’t reading the corrupt data.

Cheers
Rob

1 Like

Thank you very much for your reply! I will try this out and see whether I can make it work.

Best,
Lars