Freesurfer

freesurfer@nmr.mgh.harvard.edu

15 participants
30097 discussions

White matter edits
by lexi bryon 31 Jul '13

31 Jul '13

Dear Freesurfer experts, I am running recon-all on child brains and I am have an issue with one brain. One entire temporal gyrus is being excluded from the white matter boundary line. I have entered control points and rerun recon-all using autorecon2-cp. This added the desired white matter to wm.mgz: see attached photo. But as you can see it does not recognize it as white matter and/or create the correct white matter boundary/ pial surface. Any ideas? Sincerely, Alexarae

2 1

freesurfer 5.3 T2 flags error
by Joana Braga Pereira 31 Jul '13

31 Jul '13

Dear FreeSurfers, I tried using FreeSurfer 5.3 with the new T2 flags and I got the following error: INFO: Reading transformation from file /tmp/1b2003d0-08c9-4e48-9e9d-622f29f0ff44/mri/transforms/T2raw.lta... Reading transform with LTAreadEx() No such file or directory ERROR: Reading transform from file /tmp/1b2003d0-08c9-4e48-9e9d-622f29f0ff44/mri/transforms/T2raw.lta Linux pe01 3.5.0-27-generic #46~precise1-Ubuntu SMP Tue Mar 26 19:33:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux This is the command I used: /usr/local/freesurfer-5.3/bin/recon-all -T2 0517a9f6-098e-47e8-9038-347d8ec7f840/PPMI_3557_MR_Axial_PD-T2_TSE__br_raw_20110406143102862_49_S103376_I226466.dcm -i 1d58a0ab-3be7-4f18-974a-7faed908c840/MR_MPRAGE_GRAPPA__br_raw_20110406143100268_1_S103377_I226467.dcm -subjid 1b2003d0-08c9-4e48-9e9d-622f29f0ff44 -all -mprage -nuintensitycor-3T -qcache -T2pial Does anyone know why I got this error with the T2 or what I did wrong? Many thanks! joana

1 0

GLM Analysis: ROI (--label)
by Rachel Jonas 30 Jul '13

30 Jul '13

Hi FreeSurfer users, I am running a GLM analysis on the command line, and would like to look specifically within an ROI. I added the flag: --label lh.orbitofrontal.label, in my case, to mri_glmfit, but keep getting an error. It seems that whenever it hits this line in the command, it quits. If I put this flag at the very end (after I specify the glmdir, which I do at the very end), it'll just complete the analysis as if this flag wasn't even there, resulting in a full-brain analysis. Am I missing something here re: how to add in this flag? Any help would be much appreciated! Rachel Jonas

2 1

Cerebellar parcellation
by charles laidi 30 Jul '13

30 Jul '13

Dear Freesurfers, I would like to perform cerebellar parcellation on structural mri with freesurfer. I asked if this was possible 6 months ago (see message below, saying that this feature wasn't available for now). I checked on freesurfer wiki the release notes about Freesurfer version 5.2.0 saying that new cortical parcellations and label were available. "Cortical, Cerebellar, Striatum Parcellation in MNI152 space found in average/<Yeo_JNeurophysiol11_MNI152>, average/<Buckner_JNeurophysiol11_MNI152> and average/<Choi_JNeurophysiol12_MNI152>. See README file in each directory for more details. Note that these README files will be updated to reflect minor improvements in parcellations beyond the publication wikipages". My understanding is that cerebellar parcellation on structural mri is still not available, could you tell me if I'm right ? When I'm checking the link on the release notes it doesn't seems to concern structural imaging. Thanks a lot for your attention, sorry if my question seems obvious but I'm not very familiar with freesurfer. Charles PS : -answer : Hi Charles, that is true at the moment, although we are working on something that should be ready relatively soon. cheers Bruce -question : Dear freesurfer, I'm trying to perform parcellation on the cerebellum. After reading closely freesurfer wiki and the questions related to this topic on the mailing list, my understanding is that there is no way to perform fully automted cerebellar parcellation on structural mri with freesurfer. Could you tell me if I'm right ? Thanks a lot for your attention Charles

2 1

are many *.dat files written out to disk in <subj_dir>/mri and then deleted when autorecon completes?
by Montillo, Albert (GE Global Research) 30 Jul '13

30 Jul '13

After importing a subject's data (T1 single time point) I run a script with these commands: recon-all -s <subject> -autorecon1 recon-all -s <subject> -autorecon2 recon-all -s <subject> -autorecon3 I did this twice, once on each of two linux machines. I am using the same exact input intensity T1 data and importing the data into separate subject names (e1859_workingBak and e1858_nonworking) so there is no collision. Why am I getting many (really 1000's ) of v1_1.dat files in the $SUBJECTS_DIR/<subject>/mri of one of the machines, even though the input data is the same? They are named vNNN_N.dat where N is a digit . Contents of one of these files is below. The contents of the subject folders are represented below using the du -k . command. Now in this nonworking case the job terminated early (run time limit on the job which I can fix ) ; however I am curious: are all of these *.dat files (40GB worth!) written out all the time and then deleted at the end of the recon tasks? This happens on one red-hat linux machine (cluster ) but not on another for the same subject data Is this normal behavior? Are the dat files written out normally and then deleted later in the processing (since I don't see them in the run that completed). Contents of a subject after a successful run to completion: [e1858_workingBak]$ du -k . 1176 ./scripts 16 ./mri/transforms/bak 108200 ./mri/transforms 14088 ./mri/orig 176068 ./mri 149940 ./surf 16 ./tmp 35228 ./label 1096 ./touch 544 ./stats 16 ./src 16 ./trash 16 ./bem 364132 . Contents of same MRI input data to a different subject name, whose processing (same as above) terminated prematurely: [e1858_nonworking]$ du -k . 800 ./scripts 16 ./mri/transforms/bak 108200 ./mri/transforms 14088 ./mri/orig 41027804 ./mri 29252 ./surf 16 ./tmp 16 ./label 360 ./touch 16 ./stats 16 ./src 16 ./trash 16 ./bem 41058328 . This is when the processing of e1858_nonworking got terminated: [scripts]$ tail recon-all-status.log #@# Intensity Normalization2 Thu Jul 25 19:20:22 EDT 2013 #@# Mask BFS Thu Jul 25 19:24:53 EDT 2013 #@# WM Segmentation Thu Jul 25 19:24:56 EDT 2013 #@# Fill Thu Jul 25 19:27:47 EDT 2013 #@# Tessellate lh Thu Jul 25 19:28:47 EDT 2013 #@# Smooth1 lh Thu Jul 25 19:28:56 EDT 2013 #@# Inflation1 lh Thu Jul 25 19:29:01 EDT 2013 #@# QSphere lh Thu Jul 25 19:29:37 EDT 2013 #@# Fix Topology lh Thu Jul 25 19:35:03 EDT 2013 #@# Make White Surf lh Thu Jul 25 19:55:20 EDT 2013 This is the contents of one (v1_1.dat ) of the many *.dat files in /mri [mri]$ tail v1_1.dat 12.014513 223.051927 250.208421 12.052258 222.911943 252.203797 12.090005 222.771944 254.199159 12.127751 222.631960 256.194520 12.165498 222.491960 258.189912 12.203243 222.351976 260.185273 12.240990 222.211977 262.180635 12.278736 222.071992 264.175996 12.316483 221.931993 266.171358 12.354229 221.791994 268.166750

2 3

Deformed tksurfer results
by pfotiad＠nmr.mgh.harvard.edu 30 Jul '13

30 Jul '13

Hi, I ran tksurfer (with the inflated surface option) on a couple of my subjects that had a major deformation in their orig.mgz file and the inflated surface of tksurfer looked as if a chunk was missing off of it at the position where the deformation is located. Is that normal? I have attached two images to illustrate what I mean: One of an axial slab of the orig.mgz file where the deformation is shown, and one of the inflated surface of the same subject in tksurfer. Thank you for your time, Panos

2 2

Unsegmented ventricles
by Victor Kovac 30 Jul '13

30 Jul '13

Dear Freesurfer experts, I am running recon-all on very atrophied brains with mixed results. Attached is an image of a brain where segmentation has gone awry. There is no message indicating talairach failure, and the segmentation appears to need WM and pial edits as well as the ventricles to be filled, so I am not sure how to proceed. If you have any recommendations as to how to fix these errors, I would very much appreciate it -- these data are past their deadline, and I am at a loss. Thank you! Sincerely, Victor

3 4

Re: [Freesurfer] Deformed tksurfer results
by pfotiad＠nmr.mgh.harvard.edu 30 Jul '13

30 Jul '13

Sorry forgot the attachments. >> Hi, >> >> I ran tksurfer (with the inflated surface option) on a couple of my >> subjects that had a major deformation in their orig.mgz file and the >> inflated surface of tksurfer looked as if a chunk was missing off of it >> at >> the position where the deformation is located. Is that normal? >> >> I have attached two images to illustrate what I mean: One of an axial >> slab >> of the orig.mgz file where the deformation is shown, and one of the >> inflated surface of the same subject in tksurfer. >> >> Thank you for your time, >> Panos >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer(a)nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> >

1 0

Re: [Freesurfer] infant atlas segmentation
by Mark Plantz 30 Jul '13

30 Jul '13

Sorry about that. I received the manual segmentations from a UNC medical group < http://www.med.unc.edu/bric/ideagroup/free-softwares/unc-infant-0-1-2-atlas…>. I actually asked the main researcher about the out of bounds regions. He thinks that as long as the segmented file lines up with the input volumes, a few out of bounds regions might be OK. However, these seg volumes look very different from a typical .aseg volume that I am used to seeing after recon-all is run. Maybe the segmentation is simply incompatible with FreeSurfer? Thanks for the help. These files are a nightmare! - MP On Mon, Jul 29, 2013 at 11:40 AM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu>wrote: > can you cc the list please? Maybe we should start over. Where did you get > the manual segmentations from? > > On Mon, 29 Jul 2013, Mark Plantz wrote: > > Ahh, right. So it looks like the red regions appear to be averaged around >> 248. I am not sure why that is the case or if it has >> any significance. I attached a screen shot for reference. >> >> >> On Mon, Jul 29, 2013 at 11:29 AM, Bruce Fischl < >> fischl(a)nmr.mgh.harvard.edu> wrote: >> it isn't a registration file. You should just specify it as a >> volume on the freeview command line, the same as >> brainmask.mgz >> >> On Mon, 29 Jul 2013, Mark Plantz wrote: >> >> I actually tried to view the brainmask.mgz file with the >> segmentation file [Freeview calls it >> 'registration file' I believe]. >> For some reason, the file will load without segmentation, but >> when I attempt to add the registration >> file, I get an error >> message: >> "Failed to load MRI ~/.../../../brainmask.mgz >> >> Could this potentially be part of the problem? >> >> Thanks >> >> MP >> >> >> On Mon, Jul 29, 2013 at 10:57 AM, Mark Plantz < >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> wrote: >> >> It looks like the values vary from 20-120 depending on >> which region I run the cursor over. >> However, aren't those the >> values that correspond to the brain.mgz regions? Is >> there another way to find the segmentation >> values? >> >> >> On Mon, Jul 29, 2013 at 10:37 AM, Bruce Fischl < >> fischl(a)nmr.mgh.harvard.edu> wrote: >> I mean the segmentation values that give you the "out >> of bounds" message >> On Mon, 29 Jul 2013, Mark Plantz wrote: >> >> Hi Bruce, >> Do you mean the brainmask.mgz values? I'm not >> sure what the segmentation #'s exactly are. >> >> Thanks! >> >> MP >> >> >> On Mon, Jul 29, 2013 at 10:17 AM, Bruce Fischl < >> fischl(a)nmr.mgh.harvard.edu> wrote: >> Hi Mark >> >> >> what #s are those segmentations? It should >> be trivial to just add them to the end of >> the >> LUT. I wouldn't let them be >> out of bounds as there might be code around >> that might ignore them then. >> >> cheers >> Bruce >> >> On Mon, 29 Jul 2013, Mark Plantz wrote: >> >> Hi Doug, >> Thanks for the reply. After >> doing some research, it looks like messing >> with the >> LUT might be a >> risky decision [and way >> out of my abilities!]. >> >> If I were to use this segmentation >> file to create a .gca atlas using the >> command >> mri_ca_train, do you >> think it would yield >> problems or be inaccurate? I guess >> what I am trying to figure out is if the >> color >> lookup values are even >> significant when using >> the segmentation file to create an >> atlas? >> >> Thanks for all of the help with this. >> >> Best, >> >> MP >> >> p.s. I attached the photo of the >> segmentation volume because this e-mail is sort >> of >> old >> >> >> On Wed, Jul 24, 2013 at 2:39 PM, >> Douglas N Greve <greve(a)nmr.mgh.harvard.edu> >> wrote: >> you need a new LUT. See my >> comment from a few emails ago. >> On 07/24/2013 03:29 PM, Mark >> Plantz wrote: >> I'm not actually quite sure >> what it means either. When I use the command >> line: >> >> tkmedit $Subject brain.mgz >> -segmentation <seg.mgz>, >> >> I can run the cursor over >> various regions and the name of the region >> should pop >> up. For some >> reason, the red >> regions are simply labeled as >> "out of bounds." >> >> I'll keep messing with tkmedit >> and let you know if I find out what the >> problem >> is. >> >> Thanks guys! >> >> MP >> >> >> On Wed, Jul 24, 2013 at 2:26 PM, >> Douglas N Greve <greve(a)nmr.mgh.harvard.edu >> <mailto:greve@nmr.mgh.harvard.**edu<greve(a)nmr.mgh.harvard.edu> >> >> >> wrote: >> >> what do you mean that they are >> out of bounds? >> >> On 07/24/2013 03:25 PM, Mark >> Plantz wrote: >> >> I guess the problem is that >> those regions should not be out of >> bounds. Maybe I need to >> create a new Lookup Table for the >> infant mri's? Is that >> possible to do? >> >> >> On Wed, Jul 24, 2013 at 2:21 >> PM, Douglas N Greve >> <greve(a)nmr.mgh.harvard.edu<mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>>> wrote: >> >> Hi Mark, please post to >> the list and not to me. >> thanks >> doug >> >> On 07/24/2013 03:21 PM, >> Mark Plantz wrote: >> >> I guess the problem >> is that those regions should not >> be out of >> bounds. Maybe I need >> to create a new Lookup Table for the >> infant mri's? Is that >> possible to do? >> >> >> On Wed, Jul 24, 2013 >> at 2:15 PM, Douglas N Greve >> < >> greve(a)nmr.mgh.harvard.edu >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>>>> wrote: >> >> >> what is the >> problem exactly? The fact that there >> are red >> regions >> or that that the >> red regions are labeled as "Out of >> Bounds"? If >> the latter, you >> will need to create a LUT that >> matches your >> regions. the out >> of bounds means that the index in the >> volume does >> not match an >> index in the LUT. >> doug >> >> >> >> On 07/24/2013 >> 01:26 PM, Mark Plantz wrote: >> >> Finally got >> the registration to work. However, it >> looks like >> the out of >> bounds regions (in red) are still >> present (even >> though the >> regions are well within our >> boundaries). Is >> that >> expected >> since they were labeled in the original >> segmentation >> volume? Is >> there anyway to correct those? >> >> Thanks for >> all of the help! >> >> - Mark >> p.s. I >> attached a picture of the original >> brain.mgz file >> viewed with >> the corrected segmentation volume >> >> >> On Wed, Jul >> 24, 2013 at 12:22 PM, Mark Plantz >> < >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>> >> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>>>>> wrote: >> >> Finally >> got the registration to work. >> However, it >> looks >> like the >> out of >> bound regions (in red) are still >> prevalent. >> Is that >> expected >> since they were present in the >> original >> segmentation >> volume? >> Would there be anyway to correct >> those? >> >> Thanks >> for all the help! >> >> - MP >> >> >> On Wed, >> Jul 24, 2013 at 11:11 AM, Mark Plantz >> < >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>> >> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>>>>> wrote: >> >> >> Nevermind, it turned out to be a >> permissions >> issue. >> Thanks! >> >> >> On >> Wed, Jul 24, 2013 at 10:12 AM, Mark >> Plantz >> < >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>>> >> >> <mailto:markplantz2016@u.**northwestern.edu<markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>> >> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>> >> <mailto: >> markplantz2016(a)u.**northwestern.edu <markplantz2016(a)u.northwestern.edu> >> <mailto:markplantz2016@u.** >> northwestern.edu <markplantz2016(a)u.northwestern.edu>>>>>> wrote: >> >> >> Thanks for the reply Doug. I >> recently ran the >> bbregister >> >> command and attempted to view the >> results >> using >> >> tkregister2. I received the >> following error: >> >> >> dhcp-165-124-23-232 >> <tel:165-124-23-232> <tel: >> 165-124-23-232 <tel:165-124-23-232>> >> <tel:165-124-23-232<tel: >> 165-124-23-232> >> <tel:165-124-23-232 <tel: >> 165-124-23-232>>> >> <tel: >> 165-124-23-232 <tel:165-124-23-232> >> <tel:165-124-23-232 <tel: >> 165-124-23-232>> >> <tel:165-124-23-232<tel: >> 165-124-23-232> >> <tel:165-124-23-232 <tel: >> 165-124-23-232>>>>:Desktop >> >> >> >> IngvalsonLab$ tkregister2 --mov >> >> /Volumes/Wong_Lab/**CochlearImplant/UNC_NiFTI/** >> infant-1yr-mgz/mri/avgseg.mgz >> >> --reg >> >> /Users/IngvalsonLab/Desktop/**register.dat --surf >> >> >> tkregister_tcl >> /Applications/freesurfer/** >> tktools/tkregister2.tcl >> >> INFO: no target volume specified, >> assuming >> FreeSurfer >> orig >> >> volume. >> >> target volume orig >> >> movable volume >> >> /Volumes/Wong_Lab/**CochlearImplant/UNC_NiFTI/** >> infant-1yr-mgz/mri/avgseg.mgz >> >> reg file >> >> /Users/IngvalsonLab/Desktop/**register.dat >> >> LoadVol 1 >> >> ZeroCRAS 0 >> >> $Id: tkregister2.c,v 1.121.2.1 >> 2011/03/28 >> 20:25:16 >> greve Exp $ >> >> Diagnostic Level -1 >> >> regio_read_register(): Undefined >> error: 0 >> >> Error reading subject from >> /Users/IngvalsonLab/Desktop/* >> *register.dat >> >> ERROR: reading >> >> /Users/IngvalsonLab/Desktop/**register.dat >> >> dhcp-165-124-23-232 >> <tel:165-124-23-232> <tel: >> 165-124-23-232 <tel:165-124-23-232>> >> <tel:165-124-23-232<tel: >> 165-124-23-232> >> <tel:165-124-23-232 <tel: >> 165-124-23-232>>> >> <tel: >> 165-124-23-232 <tel:165-124-23-232> >> <tel:165-124-23-232 <tel: >> 165-124-23-232>> >> <tel:165-124-23-232<tel: >> 165-124-23-232> >> <tel:165-124-23-232 <tel: >> 165-124-23-232>>>>:Desktop >> >> >> >> IngvalsonLab$ >> >> I >> do not believe it is a >> permissions issue? >> >> >> Could it simply be that the >> register was >> bad? Is >> there an >> >> easy way to open up the >> register.dat.mincost >> file >> to check >> >> the registration? >> >> >> Thanks again, >> >> MP >> >> >> >> On Tue, Jul 23, 2013 at 9:32 PM, >> Douglas Greve >> < >> greve(a)nmr.mgh.harvard.edu >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>>> >> >> <mailto:greve@nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>> >> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>>>>> wrote: >> >> >> >> You can try using bbregister. >> Normally, you >> don't use >> >> bbregister on a segmentation, >> but the >> segmentation >> >> index numbers just happen to be >> "T1-weighted". >> >> doug >> >> ps. Please remember to copy >> the list when >> responding. >> >> thanks! >> >> >> >> >> On 7/23/13 9:51 AM, Mark >> Plantz wrote: >> >> >> Hi Doug, >> >> >> Sorry about that vague >> explanation. So >> I received >> >> a series of infant brain >> atlases >> from a >> UNC >> medical >> >> research group >> >> (http://www.med.unc.edu/bric/** >> ideagroup/free-softwares/unc-**infant-0-1-2-atlases<http://www.med.unc.edu/bric/ideagroup/free-softwares/unc-infant-0-1-2-atlas…> >> ). >> >> I have a series of infant >> MRI's that I >> would >> like to >> >> segment (using the infant >> atlases, >> instead >> of the >> >> default adult atlas in >> FreeSurfer). >> >> >> As a preliminary step, >> I was >> attempting >> to check >> >> the alignment of one of >> the atlas >> files >> >> ('avgseg.mgz') with one of the >> input brains >> >> ('brain.mgz'). [I attached >> these two >> files, >> just in >> >> case]. >> >> >> So my command line would be: >> >> >> tkmedit $Subject brain.mgz >> -segmentation >> avgseg.mgz >> $FREESURFER_HOME/** >> FreeSurferColorLUT.txt >> >> >> The result was the >> previously attached >> image. I >> was >> >> just wondering if there is >> any way to >> shift the >> two >> >> images manually so the >> alignment is >> better? >> Or maybe >> >> the two files are simply not >> compatible >> with one >> another? >> >> >> Thanks for all the help! >> >> >> Best, >> >> >> Mark >> >> >> >> >> >> On Mon, Jul 22, 2013 at >> 3:53 PM, >> Douglas N >> Greve >> >> <greve(a)nmr.mgh.harvard.edu >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>>> >> >> >> <mailto:greve@nmr.mgh.**harvard.edu<greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>> >> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu> >> <mailto: >> greve(a)nmr.mgh.harvard.**edu <greve(a)nmr.mgh.harvard.edu>>>>>> wrote: >> >> >> >> Hi Mark, I have no >> idea what >> you are >> doing. Can >> >> you send a command line? >> >> Are either of the images >> generated by FS? >> >> doug >> >> >> >> >> >> On 07/22/2013 03:56 >> PM, Mark >> Plantz wrote: >> >> > Hello FreeSurfers, >> >> > >> >> > I recently >> obtained a >> set of infant >> >> templates. Out of >> curiousity, >> >> > I decided to view >> one of the >> input >> brains >> with >> >> the provided segmented >> >> > volume file. It >> appears that >> there >> is some >> >> misalignment. I wouldn't >> >> > expect the alignment >> to be >> perfect, >> since I am >> >> basically overlaying an >> >> > average of multiple >> brains >> onto one. >> However, >> >> it looks like this >> >> > misalignment may be >> caused by >> either: >> 1.) the >> >> segmentation volume file >> >> > being shifted down >> or 2.) >> the slices >> not lining >> >> up properly (i.e. one >> >> > file starts before >> the other). >> >> > >> >> > Any ideas what >> could cause a >> problem >> like >> >> this? Could it be that >> >> > the segmented files are >> simply not >> compatible >> >> with FreeSurfer? >> >> > >> >> > Thanks for the help, >> >> > >> >> > Mark >> >> > > >

3 6

LGI
by 이 정환 29 Jul '13

29 Jul '13

Hi, I am trying to computer the LGI local gyrification index with freesurfer. I have Matlab on my machine. I got the following error: < M A T L A B (R) > Copyright 1984-2013 The MathWorks, Inc. R2013a (8.1.0.604) 64-bit (maci64) February 15, 2013 ---------------------------------------------------- Your MATLAB license will expire in 10 days. Please contact your system administrator or MathWorks to renew this license. ---------------------------------------------------- To get started, type one of these: helpwin, helpdesk, or demo. For product information, visit www.mathworks.com. >> loading datas ... FREESURFER_READ_SURF [v 1.2 ] ...reading surface file: lh.pial ...reading triangle file ...adding 1 to face indices for matlab compatibility. ...done ( 0.03 sec) FREESURFER_READ_SURF [v 1.2 ] ...reading surface file: lh.pial-outer-smoothed ...reading triangle file ...adding 1 to face indices for matlab compatibility. ...done ( 0.01 sec) preparing outer mesh structure ... face 5000 / 128476 face 10000 / 128476 face 15000 / 128476 face 20000 / 128476 face 25000 / 128476 face 30000 / 128476 face 35000 / 128476 face 40000 / 128476 face 45000 / 128476 face 50000 / 128476 face 55000 / 128476 face 60000 / 128476 face 65000 / 128476 face 70000 / 128476 face 75000 / 128476 face 80000 / 128476 face 85000 / 128476 face 90000 / 128476 face 95000 / 128476 face 100000 / 128476 face 105000 / 128476 face 110000 / 128476 face 115000 / 128476 face 120000 / 128476 face 125000 / 128476 mesh_outer = vertices: [64240x3 double] faces: [128476x3 double] facesOfVertex: [64240x1 struct] preparing pial mesh structure ... ...searching for mesh edges...done (250.55 sec). ... creating path file for vertex 1 / 64240 area file for outer ROIs saved at 1 Improper assignment with rectangular empty matrix. Error in dsearchn (line 80) [d(i),t(i)] = min(sum((x-yi).^2,2)); Error in mesh_vertex_nearest (line 29) nearestIndex = dsearchn(vertices,points); Error in reorganize_verticeslist (line 28) [nextindex,nextvalue]=mesh_vertex_nearest(mesh_total.vertices(remaininglist,:),mesh_total.vertices(verticeslist(start_vertex),:)); Error in make_roi_paths (line 93) reorglist = reorganize_verticeslist (mesh_total, A, mesh_outer, perim, verticeslist, step); >> ERROR: make_roi_paths did not complete successfully! Darwin iui-MacBook-Pro.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 recon-all -s 20130219-01 exited with ERRORS at Tue Jul 30 09:35:07 KST 2013 For more details, see the log file /Users/jeonghwan/Documents/freesurfer/ADHD-re/20130219-01/scripts/recon-all.log To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting Any suggestions to correct my error? Thanks, Jeonghwan

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer