External Email - Use Caution Correction, not cerebellum inclusions but dural inclusion being labeled as cerebellum. When editing I am setting these dural inclusion as 0 in the brainmask, i am using -autorecon2 flag, and I never edit more then one image before rerunning recon-all.
On Wed, Jun 22, 2022, 9:23 AM Aaron Tanenbaum <aaron.b.tanenb...@gmail.com> wrote: > 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/1imEjZoGTiNQP8X1YNhLdRp4XF5kcQJkDllSgMFNUyecf2sV32aaSqnYWJF_KJDyZdZS80tmhtflb2tM1ttRej6Fs-y5xHOjXAAnd-R9fPJvLiatPZSJwxzjHTTlxuP7t4n82gWLQrkyAELFEv0VPUTdBqWPgHAYAnGP8q3xwrR6lmhFeIOSbPwAfHN1m4OL-7fCf3bYDLv87jsFbaEboYhMlCqebLiEAqW_LUbVC6V_B373IfwAFUuOnkgT-XQDCyfAjhr9qMNGZAHZvybGsHyeRBI_5vilhjEVuLaPK5lFsVrKN7zGhvGvXX-2mChJEHTc2exhsSaT2SL_Ds1oRvQ/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/10o6KPWqsygkScvGA98eiq0EQMEzTBYTWE8_kx-loHjAAA8WXUMEwUEkK6cIX9GRjTFc4Rs8f-Mng504PlVyVWC3t6Ek5CDfdan9RgKD4QyOGai0pMyoxcwNAKO6Qd4gkTsNb4-7okLF-NPHoHVnuoEOue7HV0vTRY6zf88Ug6moVtxTwT9H-g50ep42nb5sE4GltRrfwpKyanD1Q10c1FWCuRfB4iTqMurPwgW_O18i9eSCdCHuf3cvR0uGTC__GqYc05oOl_KsYkESxTcUBHYapUxrBHdQktTnC7D6U2lbNfuwpBVRQeMpKE50_8pzp_EF_oLWZn06fo-qtQZ6bNA/https%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline >> < >> https://secure-web.cisco.com/10o6KPWqsygkScvGA98eiq0EQMEzTBYTWE8_kx-loHjAAA8WXUMEwUEkK6cIX9GRjTFc4Rs8f-Mng504PlVyVWC3t6Ek5CDfdan9RgKD4QyOGai0pMyoxcwNAKO6Qd4gkTsNb4-7okLF-NPHoHVnuoEOue7HV0vTRY6zf88Ug6moVtxTwT9H-g50ep42nb5sE4GltRrfwpKyanD1Q10c1FWCuRfB4iTqMurPwgW_O18i9eSCdCHuf3cvR0uGTC__GqYc05oOl_KsYkESxTcUBHYapUxrBHdQktTnC7D6U2lbNfuwpBVRQeMpKE50_8pzp_EF_oLWZn06fo-qtQZ6bNA/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.
