Dear Bruce,
I am uploading 3 example subjects processed both by v5.3 and v6.0 I referred to in the screenshots in my previous posts:
Subj 1 - large leak of white surface outside brain in v6.0, not present in v5.3. RAS coords -53,-1,75 Subj 2 - another measurement of identical subject - white surface is leaking at three spots dramatically outwards towards pial surface in v6.0. RAS coords -48,-2,64 Subj 3 - leak of white surface outside brain. Both v5.3 and v6.0 has error in white surface, but the error is much larger in v6.0. RAS coords 48,5,78
The v6.0 version is without removing -mprage. Removing -mprage in v6.0 caused only very small change in brain.mgz, the filtering is still much higher than in v5.3 and still causes the white matter surface leak.
The subjects are in files mri_normalize_v5.3.tar.gz and mri_normalize_v6.0.tar.gz.
I would very welcome any suggestions how to:
1. Prevent new white surface errors in v6.0 in subjects previously processed and edited by v5.3
2. How to make edits to modify white/pial surface location where wm.mgz editing is not sufficient. I tried workaround of directly editing 001.mgz as I discussed in thread http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html This is very time consuming. Better way is maybe to consider implementation of option for mris_make_surfaces similar to -overlay option for cases where wm.mgz voxels have value 1 as I discussed here: http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52730.html
Antonin
Hi Antonin
yes, the -mprage flag is likely to be at least one source of the differences. It makes the normalization more aggressive (since mprage trades higher CNR for lower SNR). I'm surprised removing it didn't help. I think that changing things like wlo could also help depending on how wrong the normalization is. Upload a subject and I'll take a look cheers Bruce
On Thu, 20 Apr 2017, Antonin Skoch wrote: Dear David,
thank you for the feedback; I saw your posts concerning edits and responded to them, see
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html
Just my case is not concerning poor response to the edits (which I believe is not systematically different between 5.3 and 6.0), my concern is that the data processed by v6.0 need much more wm.mgz edits than data processed by v5.3.
I think that my issue lies in -normalization2 step of recon-all. One of the difference between v5.3 and v6.0 is that by default the -mprage flag is passed to mri_normalize. This affects several parameters inside mri_normalize. I tried to reprocess my subjects using v6.0 with -no-mprage, but unfortunately this did not help.
See the example screenshots processed by v5.3 and v6.0 with -no-mprage:
The brain.mgz is still more aggressively filtered in v6.0 and there is much more prominent leak of ?h.white outside brain, which is probably caused by extended filtration which affects GM/WM contrast.
Looking at the source code of mri_normalize.c I did not comprehend where the basis of the issue lies, but in any case there are big differences in mri_normalize.c code between versions.
Antonin
From: David Semanek seman...@nyspi.columbia.edu To: Antonin Skoch a...@ikem.cz, "freesurfer@nmr.mgh.harvard.edu" freesurfer@nmr.mgh.harvard.edu Sent: 4/20/2017 3:41 PM Subject: Re: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast
Agreed. A validated protocol run on a very large group of subjects in 5.3 was attempted with similar data in 6.0 and not only was the longitudinal edit stream nearly non-functional for white matter edits, cross edit performance was disappointing.
I am currently waiting on a response to these potential issues before pursuing further work with 6.0.
Best,
David P. Semanek, HCISPP
Research Technician, Posner Lab
Division of Child and Adolescent Psychiatry
Columbia University Medical Center
New York State Psychiatric Institute
1051 Riverside Drive, Pardes Bldg. Rm. 2424
New York, NY 10032
PH: (646) 774-5885
IMPORTANT NOTICE: This e-mail is meant only for the use of the intended recipient. It may contain confidential information which is legally privileged or otherwise protected by law. If you received this e-mail in error or from someone who was not authorized to send it to you, you are strictly prohibited from reviewing, using, disseminating, distributing or copying the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.
From: Antonin Skoch a...@ikem.cz Date: Wednesday, April 19, 2017 at 5:23 PM To: freesurfer@nmr.mgh.harvard.edu Subject: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast
Dear experts,
I am sending just one more example to illustrate issue with white surface estimation in v6.0. See the attached screenshots: In v6.0 there seems to be insufficient contrast in brain.finalsurfs.mgz, so the white surface is leaking at three spots dramatically outwards towards pial surface. The white surface in v5.3 looks much more anatomically relevant in the same spot.
Could you please comment on how to avoid such issues in v.6.0?
Regards,
Antonin Skoch
Hi Antonin
Doug points out to me that you edited your copy of recon-all in 5.3, which makes it really hard for me to track down any differences. For sure your recon-all used cubic interpolation for conforming by default, which introduces pretty big differences right at the start that I expect explain the majority of the differences in wm positioning that you are seeing. I guess I would suggest trying 6.0 with cubic on (-cubic) and see if they become more similar
cheers Bruce
On Thu, 20 Apr 2017, Antonin Skoch wrote:
Dear Bruce, I am uploading 3 example subjects processed both by v5.3 and v6.0 I referred to in the screenshots in my previous posts: Subj 1 - large leak of white surface outside brain in v6.0, not present in v 5.3. RAS coords -53,-1,75 Subj 2 - another measurement of identical subject - white surface is leaking at three spots dramatically outwards towards pial surface in v6.0. RAS coords -48,-2,64 Subj 3 - leak of white surface outside brain. Both v5.3 and v6.0 has error i n white surface, but the error is much larger in v6.0. RAS coords 48,5,78 The v6.0 version is without removing -mprage. Removing -mprage in v6.0 cause d only very small change in brain.mgz, the filtering is still much higher th an in v5.3 and still causes the white matter surface leak. The subjects are in files mri_normalize_v5.3.tar.gz and mri_normalize_v6.0.t ar.gz. I would very welcome any suggestions how to:
- Prevent new white surface errors in v6.0 in subjects previously processed
and edited by v5.3 2. How to make edits to modify white/pial surface location where wm.mgz edit ing is not sufficient. I tried workaround of directly editing 001.mgz as I discussed in thread http ://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html This is very time consuming. Better way is maybe to consider implementation of option for mris_make_surfa ces similar to -overlay option for cases where wm.mgz voxels have value 1 as I discussed here: http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52730.html Antonin Hi Antonin
yes, the -mprage flag is likely to be at least one source of the differences. It makes the normalization more aggressive (since mprage trades higher CNR for lower SNR). I'm surprised removing it didn't help. I think that changing things like wlo could also help depending on how wrong the normalization is. Upload a subject and I'll take a look
cheers Bruce
On Thu, 20 Apr 2017, Antonin Skoch wrote:
Dear David,
thank you for the feedback; I saw your posts concerning edits and responded to them, see
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html
Just my case is not concerning poor response to the edits (which I believe is not systematically different between 5.3 and 6.0), my concern is that the data processed by v6.0 need much more wm.mgz edits than data processed by v5.3.
I think that my issue lies in -normalization2 step of recon-all. One of the difference between v5.3 and v6.0 is that by default the -mprage flag is passed to mri_normalize. This affects several parameters inside mri_normalize. I tried to reprocess my subjects using v6.0 with -no-mprage, but unfortunately this did not help.
See the example screenshots processed by v5.3 and v6.0 with -no-mprage:
The brain.mgz is still more aggressively filtered in v6.0 and there is much more prominent leak of ?h.white outside brain, which is probably caused by extended filtration which affects GM/WM contrast.
Looking at the source code of mri_normalize.c I did not comprehend where the basis of the issue lies, but in any case there are big differences in mri_normalize.c code between versions.
Antonin
From: David Semanek seman...@nyspi.columbia.edu To: Antonin Skoch a...@ikem.cz, "freesurfer@nmr.mgh.harvard.edu" freesurfer@nmr.mgh.harvard.edu Sent: 4/20/2017 3:41 PM Subject: Re: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast
Agreed. A validated protocol run on a very large group of subjects in 5.3 was attempted with similar data in 6.0 and not only was the longitudinal edit stream nearly non-functional for white matter edits, cross edit performance was disappointing. I am currently waiting on a response to these potential issues before pursuing further work with 6.0. Best, David P. Semanek, HCISPP Research Technician, Posner Lab Division of Child and Adolescent Psychiatry Columbia University Medical Center New York State Psychiatric Institute 1051 Riverside Drive, Pardes Bldg. Rm. 2424 New York, NY 10032 PH: (646) 774-5885IMPORTANT NOTICE: This e-mail is meant only for the use of the intended recipient. It may contain confidential information which is legally privileged or otherwise protected by law. If you received this e-mail in error or from someone who was not authorized to send it to you, you are strictly prohibited from reviewing, using, disseminating, distributing or copying the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.
From: Antonin Skoch a...@ikem.cz Date: Wednesday, April 19, 2017 at 5:23 PM To: freesurfer@nmr.mgh.harvard.edu Subject: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast
Dear experts,
I am sending just one more example to illustrate issue with white surface estimation in v6.0. See the attached screenshots: In v6.0 there seems to be insufficient contrast in brain.finalsurfs.mgz, so the white surface is leaking at three spots dramatically outwards towards pial surface. The white surface in v5.3 looks much more anatomically relevant in the same spot.
Could you please comment on how to avoid such issues in v.6.0?
Regards,
Antonin Skoch
Dear Bruce,
sorry for the confusion with xopts-use and recon-all editing.
I have checked the xopts-use and the reason of this is that I run the subject 1 and 2 as a part of batch job on large amount of subjects, where I rerun recon-all to anonymize them. Some of them had expert-options file with bbregister --init-header from the initial run (these were subjects where --init-fsl failed). I put -xopts-use to invocation of all subjects (even for them without expert-option file) to make my life easier. I did not put -cubic expert-options to any of my subjects.
Concerning editing of my 5.3 version of recon-all: My only modification in recon-all was -nsigma_above 8 for FLAIRpial and patch with .touch files recommended here: http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg41284.html
Otherwise my recon-all corresponds to the 5.3.0-patch version.
It seems that there was change in UseCubic wich 5.3.0-patch. Original recon-all from 5.3.0 has UseCubic=0, whereas recon-all from 5.3.0-patch has UseCubic=1:
https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0-patch/recon-all
In my v6.0 recon-all I have UseCubic=0.
I am surprised that mere interpolation could have such profound effect !
I will try your suggestions and let you know.
Antonin
From: Bruce Fischl fischl@nmr.mgh.harvard.edu To: Antonin Skoch ansk@ikem.cz Cc: freesurfer@nmr.mgh.harvard.edu Sent: 4/21/2017 1:00 AM Subject: Re: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast
Hi Antonin
Doug points out to me that you edited your copy of recon-all in 5.3, which makes it really hard for me to track down any differences. For sure your recon-all used cubic interpolation for conforming by default, which introduces pretty big differences right at the start that I expect explain the majority of the differences in wm positioning that you are seeing. I guess I would suggest trying 6.0 with cubic on (-cubic) and see if they become more similar
cheers Bruce
On Thu, 20 Apr 2017, Antonin Skoch wrote:
Dear Bruce, I am uploading 3 example subjects processed both by v5.3 and v6.0 I referred to in the screenshots in my previous posts: Subj 1 - large leak of white surface outside brain in v6.0, not present in v 5.3. RAS coords -53,-1,75 Subj 2 - another measurement of identical subject - white surface is leaking at three spots dramatically outwards towards pial surface in v6.0. RAS coords -48,-2,64 Subj 3 - leak of white surface outside brain. Both v5.3 and v6.0 has error i n white surface, but the error is much larger in v6.0. RAS coords 48,5,78 The v6.0 version is without removing -mprage. Removing -mprage in v6.0 cause d only very small change in brain.mgz, the filtering is still much higher th an in v5.3 and still causes the white matter surface leak. The subjects are in files mri_normalize_v5.3.tar.gz and mri_normalize_v6.0.t ar.gz. I would very welcome any suggestions how to:
- Prevent new white surface errors in v6.0 in subjects previously processed
and edited by v5.3 2. How to make edits to modify white/pial surface location where wm.mgz edit ing is not sufficient. I tried workaround of directly editing 001.mgz as I discussed in thread http ://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html This is very time consuming. Better way is maybe to consider implementation of option for mris_make_surfa ces similar to -overlay option for cases where wm.mgz voxels have value 1 as I discussed here: http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52730.html Antonin Hi Antonin
yes, the -mprage flag is likely to be at least one source of the differences. It makes the normalization more aggressive (since mprage trades higher CNR for lower SNR). I'm surprised removing it didn't help. I think that changing things like wlo could also help depending on how wrong the normalization is. Upload a subject and I'll take a look
cheers Bruce
On Thu, 20 Apr 2017, Antonin Skoch wrote:
Dear David,
thank you for the feedback; I saw your posts concerning edits and responded to them, see
http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html
Just my case is not concerning poor response to the edits (which I believe is not systematically different between 5.3 and 6.0), my concern is that the data processed by v6.0 need much more wm.mgz edits than data processed by v5.3.
I think that my issue lies in -normalization2 step of recon-all. One of the difference between v5.3 and v6.0 is that by default the -mprage flag is passed to mri_normalize. This affects several parameters inside mri_normalize. I tried to reprocess my subjects using v6.0 with -no-mprage, but unfortunately this did not help.
See the example screenshots processed by v5.3 and v6.0 with -no-mprage:
The brain.mgz is still more aggressively filtered in v6.0 and there is much more prominent leak of ?h.white outside brain, which is probably caused by extended filtration which affects GM/WM contrast.
Looking at the source code of mri_normalize.c I did not comprehend where the basis of the issue lies, but in any case there are big differences in mri_normalize.c code between versions.
Antonin
From: David Semanek seman...@nyspi.columbia.edu To: Antonin Skoch a...@ikem.cz, "freesurfer@nmr.mgh.harvard.edu" freesurfer@nmr.mgh.harvard.edu Sent: 4/20/2017 3:41 PM Subject: Re: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast
Agreed. A validated protocol run on a very large group of subjects in 5.3 was attempted with similar data in 6.0 and not only was the longitudinal edit stream nearly non-functional for white matter edits, cross edit performance was disappointing.
I am currently waiting on a response to these potential issues before pursuing further work with 6.0.
Best,
David P. Semanek, HCISPP
Research Technician, Posner Lab
Division of Child and Adolescent Psychiatry
Columbia University Medical Center
New York State Psychiatric Institute
1051 Riverside Drive, Pardes Bldg. Rm. 2424
New York, NY 10032
PH: (646) 774-5885
IMPORTANT NOTICE: This e-mail is meant only for the use of the intended recipient. It may contain confidential information which is legally privileged or otherwise protected by law. If you received this e-mail in error or from someone who was not authorized to send it to you, you are strictly prohibited from reviewing, using, disseminating, distributing or copying the e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.
From: Antonin Skoch a...@ikem.cz Date: Wednesday, April 19, 2017 at 5:23 PM To: freesurfer@nmr.mgh.harvard.edu Subject: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast
Dear experts,
I am sending just one more example to illustrate issue with white surface estimation in v6.0. See the attached screenshots: In v6.0 there seems to be insufficient contrast in brain.finalsurfs.mgz, so the white surface is leaking at three spots dramatically outwards towards pial surface. The white surface in v5.3 looks much more anatomically relevant in the same spot.
Could you please comment on how to avoid such issues in v.6.0?
Regards,
Antonin Skoch
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 Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Hi Antonin
it is a pretty significant difference, even visually, and it occurs right at the start of everything, so the differences propagate forward through recon-all. I only looked at subject 1, but it is a case where the intensities are ambiguous between gray and white and a slight increase creates a connection between brain and dura (which looks like white matter there) and messes everything up. I'm still running things, but I believe that turning on cubic removes this issue for at least this subject
cheers Bruce
On Fri, 21 Apr 2017, Antonin Skoch wrote:
Dear Bruce,
sorry for the confusion with xopts-use and recon-all editing.
I have checked the xopts-use and the reason of this is that I run the subject 1 and 2 as a part of batch job on large amount of subjects, where I rerun recon-all to anonymize them. Some of them had expert-options file with bbregister --init-header from the initial run (these were subjects where --init-fsl failed). I put -xopts-use to invocation of all subjects (even for them without expert-option file) to make my life easier. I did not put -cubic expert-options to any of my subjects.
Concerning editing of my 5.3 version of recon-all: My only modification in recon-all was -nsigma_above 8 for FLAIRpial and patch with .touch files recommended here: http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg41284.html
Otherwise my recon-all corresponds to the 5.3.0-patch version.
It seems that there was change in UseCubic wich 5.3.0-patch. Original recon-all from 5.3.0 has UseCubic=0, whereas recon-all from 5.3.0-patch has UseCubic=1:
https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0-patch/recon-al l
In my v6.0 recon-all I have UseCubic=0.
I am surprised that mere interpolation could have such profound effect !
I will try your suggestions and let you know.
Antonin
From: Bruce Fischl fischl@nmr.mgh.harvard.edu To: Antonin Skoch ansk@ikem.cz Cc: freesurfer@nmr.mgh.harvard.edu Sent: 4/21/2017 1:00 AM Subject: Re: [Freesurfer] Worse determination of ?h.white with v6.0 in comparison to v5.3 - worse GM/WM contrast
Hi Antonin Doug points out to me that you edited your copy of recon-all in 5.3, which makes it really hard for me to track down any differences. For sure your recon-all used cubic interpolation for conforming by default, which introduces pretty big differences right at the start that I expect explain the majority of the differences in wm positioning that you are seeing. I guess I would suggest trying 6.0 with cubic on (-cubic) and see if they become more similar cheers Bruce On Thu, 20 Apr 2017, Antonin Skoch wrote: > > Dear Bruce, > I am uploading 3 example subjects processed both by v5.3 and v6.0 I referred > to in the screenshots in my previous posts: > Subj 1 - large leak of white surface outside brain in v6.0, not present in v > 5.3. RAS coords -53,-1,75 > Subj 2 - another measurement of identical subject - white surface is leaking > at three spots dramatically outwards > towards pial surface in v6.0. RAS coords -48,-2,64 > Subj 3 - leak of white surface outside brain. Both v5.3 and v6.0 has error i > n white surface, but the error is much larger in v6.0. RAS coords 48,5,78 > The v6.0 version is without removing -mprage. Removing -mprage in v6.0 cause > d only very small change in brain.mgz, the filtering is still much higher th > an in v5.3 and still causes the white matter surface leak. > The subjects are in files mri_normalize_v5.3.tar.gz and mri_normalize_v6.0.t > ar.gz. > I would very welcome any suggestions how to: > 1. Prevent new white surface errors in v6.0 in subjects previously processed > and edited by v5.3 > 2. How to make edits to modify white/pial surface location where wm.mgz edit > ing is not sufficient. > I tried workaround of directly editing 001.mgz as I discussed in thread http > ://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html > This is very time consuming. > Better way is maybe to consider implementation of option for mris_make_surfa > ces similar to -overlay option for cases where wm.mgz voxels have value 1 as > I discussed here: > http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52730.html > Antonin > Hi Antonin > > yes, the -mprage flag is likely to be at least one source of the > differences. It makes the normalization more aggressive (since mprage trades > higher CNR for lower SNR). I'm surprised removing it didn't help. I think > that changing things like wlo could also help depending on how wrong the > normalization is. Upload a subject and I'll take a look > > cheers > Bruce > > > On Thu, 20 Apr 2017, Antonin Skoch wrote: > > Dear David, > > thank you for the feedback; I saw your posts concerning edits and responded > to them, see > > http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52549.html > > Just my case is not concerning poor response to the edits (which I believe > is not systematically different between 5.3 and 6.0), my concern is that the > data processed by v6.0 need much more wm.mgz edits than data processed by > v5.3. > > I think that my issue lies in -normalization2 step of recon-all. One of the > difference between v5.3 and v6.0 is that by default the -mprage flag is > passed to mri_normalize. This affects several parameters inside > mri_normalize. I tried to reprocess my subjects using v6.0 with -no-mprage, > but unfortunately this did not help. > > See the example screenshots processed by v5.3 and v6.0 with -no-mprage: > > The brain.mgz is still more aggressively filtered in v6.0 and there is much > more prominent leak of ?h.white outside brain, which is probably caused by > extended filtration which affects GM/WM contrast. > > Looking at the source code of mri_normalize.c I did not comprehend where the > basis of the issue lies, but in any case there are big differences in > mri_normalize.c code between versions. > > Antonin > > From: David Semanek <seman...@nyspi.columbia.edu> > To: Antonin Skoch <a...@ikem.cz>, "freesurfer@nmr.mgh.harvard.edu" > <freesurfer@nmr.mgh.harvard.edu> > Sent: 4/20/2017 3:41 PM > Subject: Re: [Freesurfer] Worse determination of ?h.white with v6.0 in > comparison to v5.3 - worse GM/WM contrast > > Agreed. A validated protocol run on a very large group of > subjects in 5.3 was attempted with similar data in 6.0 and not > only was the longitudinal edit stream nearly non-functional for > white matter edits, cross edit performance was disappointing. > > > > I am currently waiting on a response to these potential issues > before pursuing further work with 6.0. > > > > Best, > > > > David P. Semanek, HCISPP > > Research Technician, Posner Lab > > Division of Child and Adolescent Psychiatry > > Columbia University Medical Center > > New York State Psychiatric Institute > > 1051 Riverside Drive, Pardes Bldg. Rm. 2424 > > New York, NY 10032 > > PH: (646) 774-5885 > > > > IMPORTANT NOTICE: This e-mail is meant only for the use of the > intended recipient. It may contain confidential information which is > legally privileged or otherwise protected by law. If you received > this e-mail in error or from someone who was not authorized to send it > to you, you are strictly prohibited from reviewing, using, > disseminating, distributing or copying the e-mail. PLEASE NOTIFY US > IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS MESSAGE FROM > YOUR SYSTEM. Thank you for your cooperation. > > > > From: Antonin Skoch <a...@ikem.cz> > Date: Wednesday, April 19, 2017 at 5:23 PM > To: <freesurfer@nmr.mgh.harvard.edu> > Subject: [Freesurfer] Worse determination of ?h.white with v6.0 in > comparison to v5.3 - worse GM/WM contrast > > > > Dear experts, > > I am sending just one more example to illustrate issue with white > surface estimation in v6.0. See the attached screenshots: In v6.0 > there seems to be insufficient contrast in brain.finalsurfs.mgz, so > the white surface is leaking at three spots dramatically outwards > towards pial surface. The white surface in v5.3 looks much more > anatomically relevant in the same spot. > > Could you please comment on how to avoid such issues in v.6.0? > > Regards, > > Antonin Skoch > > > > > 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 Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
freesurfer@nmr.mgh.harvard.edu