Freesurfer January 2009

freesurfer@nmr.mgh.harvard.edu

72 participants
137 discussions

Calcarine fissure is divided into parts in the flat map
by Jürgen Hänggi 26 Jan '09

26 Jan '09

Dear FS experts The calcarine fissure (shown in cyan) is divided into several parts in the flat map. All other areas are still in one part in the flat map (see attachment). Is there anything wrong or is this the consequence of setting the relaxation cut in the calcarine fissure? Thanks in advance Regards Jürgen ---------------------------------------------------------- Juergen Haenggi Ph.D. (Dr. des.) Division Neuropsychology Institute of Psychology University of Zurich Binzmuehlestrasse 14, PO Box 25 8050 Zurich, Switzerland 0041 44 635 73 97 (phone office) 0041 76 445 86 84 (phone mobile) 0041 44 635 74 09 (fax office) BIN 4.D.04 (office room number) j.haenggi[at]psychologie.uzh.ch (email) http://www.psychologie.uzh.ch/neuropsy/ (website) http://www.juergenhaenggi.ch (private website) ----------------------------------------------------------

2 1

how to export volumes of different regions after segmentation?
by Bai Xue 26 Jan '09

26 Jan '09

Hi, I have done recon-all. Is there a command or button that can export all different region volumes maybe to a txt file so that we can have a look and compare? Thanks. Bai Xue

2 1

Warping label across mutliple brain surfaces
by Tony L 25 Jan '09

25 Jan '09

Hello, I have been unable to find a procedure/script to create a label based on talairach coordinates (or created on an averaged brain surface), and apply this label to different brain surfaces (e.g. warping the label to fit different brains). This is analogous to Freesurfer's built-in colored annotations depicting a surface's different brain cortices with labels. I need to do the exact same thing, but with a label that I define myself. Thank you very much! Best regards, Anthony _________________________________________________________________ Windows Live™ Hotmail®…more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_how…

2 1

Re: [Freesurfer] cropping of average T1
by Siddharth Srivastava 24 Jan '09

24 Jan '09

Hi Bruce, I just realised that the cropping at the posterior aspect is similar to the cropping usually done for the inferior aspect in a saggital view (to get rid of the neck etc..) . Could it be (remotely) possible that the cropping was done in a different orientation (nose pointing up in the sagittal view), and then oriented to the views that we see now? I have only used the basic commands "make_average_subject" with no special flags except --force sid. On Fri, Jan 23, 2009 at 10:33 AM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu>wrote: > I'm not really sure. Doug or Nick: any ideas? > > > On Fri, 23 Jan 2009, Siddharth Srivastava wrote: > > Hi Bruce, >> please find attached a tiff file generated by mri_concat >> --mean on the original mprages. >> Here i can see the full view, and i think no registration has been >> performed >> as yet on these >> images... Regarding exploring the dataset for 1 image, is it possible >> that >> just 1 rouge image >> can cause this problem? The clipping has a sharp border, almost as if the >> bounding box >> itself has been cropped at that level. the intensity in these posterior >> slices is zero. >> thanks, >> sid. >> >> On Fri, Jan 23, 2009 at 9:51 AM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu >> >wrote: >> >> if you can find a small set (1?) of subjects that generate the same >>> image, >>> then maybe you can just send us that subject and your commandline >>> >>> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >>> >>> ok.. i will try that and let you know... what other image/logs can i >>> >>>> provide >>>> for >>>> localizing the source of the error? >>>> sid. >>>> >>>> On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl < >>>> fischl(a)nmr.mgh.harvard.edu >>>> >>>>> wrote: >>>>> >>>> >>>> not really, it seems like there is a bug. If you can localize it to >>>> just >>>> >>>>> one or a few subjects it would a lot easier to track down >>>>> >>>>> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >>>>> >>>>> Hi Bruce, >>>>> >>>>> These are about 28 images. I have not tried fewer...do you >>>>>> think there >>>>>> are some images with incorrect orientation in the cohort? That would >>>>>> show >>>>>> up >>>>>> in the other location in the average i think... >>>>>> sid. >>>>>> On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl < >>>>>> fischl(a)nmr.mgh.harvard.edu >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>> I don't think so. How many subjects? Have you tried fewer? >>>>>> >>>>>> >>>>>>> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >>>>>>> >>>>>>> The surfaces look all right. It happens only to T1. It cant be a >>>>>>> display >>>>>>> >>>>>>> problem, can it?? >>>>>>> >>>>>>>> sid. >>>>>>>> >>>>>>>> On Fri, Jan 23, 2009 at 5:58 AM, Bruce Fischl < >>>>>>>> fischl(a)nmr.mgh.harvard.edu >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> that is strange. Do the surfaces look ok? How many subjects are >>>>>>>> you >>>>>>>> >>>>>>>> averaging? Does this happen if you only average one or a few? >>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, 22 Jan 2009, Siddharth Srivastava wrote: >>>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> >>>>>>>>> I am attaching a tiff file showing the tkmedit view >>>>>>>>> of >>>>>>>>> >>>>>>>>> the average >>>>>>>>>> T1 that freesurfer created during make_average_subject. I am a bit >>>>>>>>>> concerned >>>>>>>>>> >>>>>>>>>> about the cropping that is evident at the posterior aspect of the >>>>>>>>>> brain. >>>>>>>>>> The >>>>>>>>>> >>>>>>>>>> individual T1's are complete and ok, so i am guessing that >>>>>>>>>> something >>>>>>>>>> went >>>>>>>>>> wrong during the transform of the individual brain during the >>>>>>>>>> process. >>>>>>>>>> Can >>>>>>>>>> anyone help me find out the problem ? The average surfaces also >>>>>>>>>> look >>>>>>>>>> all >>>>>>>>>> right. >>>>>>>>>> thanks, >>>>>>>>>> sid. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>

2 3

Version 4.2.0 for Tiger on PowerPC Mac?
by Carl Anderson 23 Jan '09

23 Jan '09

Hi Would it be possible to somehow download V4.2.0 for Tiger running on a PowerPC Mac? Thanks ------------------------------------------------------- Carl M. Anderson, Ph.D. Assistant Professor of Psychiatry, Harvard Medical School & The Neural Imaging Center, McLean Hospital 115 Mill St. Belmont, MA 02478 Ph: 617-855-2972 Fax: 617-855-2770 webpages: http://remfractal.mclean.org/main.html email: carl_anderson(a)hms.harvard.edu ------------------------------------------------------- Any information, including protected health information (PHI), transmitted in this email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential and or exempt from disclosure under applicable Federal or State law. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon, protected health information (PHI) by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the material from any computer.

2 1

Cortical thickness conversion
by Yigal Agam 23 Jan '09

23 Jan '09

Hi, I'm trying to convert corical thickness maps into a common space and getting this error. Any ideas? mri_surf2surf --srcsubject mano002_new --trgsubject fsaverage --hemi lh --srcsurfval lh.thickness --trgsurfval /space/schnook/1/users/yigal/projects/dti/data/new_recons/mano002_new/surf/lh.thickness_fsaverage.nii --nsmooth-in 3 --nsmooth-out 3 srcsubject = mano002_new srcval = lh.thickness srctype = trgsubject = fsaverage trgval = /space/schnook/1/users/yigal/projects/dti/data/new_recons/mano002_new/surf/lh.thickness_fsaverage.nii trgtype = surfreg = sphere.reg srchemi = lh trghemi = lh frame = 0 fwhm-in = 0 fwhm-out = 0 Reading source surface reg /autofs/space/ventzl_001/users/SUBJECTS_DIR/mano002_new/surf/lh.sphere.reg Loading source data ERROR: dimesion inconsitency in source data Number of surface vertices = 115532 Number of value vertices = 118209 mri_surf2surf --srcsubject mano002_new --trgsubject fsaverage --hemi rh --srcsurfval rh.thickness --trgsurfval /space/schnook/1/users/yigal/projects/dti/data/new_recons/mano002_new/surf/rh.thickness_fsaverage.nii --nsmooth-in 3 --nsmooth-out 3 srcsubject = mano002_new srcval = rh.thickness srctype = trgsubject = fsaverage trgval = /space/schnook/1/users/yigal/projects/dti/data/new_recons/mano002_new/surf/rh.thickness_fsaverage.nii trgtype = surfreg = sphere.reg srchemi = rh trghemi = rh frame = 0 fwhm-in = 0 fwhm-out = 0 Reading source surface reg /autofs/space/ventzl_001/users/SUBJECTS_DIR/mano002_new/surf/rh.sphere.reg Loading source data ERROR: dimesion inconsitency in source data Number of surface vertices = 116029 Number of value vertices = 120919

2 1

Fwd: [Freesurfer] cropping of average T1
by Siddharth Srivastava 23 Jan '09

23 Jan '09

---------- Forwarded message ---------- From: Siddharth Srivastava <siddys(a)gmail.com> Date: Fri, Jan 23, 2009 at 9:10 AM Subject: Re: [Freesurfer] cropping of average T1 To: Bruce Fischl <fischl(a)nmr.mgh.harvard.edu> ok.. i will try that and let you know... what other image/logs can i provide for localizing the source of the error? sid. On Fri, Jan 23, 2009 at 9:04 AM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu>wrote: > not really, it seems like there is a bug. If you can localize it to just > one or a few subjects it would a lot easier to track down > > On Fri, 23 Jan 2009, Siddharth Srivastava wrote: > > Hi Bruce, >> These are about 28 images. I have not tried fewer...do you >> think there >> are some images with incorrect orientation in the cohort? That would show >> up >> in the other location in the average i think... >> sid. >> On Fri, Jan 23, 2009 at 8:46 AM, Bruce Fischl <fischl(a)nmr.mgh.harvard.edu >> >wrote: >> >> I don't think so. How many subjects? Have you tried fewer? >>> >>> On Fri, 23 Jan 2009, Siddharth Srivastava wrote: >>> >>> The surfaces look all right. It happens only to T1. It cant be a display >>> >>>> problem, can it?? >>>> sid. >>>> >>>> On Fri, Jan 23, 2009 at 5:58 AM, Bruce Fischl < >>>> fischl(a)nmr.mgh.harvard.edu >>>> >>>>> wrote: >>>>> >>>> >>>> that is strange. Do the surfaces look ok? How many subjects are you >>>> >>>>> averaging? Does this happen if you only average one or a few? >>>>> >>>>> On Thu, 22 Jan 2009, Siddharth Srivastava wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> I am attaching a tiff file showing the tkmedit view of >>>>>> the average >>>>>> T1 that freesurfer created during make_average_subject. I am a bit >>>>>> concerned >>>>>> >>>>>> about the cropping that is evident at the posterior aspect of the >>>>>> brain. >>>>>> The >>>>>> >>>>>> individual T1's are complete and ok, so i am guessing that something >>>>>> went >>>>>> wrong during the transform of the individual brain during the process. >>>>>> Can >>>>>> anyone help me find out the problem ? The average surfaces also look >>>>>> all >>>>>> right. >>>>>> thanks, >>>>>> sid. >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>

1 0

cropping of average T1
by Siddharth Srivastava 23 Jan '09

23 Jan '09

Hi everyone, I am attaching a tiff file showing the tkmedit view of the average T1 that freesurfer created during make_average_subject. I am a bit concerned about the cropping that is evident at the posterior aspect of the brain. The individual T1's are complete and ok, so i am guessing that something went wrong during the transform of the individual brain during the process. Can anyone help me find out the problem ? The average surfaces also look all right. thanks, sid.

2 3

labels and transforming them
by Ian Malone 23 Jan '09

23 Jan '09

Hi, I'm trying to work out how to use a transformation matrix derived from FSL to transform labels from Freesurfer into a standard space (MNI152). If I use mri_label2vol to convert the label to a volume with the scan from subject/mri/orig/001.mgz as a template and then flirt to apply the FSL transformation I end up with something that corresponds correctly to the standard space (and the intermediate volume looks correct compared to the original scan). If on the other hand I multiply the positions in the label file by the transformation matrix from FSL (i.e. M*[x y z 1]') then the labelled region does not appear in the correct space. I have also tried adjusting the translation component of the FSL matrix by half the difference between the standard space and original image dimensions with no success. I've also tried to generate a .mat to pass to mri_label2vol using tkregister2, but despite trying different combinations of I and S in --targ-orientation and --mov-orientation I seem to always have one volume upside down (target if I don't specify the orientation, moveable if I do, the FSL matrix does not have this flip). Any suggestions for things that might be going wrong here or other strategies to try? Also, assuming I get the transformation right, will adjusting the label point volume to match the new voxel dimensions make any difference if the the threshold is set at zero? Thanks, Ian

1 0

mri_convert
by Jared Price 23 Jan '09

23 Jan '09

Hi everyone, I have a quick question but an important one. We are working on a 5 year study involving well over 1000 scans. Processing of these patients is primarily done using a cluster machine loaded with freesurfer version x86_64-redhat-linux-gnu-dev4-20080904. However, sometimes it is useful to be able to do certain preliminary steps of the processing locally in our lab which is full of Macs running the 4.0.5 version of freesurfer. Also, because of the long nature of the study in the past these computers have been loaded with 4.0.0 4.0.1 4.0.2 etc. Anyway, my question is that although all of the recon-all processing has been done on the cluster machine some scans have undergone mri_convert locally in the lab to create a 001.mgz file which is then fed to the cluster for further processing. Would there be any concern in this? I know the version of mri_convert for freesurfer version 4.0.5 is mri_convert 1.146.2.3 and the one on our cluster machine is 1.146.2.1, but I am not sure what the versions of mri_convert were that were used in 4.0.0 4.0.1 etc. Anyway, any reason for concern in having some variability only in the version invoked to create the 001.mgz file using mri_convert?

2 1

← Newer
1
2
3
4
5
6
7
8
...
14
Older →

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 January 2009