Dear Bruce and Freesurfer Experts,
Thanks for the quick answer, Bruce, to previous post.
As I work my way through all the checks on output I had a couple of other quick questions
1) I noticed by skull-stripping was poor (too aggerssive at the back of the brain with part of the occipital lobe and a small part of cerebellum). I therefore tried a number of suggestions from the tutorials including using -wsthresh 35 and -no-wsgcaatlas - this worked well but could someone explain why the lack of atlas use improves things ?
2) I also tried to improve skull stripping using the talairach_with_skull_2.lta option but I did not have this file despite recon-all -all having run fine the first time around with no errors/problems reported - should this concern me ?
3) I am using Centos 64 on a Linux box with 4 cores and 12 GB of RAM - how many instances of recon-all could I have running at the same time with no problems
Thank you.
Mo
On Thu, Nov 24, 2011 at 4:01 PM, Bruce Fischl fischl@nmr.mgh.harvard.eduwrote:
Hi Mo,
that's not a problem. We have different normalizations for different pieces of the recon. For subcortical we use the norm.mgz, which should *not* be eroding borders of thalamus, pallidum, etc.... The brain*.mgz are for cortex, where we don't care about those borders.
cheers Bruce
On Thu, 24 Nov 2011, Mahinda Yogarajah wrote:
Dear Experts,
I am a beginner to the use of Freesurfer and having just installed version 5.1.0 (Centos 64bit) I have been going through the processing pipeline with one of our own datasets (3T GE Excite II scanner - coronal T1-weighted volumetric acquisition sequence with 1.1-mm thick slices). recon-all works fine and I have been looking at the outputs.
I have a question regarding the subcortical segmentation especially around the basal ganglia - during the intensity normalisation it appears to have assigned similar high (110) voxel values to parts of the internal capsule, pallidum and thalamus (pic1- brainmask.mgz), though the actual segmentation (pic2-aseg) looks reasonable when compared with the native image (pic3-raw T1) (though I appreciate one is normalised and the other is not). Should I be worried about this (and if so how can I correct ?) or is this intensity normalisation used only in the surface stream with a different intensity normalisation used in the volume stream ? Or ... is it used in the volume stream but the other parts of the model (eg priors from atlas etc) compensate in some way.
Thanks.
Mo
PS I can post screen
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/**compliancelinehttp://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.
1. A linear transform isn't always good enough to describe brain/skull variability. It helps more often than it hurts, but sometimes it does worse.
2-3. I'll leave these for Nick except to say I think 3g/recon should be fine and you might be able to get away with a bit less. So 4 would be safe, but you might be able to squeeze in 5 or 6 (although they will of course run slower with only 4 cores)
cheers Bruce
On Sun, 27 Nov 2011, Mahinda Yogarajah wrote:
Dear Bruce and Freesurfer Experts,
Thanks for the quick answer, Bruce, to previous post.
As I work my way through all the checks on output I had a couple of other quick questions
- I noticed by skull-stripping was poor (too aggerssive at the back of the
brain with part of the occipital lobe and a small part of cerebellum). I therefore tried a number of suggestions from the tutorials including using -wsthresh 35 and -no-wsgcaatlas - this worked well but could someone explain why the lack of atlas use improves things ?
- I also tried to improve skull stripping using the
talairach_with_skull_2.lta option but I did not have this file despite recon-all -all having run fine the first time around with no errors/problems reported - should this concern me ?
- I am using Centos 64 on a Linux box with 4 cores and 12 GB of RAM - how
many instances of recon-all could I have running at the same time with no problems
Thank you.
Mo
On Thu, Nov 24, 2011 at 4:01 PM, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: Hi Mo,
that's not a problem. We have different normalizations for different pieces of the recon. For subcortical we use the norm.mgz, which should *not* be eroding borders of thalamus, pallidum, etc.... The brain*.mgz are for cortex, where we don't care about those borders. cheers BruceOn Thu, 24 Nov 2011, Mahinda Yogarajah wrote:
Dear Experts, I am a beginner to the use of Freesurfer and having just installed version 5.1.0 (Centos 64bit) I have been going through the processing pipeline with one of our own datasets (3T GE Excite II scanner - coronal T1-weighted volumetric acquisition sequence with 1.1-mm thick slices). recon-all works fine and I have been looking at the outputs. I have a question regarding the subcortical segmentation especially around the basal ganglia - during the intensity normalisation it appears to have assigned similar high (110) voxel values to parts of the internal capsule, pallidum and thalamus (pic1- brainmask.mgz), though the actual segmentation (pic2-aseg) looks reasonable when compared with the native image (pic3-raw T1) (though I appreciate one is normalised and the other is not). Should I be worried about this (and if so how can I correct ?) or is this intensity normalisation used only in the surface stream with a different intensity normalisation used in the volume stream ? Or ... is it used in the volume stream but the other parts of the model (eg priors from atlas etc) compensate in some way. Thanks. Mo PS I can post screenThe 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.
the documentation is a bit ahead of the release, so talairach_with_skull_2.lta doesnt exist in a 5.1 run. however, it is the same file as that produced during the -skull-lta stage (so its file date will be newer than talairach.lta), so if it is newer, then you can try rerunning skullstrip and it will use it.
i'd recommend 4 jobs on your 12GB machine, but try to space them apart by 30 minutes (sleep 18000).
n.
- A linear transform isn't always good enough to describe brain/skull
variability. It helps more often than it hurts, but sometimes it does worse.
2-3. I'll leave these for Nick except to say I think 3g/recon should be fine and you might be able to get away with a bit less. So 4 would be safe, but you might be able to squeeze in 5 or 6 (although they will of course run slower with only 4 cores)
cheers Bruce
On Sun, 27 Nov 2011, Mahinda Yogarajah wrote:
Dear Bruce and Freesurfer Experts,
Thanks for the quick answer, Bruce, to previous post.
As I work my way through all the checks on output I had a couple of other quick questions
- I noticed by skull-stripping was poor (too aggerssive at the back of
the brain with part of the occipital lobe and a small part of cerebellum). I therefore tried a number of suggestions from the tutorials including using -wsthresh 35 and -no-wsgcaatlas - this worked well but could someone explain why the lack of atlas use improves things ?
- I also tried to improve skull stripping using the
talairach_with_skull_2.lta option but I did not have this file despite recon-all -all having run fine the first time around with no errors/problems reported - should this concern me ?
- I am using Centos 64 on a Linux box with 4 cores and 12 GB of RAM -
how many instances of recon-all could I have running at the same time with no problems
Thank you.
Mo
On Thu, Nov 24, 2011 at 4:01 PM, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: Hi Mo,
that's not a problem. We have different normalizations for different pieces of the recon. For subcortical we use the norm.mgz, which should *not* be eroding borders of thalamus, pallidum, etc.... The brain*.mgz are for cortex, where we don't care about those borders. cheers BruceOn Thu, 24 Nov 2011, Mahinda Yogarajah wrote:
Dear Experts, I am a beginner to the use of Freesurfer and having just installed version 5.1.0 (Centos 64bit) I have been going through the processing pipeline with one of our own datasets (3T GE Excite II scanner - coronal T1-weighted volumetric acquisition sequence with 1.1-mm thick slices). recon-all works fine and I have been looking at the outputs. I have a question regarding the subcortical segmentation especially around the basal ganglia - during the intensity normalisation it appears to have assigned similar high (110) voxel values to parts of the internal capsule, pallidum and thalamus (pic1- brainmask.mgz), though the actual segmentation (pic2-aseg) looks reasonable when compared with the native image (pic3-raw T1) (though I appreciate one is normalised and the other is not). Should I be worried about this (and if so how can I correct ?) or is this intensity normalisation used only in the surface stream with a different intensity normalisation used in the volume stream ? Or ... is it used in the volume stream but the other parts of the model (eg priors from atlas etc) compensate in some way. Thanks. Mo PS I can post screenThe 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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu