If this is not something you have to do a lot of, you can put a
repositioning point. See the release notes.
On 2/21/2022 1:10 PM, Fischl, Bruce wrote:
Hi Edan
Control points might be helpful in both cases, but you are right it is
more often the case when the wm is too dark. Another thing you can try
is using expert options for mri_segment to constrain the intensity
ranges of wm/gm. Or you could try using the samseg stream (someone
else will have to help you with this, but it might well do better for
your acquisitions)
Cheers
Bruce
*From:* Edan Daniel <ed...@princeton.edu>
*Sent:* Monday, February 21, 2022 11:14 AM
*To:* Fischl, Bruce <bfis...@mgh.harvard.edu>
*Cc:* Freesurfer support list <freesurfer@nmr.mgh.harvard.edu>
*Subject:* Re: [Freesurfer] autorecon2-wm not reflecting edits in
white matter segmentation (7.1.1, 7.2.0)
* External Email - Use Caution *
Thanks Bruce!
This looks like a helpful solution for the places where the wm is not
identified- we will definitely try it!
We have one other type of issue which is more prevalent, that I was
not sure if control points will be able to help with (we have not
worked with control points before so sorry if this is a misinformed
question)
The main issue we're facing is that the final segmentation we get is
too aggressive, that is, in many places too *many* voxels are
categorized as wm and thus we have lower ability to characterize
properties of the gray matter in the occipital cortex. What we usually
do is clean the wm segmentation to make it less bulky, but now these
edits are not being incorporated in the final segmentation. We are
very confused by this because this type of edits were easily
incorporated in v6, but not with v7.
From my understanding- the control points would be helpful in the
opposite case- where not enough voxels are recognized as wm (such as
in the rightmost part of the attached image)- but not much in the rest
of the image where we can see that the magenta borders (x.orig.nofix)
are 'tighter' around the wm when compared to the borders after running
through recon -wm (teal, x.white.preaparc).
Is there a way to leverage the control points for this cause, or is
there something else we can try to make the recon -wm less stubborn
and accept our manual edits?
For reference, the full command we run is as follows:
recon-all -autorecon2-wm -autorecon3 -subjid '
freesurferfoldername ' -cc-crs ' num2str(corpus_point)
Attaching another image - please let me know if the visibility here is
better or if you'd like to see a different visualization.
Many thanks!!!!
Edan @ PrincetonBrainDevLab
On Fri, Feb 18, 2022 at 9:53 AM Fischl, Bruce
<bfis...@mgh.harvard.edu> wrote:
Hi Edan
It’s hard for me to see what’s going on in those images. What is
the intensity of the white matter in the middle of the occipital
strands in the brain.mgz and the brain.finalsurfs.mgz? If it is
significantly lower than 110 you probably want some control points
in the occipital lobe.
Cheers
Bruce
*From:* Edan Daniel <ed...@princeton.edu>
*Sent:* Friday, February 18, 2022 12:15 AM
*To:* Freesurfer support list <freesurfer@nmr.mgh.harvard.edu>;
Fischl, Bruce <bfis...@mgh.harvard.edu>
*Subject:* Re: [Freesurfer] autorecon2-wm not reflecting edits in
white matter segmentation (7.1.1, 7.2.0)
* External Email - Use Caution *
Hi Bruce!
We are focusing on the occipital lobe where the white matter
boundary is often too far into the gray matter, and we need those
voxels to record visual signals.
Attaching a few images for reference - notice how much 'thicker'
the wm segmentation is in the white.preaparc vs the lh.orig.nofix.
wm edits of this sort were accepted when we were using the same
pipeline with v6 (separate datasets), but now with v7
our edits get 're-corrected' and overwritten. We'd be happy to
provide more information or images.
Many thanks!!!
Edan @ PrincetonBrainDevLab
On Thu, Feb 17, 2022 at 7:01 PM Fischl, Bruce
<bfis...@mgh.harvard.edu> wrote:
Hi Edan
Sometimes control points can be more effective than editing
the wm, particularly if the intensities in that region are not
what we expect (like if the wm and gm are darker than what we
try to set them to). Can you post an image or two?
Cheers
Bruce
*From:* freesurfer-boun...@nmr.mgh.harvard.edu
<freesurfer-boun...@nmr.mgh.harvard.edu> *On Behalf Of *Edan
Daniel
*Sent:* Thursday, February 17, 2022 6:51 PM
*To:* Freesurfer support list <freesurfer@nmr.mgh.harvard.edu>
*Subject:* Re: [Freesurfer] autorecon2-wm not reflecting edits
in white matter segmentation (7.1.1, 7.2.0)
* External Email - Use Caution *
* Different data, same pipeline. In v6 our changes were
included in the final white surface segmentation, whereas
in v7 they are overwritten during the placement 'refining'.
* ?h.orig.nofix and ?h.orig DO reflect edits (?h.orig to
some extent). white.preaparc does NOT.
* We noticed that the placement is very stubborn and we were
not able to overcome this. Methods like manually editing
the wm surface worked well with v6 and do not work now
with v7. We have also tried editing the filled.mgz with
v7.2 following the new tutorial, and that did not work
either.
Is there any way we can overcome this stubbornness?
Many thanks!
Edan @ Princeton BrainDevLab
On Thu, Feb 17, 2022 at 6:07 PM Douglas N. Greve
<dgr...@mgh.harvard.edu> wrote:
The edits you are making only change the initial surface;
the surface placement then refines the placement.
Sometimes the surface placement can be quite stubborn. If
this is the case, the ?h.orig.nofix and ?h.orig will
reflect your edits (nofix exactly; ?h.orig to some
extent). Also check the the white.preaparc is where the
problem starts.
When you say that v6 did better, do you mean on this same
data or on different data? The surface placement has not
changed that much since v6.
On 2/14/2022 12:50 PM, Edan Daniel wrote:
* External Email - Use Caution *
We have been having issues with recreating the final
surfaces after editing the white matter segmentation,
which used to work smoothly in version 6.
After running a subject through recon-all (version
7.1.1 *without* the parallel flag) and then editing
the white matter, we run the following command (w v7.1.1):
recon-all -autorecon2-wm -autorecon3 -subjid '
freesurferfoldername ' -cc-crs ' num2str(corpus_point)
The ribbon file and surfaces do update *very slightly*
but it’s largely ignoring our (sometimes large) edits.
This pipeline worked well for us in version 6- do you
have any idea what might be going on?
Would love to hear your thoughts about this.
Many thanks!!
Edan, Braindevlab@Princeton
_______________________________________________
Freesurfer mailing list
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/1BhcjfvnDAXHKeDR6R-iodPMLY3xi6xzTIkDcLTzdfO3AL026S0Y3nNiwNsk_Rhlx_6JzCATRItAPsiC_YL1qTPC76JQ1MNnw3UFSezKkrQcBMfyG1DRPHx23o0SxD83e-UdoqRq6N_xTPo7NheFjY7DCWEVDO0VG4JQcj_B6gRwgTjcEusrZjCc7AIQLTBCPjUGmV7iAA6k3S4pAbv0fOyoEPiRWC2ZgYRUgdQU37hKnQcsQQh0NXPeMNjg9XNO503u9KpbREhWN6C_FpIcwAg0QwUJZtmVUfCQCbYUiXIzPMh5ccArQBCnw4ESKv_GujZUYT0Xdb3SffsHy_AhtuA/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer>
_______________________________________________
Freesurfer mailing list
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/1BhcjfvnDAXHKeDR6R-iodPMLY3xi6xzTIkDcLTzdfO3AL026S0Y3nNiwNsk_Rhlx_6JzCATRItAPsiC_YL1qTPC76JQ1MNnw3UFSezKkrQcBMfyG1DRPHx23o0SxD83e-UdoqRq6N_xTPo7NheFjY7DCWEVDO0VG4JQcj_B6gRwgTjcEusrZjCc7AIQLTBCPjUGmV7iAA6k3S4pAbv0fOyoEPiRWC2ZgYRUgdQU37hKnQcsQQh0NXPeMNjg9XNO503u9KpbREhWN6C_FpIcwAg0QwUJZtmVUfCQCbYUiXIzPMh5ccArQBCnw4ESKv_GujZUYT0Xdb3SffsHy_AhtuA/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer>
_______________________________________________
Freesurfer mailing list
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/12WGi9fwMNRKoc7g0UsFngq4QzxkPkp8uUBbbPuKzCH_q-TezGLWNd9gLzSp5bA5xyVBH4b49Ud7EB5J4_56yDSUeCG8y4c9zwEkJDUAc0Twj6u13EwndIb9BDN6wtlLMFHjG8bvBBhNl4Eku3J-b3JAibe2gc0BJQdXG3SDNjvzjTedpGREZ5R1OxhDqNatpoOWUkC7c7gNubVq8xP8-ifLLMnnaz-Y8YMsLkKNy6MZTu8U3DuMberr-t84pfbtBdl4XlvA_HRz0s2rMYnsl2DHweu8kDVysoXaKUBeUYf9RBeRHtRniA7Bv98iG7P9a/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer>
_______________________________________________
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
