Frm an automated standpoint, there is not much more to do. That area may
be part of the medial wall anyway. If you want to fix it manually, you
will have to
cp brain.finalsurfs.mgz brain.finalsurfs.manedit.mgz
Then edit the manedit in freeview to fill in those regions with 255
Then rerun recon-all -s subject -autorecon-pial ( this will do white and
pial)
On 3/27/2023 6:32 PM, Keefe, Sarah wrote:
External Email - Use Caution
Thank you! That does describe the problem. I tested that out and it
just completed and unfortunately that adjustment didn't change things
significantly from the original run. A screenshot is attached. I made
very very VERY sure that the recon-all log for the right side
screenshot did really incorporate the xopts file, and that the
WhitePreAparc call had that flag included correctly. The output on the
right side of this screenshot is 100% definitely using the custom
xopts file and in the recon-all.log it correctly added the
--rip-bg-no-annot flag to WhitePreAparc. Any chance you have other
suggestions in this vein?
Happy to send these output subject directories if needed.
Thanks again,
Sarah
------------------------------------------------------------------------
*From:* freesurfer-boun...@nmr.mgh.harvard.edu
<freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Douglas N. Greve
<dgr...@mgh.harvard.edu>
*Sent:* Monday, March 27, 2023 10:06 AM
*To:* freesurfer@nmr.mgh.harvard.edu <freesurfer@nmr.mgh.harvard.edu>
*Subject:* Re: [Freesurfer] White matter exclusions occurring in
v7.3.2 but not v5.3
** External Email - Caution **
Does this describe the problem?
*MailScanner has detected a possible fraud attempt from
"secure-web.cisco.com" claiming to be*
https://surfer.nmr.mgh.harvard.edu/fswiki/ReleaseNotes
<https://secure-web.cisco.com/1l-IDmQ2XgFbr_hrqvkMaCbn3jZ7ogYL3PZ-zetLeQW1VkhgTXzNy6uFQMYmPSSa6WPiAj8iAzrqXNCrhhQztHqeGcwhlf8kMUYbByOivngTgYzBhmxZ7FMkiH9RwuSHPefwTJpwglephcndpB0BoIS12wvsviRt_wLPP1duX6dAh4qI1uAK5jptvKtPHxjXxMAiIh7NLdXI04R0ihioJpBU1KZEcRB4JY_LgnNQ-pAnyvXB1UlIrs4HcQL-pn-Dz3JMe285YK127i-L52ZPXJss11VorXBQuGv-dzoi2mG1-e0RuV8bZ0ePWIZs6V6vY3iryTMaaeEomnYQdgHXg8Q/https%3A%2F%2Fnam10.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fsurfer.nmr.mgh.harvard.edu%252Ffswiki%252FReleaseNotes%26data%3D05%257C01%257Csarahkeefe%2540wustl.edu%257C6e0aa60ed1ca49477c1608db2ed4ecf0%257C4ccca3b571cd4e6d974b4d9beb96c6d6%257C0%257C0%257C638155264274677619%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3D8bsYLWFStlXfF8zaBF52GG%252F59T68ntmB%252B2yvF77sHXA%253D%26reserved%3D0>
Bug fix: improve surface placement in inferior frontal area near
putamen. There are some cases where the white surface is not placed
well in these areas because of the close proximity of putamen to
cortex; it is probably the case that the surface is not well-defined
in this region anyway, but the placement can be improved by creating
an expert options file with the line "WhitePreAparc --rip-bg-no-annot"
Let me know if that fixes the problem
On 3/22/2023 5:00 PM, Keefe, Sarah wrote:
External Email - Use Caution
Hi FreeSurfer Team,
Our group is working on reprocessing scans that we originally
processed (performed quality control and edited where necessary) with
FreeSurfer 5.3 with the HCP patch. We are aiming to reprocess
everything with FreeSurfer version 7.3.2. So far when checking and
editing FreeSurfer 7 outputs we're regularly seeing areas of brain
that should be included within the white matter surface but are not,
particularly in the accumbens and orbitofrontal areas. The areas are
of lower intensity within the scans, but FreeSurfer 5.3 is able to
handle these areas accurately - we don't see these issues in our runs
on the same scan files done in FreeSurfer 5.3.
I've attached a screenshot of the Freesurfer output of each version
side by side on one of the slices where the exclusion is happening.
We're seeing this on maybe 1 in 10 Freesurfer 7 scans. All did fine
in 5.3. We're finding that the problem is not limited to certain
scanners - one of these examples is from a Biograph PETMR scan and
the other is from a Prisma.
Is there a recommended flag or flags we could use with Freesurfer 7
recon-all that might get us closer to the way 5.3 handles this?
The Freesurfer 5.3 parameters we originally used were:
-all -qcache -hippo-subfields -nocubic -mprage
The Freesurfer 7.3.2 parameters we are using now are:
-all -qcache
I have the recon-all outputs of both versions and the original scan
available and can send them via FTP if that would be helpful.
Other notes: Running with the -mprage flag added to the Freesurfer
7.3.2 recon-all launch was not different from the FS 7.3.2 recon-all
launch without the flag but I can send that output along as well if
it would be useful. Also, these examples are done in 7.3.2 but we've
also run into this issue with 7.1.1.
Really appreciate any assistance you can provide, as trying to figure
this out has been delaying our processing a bit.
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 <mailto:Freesurfer@nmr.mgh.harvard.edu>
*MailScanner has detected a possible fraud attempt from
"secure-web.cisco.com" claiming to be*
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer <https://secure-web.cisco.com/1aZLPk8I54TnrtsEDa9DfjuK-p9k-CGuHxZeyYXptL5gLs0fByGkfNSpB1iBmS0no_SGYtMZ8CQzmTHlPSuW5j1324X3KuaJ7n3nyVsOAIkkCupIij6JxzduU2BMiD8_lRQM1agLCeEa_Q0RvRPuhaX5qBR7sAhwFaNQcQP0rGMHqNZsBcDdD4Eo3KLjg4hT-yHc40PYkVGfBX3maLlX9gIr89QOk0nlaXZvoJcy8ky-6vTF-w3GlpQyMxtKM9f-ds_hLXIaNPsBY3Er_v0DY-cPvE9IaWP_ukfXryyYDalUceJAwNCL731qHKrWfRCVVjUCoqZYiiL8GDT5zYW1IPw/https%3A%2F%2Fnam10.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fmail.nmr.mgh.harvard.edu%252Fmailman%252Flistinfo%252Ffreesurfer%26data%3D05%257C01%257Csarahkeefe%2540wustl.edu%257C6e0aa60ed1ca49477c1608db2ed4ecf0%257C4ccca3b571cd4e6d974b4d9beb96c6d6%257C0%257C0%257C638155264274677619%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3DAsdBFd%252FWIEi%252B3vOudKifF9aoMesUvRGrDtt8RKXu7z4%253D%26reserved%3D0>
------------------------------------------------------------------------
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://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
_______________________________________________
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.
