External Email - Use Caution So I believe I posted something like this a while ago. My observation is that edits removing voxel from the brain mask does not always remove inclusions for the cerebellum. It seem to work for the rest of the brain. I find this to be a common occurrence.
On Thu, Jun 16, 2022, 7:02 PM Keefe, Sarah <sarahke...@wustl.edu> wrote: > External Email - Use Caution > > Hi FreeSurfer Team, > > Our group is in the process of switching to Freesurfer 7.1.1 from 5.3. We > have been taking advantage of Freesurfer 7's aseg.presurf volume to add in > correction of unlabeled cerebellum to our standard edit checklist rather > than our previous workflow of having a Freesurfer fail our quality control > standards and be excluded from analysis if too much cerebellum is unlabeled > on aparc+aseg segmentation. We're consistently running into an issue when > we have a Freesurfer that requires corrections to both brainmask.mgz and > aseg.presurf.mgz. > > An example of when this happens is if the Freesurfer output labels dura as > cerebellum cortex on aparc+aseg (which requires erasing the included dura > from brainmask.mgz) and the output also has an exclusion of cerebellum from > the aparc+aseg segmentation (which requires correctly labeling the excluded > voxels on aseg.presurf.mgz). We have found that if we edit both the > aseg.presurf.mgz and brainmask.mgz volumes and then rerun recon-all with > both, the cerebellum exclusion segmentation fix does not "take" completely > and individual voxels in the cerebellum that were corrected in the edited > volume are still left unlabeled. We have 100% confirmed that our labeling > edits to aseg.presurf are correct and complete before this happens. To > reduce confusion and attempt some consistency across our editing team, we > relaunch recon-all with the same flags every time: -autorecon2 -autorecon3 > -qcache > > To work around this issue, we implemented a workflow where editors will > make brainmask.mgz corrections, then rerun recon-all (rerun 1), and then > make aseg.presurf corrections, and rerun recon-all again (rerun 2). This > seems to work although it is frustrating since we are trying to minimize > the number of reruns of recon-all and we typically tell people to stop and > make a final quality control decision after 3 reruns. > > What we are finding is if another issue pops up on brainmask.mgz after > rerun 2 that then needs corrections (e.g. other areas of dura are > incorrectly included in the pial surface or aparc+aseg cerebellum labeling > but weren't included before so weren't erased) then after making those > edits and rerunning recon-all, the previously corrected aparc+aseg > cerebellum segmentation shows "missing" unlabeled voxels, same as if we had > run recon-all once with both aseg.presurf and brainmask volumes edited. > > The attached image shows an example of our process and the issues we're > seeing. The end result (F) also happens if we edit both brainmask.mgz and > aseg.presurf.mgz edits and rerun recon-all once with both included. > > screenshot A is the aparc+aseg.mgz of the original recon-all output (run > 0) where cerebellum is unlabeled (red arrows). There is also visible dura > labeled as cerebellum that we need to fix (yellow arrow). > > screenshot B is the aparc+aseg.mgz of the recon-all rerun output after > just the brainmask.mgz was edited and saved (run 1). Additional > segmentation issues have appeared in addition to the original ones (red > arrows). This screenshot also shows an example of the type of edit we are > doing to brainmask - we have erased dura from brainmask.mgz to correct the > cerebellum cortex labeling and the edit worked (yellow arrow). > > screenshot C is the aseg.presurf.mgz volume after run 1 before editing for > the cerebellum exclusion issue. > > screenshot D is our edited and saved aseg.presurf volume BEFORE we run the > second recon-all relaunch. We have corrected the labeling (green arrows). > > screenshot E is the aparc+aseg.mgz after a recon-all relaunch with only > the new edit to aseg.presurf. (run 2). The cerebellum exclusion error has > been fixed in aparc+aseg (green arrows). This run 2 of recon-all caused > more issues to show up that required more brainmask.mgz edits. > > screenshot F is what we see if we edit brainmask.mgz again and rerun > recon-all (run 3). The output of run 3 shows missing voxels in the > cerebellum where we had fixed them before. Unlabeled voxels appear > throughout the areas that were edited in C and were corrected in D. > > We try to minimize edits and maintain consistency across our editing team > by asking people to only erase dura from brainmask.mgz that has been > erroneously included in the cerebellum labelling or in the pial surface > (rather than other dura that also happens to be included in the > brainmask.mgz). We also ask people to relaunch recon-all with the same > -autorecon2 -autorecon3 -qcache flags each time for consistency across our > data. We really really want to be able to cut down the number of times we > are relaunching recon-all but we are unable to fix both these issues at > once (it ends up like screenshot F after 1 rerun). > > Is there a way to prevent the aseg.presurf.mgz edits from "undoing" voxels > when brainmask.mgz edits are included or done after aseg.presurf? Any > assistance or alternative techniques for solving this would be much > appreciated. > > We are primarily using the Freesurfer 7.1.1 Docker container but I have > also been able to replicate this issue on CentOS 8 and Ubuntu 20.04 with > build stamp freesurfer-linux-centos7_x86_64-7.1.1-20200723-8b40551. > > Thanks so much, > Sarah > > > ------------------------------ > > The materials in this message are private and may contain Protected > Healthcare Information or other information of a sensitive nature. If you > are not the intended recipient, be advised that any unauthorized use, > disclosure, copying or the taking of any action in reliance on the contents > of this information is strictly prohibited. If you have received this email > in error, please immediately notify the sender via telephone or return mail. > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu > https://secure-web.cisco.com/1anrAOugOYQl4yaJ98cqK-1jCSdsbQW6CNv6xSXyKRurMDgDUBdr3d2PbfDqI7PmwZAIMukJ0sEHZXHi_1Agu0h10Prks2SaPyr6gPmILBZk5NtCMlB3sUuZk9nUje3BEy7o4AIKdOKHZZ6hPeb2-y071aT3boQCMsoVXIfKJ8f7lgmxduBur3Aiz8iUI1BwZIcfQQzFJSVqheeUPE5B0dYt4lwlV7LACiTCxj4j8wjti6M8JxS8MGdtGug7ZIFLtMxR3ENwGPRauDee4wwe27gmly5ddOrlhCJ8PlppIxvUqda04AVeGslyY2bjMH9uX/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer > The information in this e-mail is intended only for the person to whom it > is addressed. If you believe this e-mail was sent to you in error and the > e-mail contains patient information, please contact the Mass General > Brigham Compliance HelpLine at > https://secure-web.cisco.com/1fNeVYH4oi-ocQVT7J54Rn_Eop7LvWPYKNHNd5tbxg8DPGHz2-mAc7Eji3AbwZw3zsCP9wmzYwN77xNLjplrre1p7fcDoYSQr6qanQVLlDbeYx37Atkj1zFW-4QduoI5Fo_9XlSWEUlDAZsm_RR6HiVA0dPttZKIt6OXQsJWhfTFgeZb7-dfsOrC7hHSVi43lh1VfIvPuV__mrj0-f8WRQRwj7piyJlMU_--oUzDmgKftxws2tgOtZYFay8oBiNV4m8rzvSORvFLTqFLRRLNjRQcS2FFmjQCT8IhlTqfSXKIyL5QnHi-yLDD8-AAX_vVU/https%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline > < > https://secure-web.cisco.com/1fNeVYH4oi-ocQVT7J54Rn_Eop7LvWPYKNHNd5tbxg8DPGHz2-mAc7Eji3AbwZw3zsCP9wmzYwN77xNLjplrre1p7fcDoYSQr6qanQVLlDbeYx37Atkj1zFW-4QduoI5Fo_9XlSWEUlDAZsm_RR6HiVA0dPttZKIt6OXQsJWhfTFgeZb7-dfsOrC7hHSVi43lh1VfIvPuV__mrj0-f8WRQRwj7piyJlMU_--oUzDmgKftxws2tgOtZYFay8oBiNV4m8rzvSORvFLTqFLRRLNjRQcS2FFmjQCT8IhlTqfSXKIyL5QnHi-yLDD8-AAX_vVU/https%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline> > . > Please note that this e-mail is not secure (encrypted). If you do not > wish to continue communication over unencrypted e-mail, please notify the > sender of this message immediately. Continuing to send or respond to > e-mail after receiving this message means you understand and accept this > risk and wish to continue to communicate over unencrypted e-mail. >
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline <https://www.massgeneralbrigham.org/complianceline> . Please note that this e-mail is not secure (encrypted). If you do not wish to continue communication over unencrypted e-mail, please notify the sender of this message immediately. Continuing to send or respond to e-mail after receiving this message means you understand and accept this risk and wish to continue to communicate over unencrypted e-mail.
