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!
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.
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.
(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?
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.