Freesurfer

freesurfer@nmr.mgh.harvard.edu

30132 discussions

bankssts label
by Mensen, V.T. 13 Nov '12

13 Nov '12

Dear Freesurfers, Does anyone know why sometimes the "bankssts" (banks of the superior temporal sulcus) is only found in the sulcus, and sometimes occupies a sizeable part of an adjacent gyrus (superior temporal / inferior parietal)? The dark-green area is generally only visible in the inflated view, but every so often it is quite pronounced in the main (pial) view as well. Thanks! Vincent Mensen Utrecht ------------------------------------------------------------------------------ De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. Het Universitair Medisch Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W. (Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197. Denk s.v.p aan het milieu voor u deze e-mail afdrukt. ------------------------------------------------------------------------------ This message may contain confidential information and is intended exclusively for the addressee. If you receive this message unintentionally, please do not use the contents but notify the sender immediately by return e-mail. University Medical Center Utrecht is a legal person by public law and is registered at the Chamber of Commerce for Midden-Nederland under no. 30244197. Please consider the environment before printing this e-mail.

2 1

Re: [Freesurfer] pre-processing functional data error
by Douglas N Greve 13 Nov '12

13 Nov '12

The terminal output looks ok. Do you mean that there is something wrong with the output volume? What? doug On 11/12/2012 11:30 AM, Yangmei LUO wrote: > Hi Douglas, > > It appeared the same error as before. The picture of the results is > the same. I am so sorry. > Thanks again! > > Best, > Yangmei > > $ /usr/local/freesurfer/bin/mri_convert.linux I0001.dcm s105.run1.nii > /usr/local/freesurfer/bin/mri_convert.linux I0001.dcm s105.run1.nii > $Id: mri_convert.c,v 1.196 2012/07/11 17:50:50 fischl Exp $ > reading from I0001.dcm... > Getting Series No > Scanning Directory > INFO: Found 230 files in /home/fsl/data/emotion/s105/run1 > INFO: Scanning for Series Number 3 > INFO: found 228 files in series > INFO: loading series header info. > > INFO: sorting. > RunNo = 2 > INFO: ( 64 64 32), nframes = 228, ismosaic=1 > Could not parse NUMARIS version string syngo MR B17 > found in dicom tag 18,1020 (len = 3 != 6) > Repetition Time = 2000, TR = 2000 ms > PE Dir COL COL > AutoAlign matrix detected > AutoAlign Matrix --------------------- > 1.000 0.000 0.000 0.000; > 0.000 1.000 0.000 0.000; > 0.000 0.000 1.000 0.000; > 0.000 0.000 0.000 1.000; > > FileName /home/fsl/data/emotion/s105/run1/I0001.dcm > Identification > NumarisVer syngo MR B17 > ScannerModel TrioTim > PatientName LuoYangmei_s5^caoguoguo > Date and time > StudyDate 20121009 > StudyTime 084434.968000 > SeriesTime 090357.640000 > AcqTime 090309.732500 > Acquisition parameters > PulseSeq *epfid2d1_64 > Protocol run1 > PhEncDir COL > EchoNo 1 > FlipAngle 90 > EchoTime 30 > InversionTime -1 > RepetitionTime 2000 > PhEncFOV 192 > ReadoutFOV 192 > Image information > RunNo 2 > SeriesNo 3 > ImageNo 1 > NImageRows 384 > NImageCols 384 > NFrames 228 > SliceArraylSize 32 > IsMosaic 1 > ImgPos 99.3735 107.4917 -33.8349 > VolRes 3.0000 3.0000 3.9900 > VolDim 64 64 32 > Vc -1.0000 -0.0000 0.0000 > Vr -0.0000 -0.9999 0.0105 > Vs -0.0000 0.0105 0.9999 > VolCenter 3.3735 12.1655 31.0069 > TransferSyntaxUID 1.2.840.10008.1.2 > UseSliceScaleFactor 0 (slice 0: 1) > sagrev = 0, correv =1, trarev = 1 > Vs = -0 0.0104718 0.999945 > INFO: detected a Siemens slice order reversal in mosaic, so > I'm going to reverse them back to their 'original' order. > TR=2000.00, TE=30.00, TI=-1.00, flip angle=90.00 > i_ras = (-1, -0, 0) > j_ras = (-0, -0.999945, 0.0104718) > k_ras = (-0, 0.0104718, 0.999945) > writing to s105.run1.nii... > > > > > > > > > > On Mon, Nov 12, 2012 at 4:11 PM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: > > sorry, remove the slash from the end of the line > > > On 11/12/2012 10:49 AM, Yangmei LUO wrote: > > Hi Douglas, > > Thank you for your kind help. The command still can not work. > > $ /usr/local/freesurfer/bin/mri_convert.linux I0001.dcm > s105.run1.nii/ > > /usr/local/freesurfer/bin/mri_convert.linux I0001.dcm > s105.run1.nii/ > mri_convert.linux: can't determine type of output volume > ind = 86581; % bad > Ct0 = y(:,ind+1); > %Ct0 = load('tcp.dat'); > intCt0 = cumtrapz(t0,Ct0); > > HalfLifeMin = 20.4; %min > TDecayMin = -HalfLifeMin/log(.5); > TDecaySec = TDecayMin*60; > intDecay = t0.*exp(-t0/TDecayMin); > w = sqrt(intDecay/sum(intDecay)); > W = diag(w); > > > X0 = [Cr0 intCr0 -intCt0]; > X = W*X0; > WCt = W*Ct0; > beta = inv(X'*X)*X'*WCt; > R1 = beta(1); > k2 = beta(2); > k2a = beta(3); > BPnd0 = k2/k2a -1; > CtHatSRTM = X0*beta; > > psrtm0 = max([R1 k2 k2a],0) + eps; > if(BPnd0 > 7 | BPnd0 < 0) psrtm0(3) = abs(k2)/(6+1); end > psrtm = fminsearch('srtm_err',psrtm0,[],Ct0,t0,Cr0,w); > [err CtHatsrtm] = srtm_err(psrtm,Ct0,t0,Cr0,w); > BPndNL = psrtm(2)/psrtm(3)-1; > > k3Init = .35; > paramsInit = [beta(1) abs(beta(2)) k3Init k3Init/abs(BPnd0)]; > paramsInit = [beta(1) .066 0.3 0.06]; > params = fminsearch('frtm_err',paramsInit,[],Ct0,t0,Cr0,w); > [err CtHat] = frtm_err(params,Ct0,t0,Cr0,w); > BPndF = params(3)/params(4); > k2aF = params(2)/(1+BPndF); > betaF = [params(1:2) k2aF]'; > yhatF = X0*betaF; > > plot(t0,Ct0,t0,CtHat,t0,CtHatSRTM,t0,CtHatsrtm); > legend('Data','FRTM','SRTM','NL-SRTM') > > > > > when I typed the type of the output volume, there were some > errors. > > /usr/local/freesurfer/bin/mri_convert.linux --out_type nii > I0001.dcm s105.run1.nii/ > /usr/local/freesurfer/bin/mri_convert.linux --out_type nii > I0001.dcm s105.run1.nii/ > $Id: mri_convert.c,v 1.196 2012/07/11 17:50:50 fischl Exp $ > reading from I0001.dcm... > Getting Series No > Scanning Directory > INFO: Found 230 files in /home/fsl/data/emotion/s105/run1 > INFO: Scanning for Series Number 3 > INFO: found 228 files in series > INFO: loading series header info. > > INFO: sorting. > RunNo = 2 > INFO: ( 64 64 32), nframes = 228, ismosaic=1 > Could not parse NUMARIS version string syngo MR B17 > found in dicom tag 18,1020 (len = 3 != 6) > Repetition Time = 2000, TR = 2000 ms > PE Dir COL COL > AutoAlign matrix detected > AutoAlign Matrix --------------------- > 1.000 0.000 0.000 0.000; > 0.000 1.000 0.000 0.000; > 0.000 0.000 1.000 0.000; > 0.000 0.000 0.000 1.000; > > FileName /home/fsl/data/emotion/s105/run1/I0001.dcm > Identification > NumarisVer syngo MR B17 > ScannerModel TrioTim > PatientName LuoYangmei_s5^caoguoguo > Date and time > StudyDate 20121009 > StudyTime 084434.968000 > SeriesTime 090357.640000 > AcqTime 090309.732500 > Acquisition parameters > PulseSeq *epfid2d1_64 > Protocol run1 > PhEncDir COL > EchoNo 1 > FlipAngle 90 > EchoTime 30 > InversionTime -1 > RepetitionTime 2000 > PhEncFOV 192 > ReadoutFOV 192 > Image information > RunNo 2 > SeriesNo 3 > ImageNo 1 > NImageRows 384 > NImageCols 384 > NFrames 228 > SliceArraylSize 32 > IsMosaic 1 > ImgPos 99.3735 107.4917 -33.8349 > VolRes 3.0000 3.0000 3.9900 > VolDim 64 64 32 > Vc -1.0000 -0.0000 0.0000 > Vr -0.0000 -0.9999 0.0105 > Vs -0.0000 0.0105 0.9999 > VolCenter 3.3735 12.1655 31.0069 > TransferSyntaxUID 1.2.840.10008.1.2 > UseSliceScaleFactor 0 (slice 0: 1) > sagrev = 0, correv =1, trarev = 1 > Vs = -0 0.0104718 0.999945 > INFO: detected a Siemens slice order reversal in mosaic, so > I'm going to reverse them back to their 'original' order. > TR=2000.00, TE=30.00, TI=-1.00, flip angle=90.00 > i_ras = (-1, -0, 0) > j_ras = (-0, -0.999945, 0.0104718) > k_ras = (-0, 0.0104718, 0.999945) > writing to s105.run1.nii/... > niiWrite(): error opening file s105.run1.nii/ > ERROR: failure writing s105.run1.nii/ as volume type 24 > > > > > > On Mon, Nov 12, 2012 at 3:29 PM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>> wrote: > > /Run this command line instead > mri_convert.linux I0001.dcm s105.run1.nii/ > doug > > On 11/09/2012 01:57 PM, Yangmei LUO wrote: > > Hi Dr, Douglas, > > > I attached the capture of the result using fslview. > > Thanks very much! > > Yangmei > > On Fri, Nov 9, 2012 at 12:51 PM, Yangmei LUO > <yangmeiluo(a)gmail.com <mailto:yangmeiluo@gmail.com> > <mailto:yangmeiluo@gmail.com <mailto:yangmeiluo@gmail.com>> > <mailto:yangmeiluo@gmail.com <mailto:yangmeiluo@gmail.com> > <mailto:yangmeiluo@gmail.com <mailto:yangmeiluo@gmail.com>>>> > > wrote: > > Hi Dr.Douglas, > > Thanks very much for your patient help. > MRI_convert can > work. It > is great. However, there was another problem about the > convert. > The results of the convert is unknown file and > there is a > warning. > Could you help me again? > > This the command : > //usr/local/freesurfer/bin/mri_convert.linux > --in_type dicom > --out_type nii I0001.dcm s105.run1.nii/ > > The result is: > > //usr/local/freesurfer/bin/mri_convert.linux > --in_type dicom > > --out_type nii I0001.dcm s105.run1.nii > $Id: mri_convert.c,v 1.196 2012/07/11 17:50:50 > fischl Exp $ > reading from I0001.dcm... > Starting DICOMRead2() > dcmfile = /home/fsl/data/emotion/s105/run1/I0001.dcm > dcmdir = /home/fsl/data/emotion/s105/run1 > Ref Series No = 3 > Found 231 files, checking for dicoms > Found 228 dicom files in series. > First Sorting > Computing Slice Direction > > > WARNING: it appears that the image position for all > slices is the > same. > This is a problem with the DICOM file. Using > direction > cosines > from col and row > to compute slice direction, but the output may be > misoriented. > > Vs: 0 -0.0104718 0.999945 > Vs: 0 -0.0104718 0.999945 > Second Sorting > Counting frames > nframes = 228 > nslices = 1 > ndcmfiles = 228 > PE Dir = COL (dicom read) > TransferSyntaxUID: --1.2.840.10008.1.2-- > Loading pixel data > TR=2000.00, TE=30.00, TI=0.00, flip angle=90.00 > i_ras = (-1, -0, 0) > j_ras = (-0, -0.999945, 0.0104718) > k_ras = (-0, 0.0104718, 0.999945) > writing to s105.run1.nii.../ > > > > Thank you so much! > > Best regards, > Yangmei > > > > > > On Fri, Nov 9, 2012 at 12:29 PM, Douglas N Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>>> wrote: > > run these two lines then try again > chmod a+x mri_convert > reshash. > > > On 11/09/2012 01:04 PM, Yangmei LUO wrote: > > Hi Dr. Douglas, > > Thanks for your kind help. The version of > freesurfer is > stable v5.1.0 on CentOS 4 (32b). When I > download the > updated version you provided and switch > the file > in the > bin( I do not know what I did is correct). > When I > run the > command, the terminal appeared "permission > denied". > > What can I do next? > > Thanks so much! > > Best, > Yangmei > > > > > On Fri, Nov 9, 2012 at 11:29 AM, Douglas N > Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>>>> wrote: > > The name is not important. I was able to > convert all > of those > files without a problem. What version > are you > using? > Maybe try an > updated version of mri_convert > ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/mri_convert.l… > > Also, please remember to include previous > correspondences in your > email to me. I always delete the > emails once I > answer > them. > thanks > doug > > > > On 11/09/2012 12:19 PM, Yangmei LUO wrote: > > > Hi Douglas, > > Thank you for your help. I change > the name > of the > dicom file > in order to process conveniently. > So, I > attached > two files of > with origin name and two files > with the > changed > name. I wish > it could help you figure out the > problem. > > > Thanks a million! > > > Best, > > > Yangmei > > > -- Douglas N. Greve, Ph.D. > MGH-NMR Center > greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>>> > Phone Number: 617-724-2358 > <tel:617-724-2358> <tel:617-724-2358 <tel:617-724-2358>> > <tel:617-724-2358 <tel:617-724-2358> <tel:617-724-2358 > <tel:617-724-2358>>> > <tel:617-724-2358 <tel:617-724-2358> <tel:617-724-2358 > <tel:617-724-2358>> <tel:617-724-2358 <tel:617-724-2358> > <tel:617-724-2358 <tel:617-724-2358>>>> > Fax: 617-726-7422 <tel:617-726-7422> > <tel:617-726-7422 <tel:617-726-7422>> > <tel:617-726-7422 <tel:617-726-7422> <tel:617-726-7422 > <tel:617-726-7422>>> <tel:617-726-7422 <tel:617-726-7422> > <tel:617-726-7422 <tel:617-726-7422>> > > <tel:617-726-7422 <tel:617-726-7422> <tel:617-726-7422 > <tel:617-726-7422>>>> > > > Bugs: > surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > FileDrop: > www.nmr.mgh.harvard.edu/facility/filedrop/index.html > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > > > > > 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. > > > > -- Douglas N. Greve, Ph.D. > MGH-NMR Center > greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>>> > Phone Number: 617-724-2358 <tel:617-724-2358> > <tel:617-724-2358 <tel:617-724-2358>> > <tel:617-724-2358 <tel:617-724-2358> <tel:617-724-2358 > <tel:617-724-2358>>> > Fax: 617-726-7422 <tel:617-726-7422> > <tel:617-726-7422 <tel:617-726-7422>> <tel:617-726-7422 > <tel:617-726-7422> > <tel:617-726-7422 <tel:617-726-7422>>> > > Bugs: > surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > FileDrop: > www.nmr.mgh.harvard.edu/facility/filedrop/index.html > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > > > > > -- Douglas N. Greve, Ph.D. > MGH-NMR Center > greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > <mailto:greve@nmr.mgh.harvard.edu > <mailto:greve@nmr.mgh.harvard.edu>> > Phone Number: 617-724-2358 <tel:617-724-2358> > <tel:617-724-2358 <tel:617-724-2358>> > Fax: 617-726-7422 <tel:617-726-7422> <tel:617-726-7422 > <tel:617-726-7422>> > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > FileDrop: > www.nmr.mgh.harvard.edu/facility/filedrop/index.html > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > > > > -- > Douglas N. Greve, Ph.D. > MGH-NMR Center > greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> > Phone Number: 617-724-2358 <tel:617-724-2358> > Fax: 617-726-7422 <tel:617-726-7422> > > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting > <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> > FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> > > -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(a)nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

1 0

volume conversion problem
by Gabriel Gonzalez Escamilla 13 Nov '12

13 Nov '12

2 3

gstrobbe@ggmail.com, analysis-bugs@nmr.mgh.harvard.edu
by Azeez Adebimpe 13 Nov '12

13 Nov '12

Hi Freesurferers or Experts, I have been trying to convert the watershed bem brain surfaces to vol with mri_fill and mri_surf2vol but not succeed. My main aim is to create mask for outer_skull, inner_skull and other from their respective surfaces. Is there any other method to use? Azeez Azeez Adebimpe

2 1

Phase Encoding Direction and epidewarp.fsl
by Clark Fisher 13 Nov '12

13 Nov '12

Hi everyone, I recently switched the phase encoding direction of the functional sequence I've been using from F >> H to R >> L and ran into a problem with epidewarp.fsl (in version 4). The unwarping was still happening along the F >> H axis in the new images where phase encoding was R >> L. (Note: I'm working with NHPs in sphinx position, but I'll describe my problem in standard coordinates to keep everything somewhat simpler) Because thought that epidewarp.fsl might be having a difficult time determining the phase encoding direction, I swapped the position of the F >> H and R >> L dimensions in my nifti file (going from LIP to IRP) and the dewarping now seems to work. Is there something going wrong in the unpacking such that the phase encoding information is lost? Also, is the phase encoding information stored anywhere in the nifti, so that I can automatically detect and correct cases like this? Thanks for the help, Clark

3 3

contrast matrix
by xiangbo_2010 13 Nov '12

13 Nov '12

Hi Freesurfer experts, I'm very sorry to bother you, but I am very confused with the following questions: My experimental design includes two discrete factors: genotype with three levels (GG,GA,AA ); gender (F, M), and one covariate. So I can get 6 classes: MGG, MGA,MAA, FGG,FGA,FAA. 1) I want to perform the difference between any of the genotype leves analysis with regressing out the effect of gender and one covariate, but I don't know the rules for setting the contrasts for the F-test. The contrast matrix I used is: [1 -1 0 1 -1 0 0 0 0 0 0 0 ]/2 [1 0 -1 1 0 -1 0 0 0 0 0 0 ]/2 is it correct? Any help will be very appreciated. Best wishes, Bo Xiang

2 1

error in analyze command failed: mri_concat
by Berg, S.F. van den 13 Nov '12

13 Nov '12

Hello Freesurfer experts, I have got some problems with qdec. For testing my data i make an design with age, sexe and right and left hippocampus. The same design as the tutorial on the freesurfer wiki. When starting anlalyze i get an Error in Analyze: command failed: mri_concat /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0050/surf/lh.volume.fwhm10.fsaverage.mgh. surf is the map with the smoothings. The correct smoothings file. In this design is 10 is correctly presented in the map surf. Thanks, Stan lh-Avg-Intercept-volume ----------------------- Does the average volume differ from zero? 1.000 1.000 0.000 0.000; lh-Avg-volume-Left-Hippocampus-Cor ----------------------- Does the correlation between volume and Left-Hippocampus, accounting for gender, differ from zero? 0.000 0.000 1.000 1.000; lh-Diff-male-female-Intercept-volume ----------------------- Does the average volume differ between male and female? 1.000 -1.000 0.000 0.000; lh-Diff-male-female-Cor-volume-Left-Hippocampus ----------------------- Does the volume--Left-Hippocampus correlation differ between male and female? 0.000 0.000 1.000 -1.000; ninputs = 9 Checking inputs reading MRI_FRAME structure from file... Error in Analyze: command failed: mri_concat /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0050/surf/lh.volume.fwhm10.fsaverage.mgh /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0051/surf/lh.volume.fwhm10.fsaverage.mgh /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0054/surf/lh.volume.fwhm10.fsaverage.mgh /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0060/surf/lh.volume.fwhm10.fsaverage.mgh /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0062/surf/lh.volume.fwhm10.fsaverage.mgh /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0064/surf/lh.volume.fwhm10.fsaverage.mgh /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0067/surf/lh.volume.fwhm10.fsaverage.mgh /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0075/surf/lh.volume.fwhm10.fsaverage.mgh /data1/projects/ysbrand-vumc/pddatabase-freesurfer/0080/surf/lh.volume.fwhm10.fsaverage.mgh --o /data1/projects/ysbrand-vumc/pddatabase-freesurfer/qdec/hippocampus/y.mgh

2 1

segmentation problem.
by youngmin huh 13 Nov '12

13 Nov '12

Hi I'm working with some images, and freesurfer didn't properly detect some of their white matter boundaries. I attached some examples. I ran recon2 with expert options(-b 20 -n 5). As you can see, they have inaccurate white matter boundaries in curved area. I think it's not that highly curved, though. Any comment will be appreciated. Thanks, Youngmin Huh [image: 본문 이미지 2][image: 본문 이미지 1]

2 3

Fw:contrast matrix
by Meng Li 13 Nov '12

13 Nov '12

Hi Freesurfer experts, I'm very sorry to bother you, but I am very confused with the following questions: My experimental design includes 3 discrete factors: diagnosis with two levels (A, B); genotype with two levels (G, T); gender (F, M), and two covariates. So I can get 8 classes: AGF, AGM, ATF,ATM, BGF, BGM, BTF, BTM. 1) I want to perform 2 (diagnosis)* 2(genotype) interaction analysis with regressing out the effect of gender and two covariates, but I don't know the rules for setting the contrasts for the interaction. The contrast matrix I used is: 0.25 0.25 -0.25 -0.25 -0.25 -0.25 0.25 0.25 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 is it correct? If it is correct, how to explain the results, for example, what does the positive (or negative) clusters stand for? Or the clusters showed in the t-test statistical map are the regions that have the significant interaction? 2) When I perform the main effect of dignosis, is the following matrix I used correct? 0.25 0.25 0.25 0.25 -0.25 -0.25 -0.25 -0.25 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (I think it regressed out the effect of genotype and gender, that is it takes the genotype as a covariable) Or I should create another fsgd file, that has 4 classes: AF, AM, BF, BM. And I can use the matrix (0.5 0.5 -0.5 -0.5 0 0 0 0 0 0 0 0) to perform the main effect of diagnosis. which one is right? Any help will be very appreciated. Best wishes, Meng Li

2 2

The mismatched color in the tksurfer color bar for surface file
by Longchuan Li 12 Nov '12

12 Nov '12

Hi, Doug and other FreeSurfer experts: I noticed that the color in a surface file I generated (*.mgh with the values ranging from 0 to 1) does not match that in the color bar (see attached Fig for an example). For example, the low values in the surface file (dark red) are obviously darker than that in the lowest values in the color bar (much brighter red). Is there any remedy for this mismatch? Thank you in advance! Longchuan

2 2

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