Freesurfer August 2014

freesurfer@nmr.mgh.harvard.edu

146 participants
208 discussions

head surface
by Meryem Ayse Yucel 21 Aug '14

21 Aug '14

Hi freesurfer community, I am trying to get faces and vertices of the head surface mesh in Matlab. freesurfer_read_surf works perfectly when I extract faces and vertices for the pial surface (from lh.pial), but I get an "unknown magic number in surface file" error when I use the same function for lh.seghead (which I assume is the head surface?). Any help on what I am doing wrong? Thanks! Meryem

2 1

GLM: Error Matric-Scale
by Robby De Pauw 21 Aug '14

21 Aug '14

Hi there FreeSurfer When trying the GLM-analysis I keep getting the following error. Could you help me with fixing it? ERROR: matrix is ill-conditioned or badly scaled, condno = 1e+08 -------------------------------- Possible problem with experimental design: Check for duplicate entries and/or lack of range of continuous variables within a class. If you seek help with this problem, make sure to send: 1. Your command line: mri_glmfit --y lh.whiplash.thickness.10B.mgh --fsgd whiplash.fsgd dods --C group_diff.mtx --surf fsaverage lh --cortex --glmdir lh.whiplash.glmdir 2. The FSGD file (if using one) 3. And the design matrix above Thank you in advance, Robby Robby De Pauw, dra. Ghent University Department of Physiotherapy and Rehabilitation Sciences 3B3 De Pintelaan 185 B-9000 Ghent Robby.DePauw(a)Ugent.be

2 2

FLAIR Registration Problems
by Zamroziewicz, Marta Karolina 21 Aug '14

21 Aug '14

Hello, This email is related to the archived “bbregister and FLAIR” email chain posted by Kayle Sawyer on 5/23/2014 (http://www.mail-archive.com/freesurfer%40nmr.mgh.harvard.edu/msg36117.html) We have also been registering with FLAIR scans, and have run into a problem with approximately half of our subjects. Recon-all completes successfully but a bad registration step leaves our MPRAGE and FLAIR scans misaligned. I’ve attached two screenshots, the first of which shows a bad registration and the second of which shows a good registration. Per your previous suggestion, we ran bbregister using the following flag: bbregister --s SLOTS007 --mov flair.mgz --init-header --reg reg.test.dat --t2 --lta reg.test.lta This did result in a good registration, and we are hoping to incorporate this into our processing pipeline to ensure that we can use the FLAIR for refining the pill surface. The problem that we’ve run into is that we aren’t sure at which point this bbregister step occurs within the recon-all process flow. We were thinking there are a couple of possibilities: 1. manually create the transformation matrix for the FLAIR using the command mentioned above, and then re-run whichever steps necessary in recon-all to include this manually created xform; 2. apply the manually created xform to the mri/orig/FLAIRraw.mgz image to create a new, properly aligned mri/FLAIR.mgz, and then re-run recon-all with whatever steps/flags we need to include this FLAIR image to refine the pial surface. Unfortunately we're not exactly sure which flags to include in recon-all in order to most efficiently re-process our data with the manually created FLAIR transformation, and we were hoping you might offer some advice on this point. Please let me know if I can provide any additional information. Thanks for your time and assistance! [cid:D837E275-197C-46BB-A1D4-B7559DF58D48@beckman.uiuc.edu][cid:D62F65DB-AF9A-4ADC-A596-79E0821DE24D@beckman.uiuc.edu] Marta Zamroziewicz MD/PhD Candidate Decision Neuroscience Laboratory University of Illinois Urbana-Champaign mzamro2(a)illinois.edu<mailto:mzamro2@illinois.edu> 815-980-3882

2 5

FreeSurfer platform/performance questions
by Lazarevich, Alexander 21 Aug '14

21 Aug '14

Hello FreeSurfer mailing list, First off, I am not a scientist and I have no experience running FreeSurfer. I have installed it, and seen it run, but that's it. I work for the IT department in the Beckman Institute, part of the University of Illinois. We support a computer lab here called the "Visualization Laboratory" - aka Vislab. (http://itg.beckman.illinois.edu/visualization_laboratory/) The Vislab lab has dozens of very nice workstations in it. (16 x 3GHz Xeon cores, 128GB of mem, NVIDIA Quadro K6000 video, etc.) In short, the Vislab supports research which needs high end computing. (less power than supercomputers, but much better than normal desktops and much easier to access/use than supercomputers) The Vislab has hundreds of active users, students, faculty, postdocs, etc., all of whom do some kind of scientific research. One of the packages we have recently installed upon request is FreeSurfer. We have installed freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0.tar.gz<ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0/freesurfer-Linux…> on our Red Hat Enterprise Linux 6 workstations, as well as on our Windows 7 Enterprise 64bit workstations. We have also installed Oracle's VirtualBox on a Windows 7 Enterprise 64bit machine, and run the VM freesurfer-Virtualbox-linux-x86-stable-pub-v5.3-full.vdi.gz<ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0/freesurfer-Virtu…> inside that virtual environment. The researchers who requested FreeSurfer are all part of the same group, and they are trying to complete a very large research project which requires FreeSurfer to process large amounts of data. They have normally been running FreeSurfer on the VM in the XUbuntu VirtualBox environment on their own average desktop PC's. However, they are concerned about their processing time with FreeSurfer, so they are hoping to take advantage of the Vislab computing resources to decrease the processing time in FreeSurfer. We are running into the following problems/concerns: 1) The FreeSurfer VM (Xubuntu) that runs in VirtualBox is a 32bit host. Is there a 64bit VM available? That 32bit host can only access 4GB of memory, whereas they would like to be able to access more of the workstations 128GB of memory. 2) The users have expressed concern about switching platforms to Red Hat Enterprise Linux6 with the FreeSurfer freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0.tar.gz<ftp://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/5.3.0/freesurfer-Linux…> installed. They have told us that FreeSurfer on XUbuntu might give different results than if it were run on Red Hat Enterprise Linux 6, given the same dataset. They are concerned about switching platforms in the middle of the research study, and that it might contaminate results. Is this possible? Or should the same version of FreeSurfer provide the same results, even with a different platform? 3) Does anyone else on this list run very large FreeSurfer processes on high end 64bit computers? If a high-end processing method works well for you, I would love to hear about it so I can share it with the researchers here. Thanks for your time! ____________ Alex Lazarevich 5321 Beckman Institute - 217-244-1565 Information Technology Services - http://its.beckman.illinois.edu<http://its.beckman.illinois.edu/> Beckman Institute - http://beckman.illinois.edu<http://beckman.illinois.edu/> University of Illinois - http://illinois.edu<http://illinois.edu/>

3 6

no improvement for recon-all result after edits
by Jidan Zhong 21 Aug '14

21 Aug '14

Hi Freesurfer experts, I was doing some manual editing on our subjects which are patients with lesions. I managed to correct most of them, however, 4 subjects have the same problem that I can't fix no matter what edits I tried. So, the 4 subjects, they all have the same problem, which is: frontal part of superior temporal gyrus region is not segmented as white matter, thus they are just "missing" from the final surfaces and final segmentations. But when just do eye check, there is nothing wrong with this part, even the intensity looks the same of other white matter parts.Its just cut suddenly. When I went back to those subjects, first I tried with control points. - It didnt help. I confirmed that white matter is present connected to the main brain white matter volume. -- I reran from recon-all autorecon2-wm, didnt help. Then I checked the aseg.mgz, that part is segmented as white matter correctly. I even modified the aseg.mgz (although not suggested), it still didn't work It is just weird that the surface was just cut from the middle of STG. So, is there any other way I can tell FreeSurfer that this is really STG and please keep it? Thanks!! -- Regards, Jidan

3 3

Creating lower resolution surface models
by Nicholas Heugel 21 Aug '14

21 Aug '14

I am running analysis where I am taking fMRI data using Freesurfer to project it onto the cortical surface and load it into Brainstorm to use as a constraint on the source reconstruction. I am able to do all the steps just fine, the problem I am encountering is that Freesurfer creates a surface with 200,000+ vertices, for the analysis I am running I downsample it in brainstorm to 15,000 vertices to reduce run time. However, when the label file for Freesurfeer gets down sampled it significantly changes how the scouts look. Is there a way to have Freesurfer create a surface with 15000 vertices and then project the volumetric fMRI onto that surface so I don't have to downsample the data? I know there is the function fmris_decimate, which should allow me to decimate targeted files. But I am not sure if I can then use mdi_vol2surf to put the fMRI data onto the decimated surface files, or if I need to have the entire surface file generated from the beginning with only 15,000 vertices. Can I use the recon-all function to define the number of vertices I want, or is that a variable I can't adjust? Any help in the matter would be appreciated. Nicholas

2 1

Fwd: mpr2mni305 failed error
by Francesco Deleo 21 Aug '14

21 Aug '14

---------- Forwarded message ---------- From: Francesco Deleo <franc.deleo(a)gmail.com> Date: 2014-08-08 18:06 GMT+02:00 Subject: Re: [Freesurfer] mpr2mni305 failed error To: freesurfer <freesurfer(a)nmr.mgh.harvard.edu> It is not ok... It seems to have a contrast problem... I can send a snapshot, or if you want I can send the rawavg.mgz Francesco 2014-08-08 17:53 GMT+02:00 Bruce Fischl <fischl(a)nmr.mgh.harvard.edu>: what does the rawavg.mgz look like? If it is ok, can you email it to us? > > On Fri, 8 Aug 2014, Francesco Deleo wrote: > > Thank you all for attention and help! >> Maybe we're finding the problem: in cases I received the mpr2mni305 error >> the orig.mgz is unintelligible (it is white with some black point). But my >> dicoms are ok (I've checked!). I've already tried converting dicom to tiff >> but I got the same error message and the same unintelligible orig.mgz (and >> the tiff are ok too!). >> So I think the likely problem is in the recon-all -i command! >> Any idea? >> >> It remains a mistery for me why I have this problem only in some (and not >> in >> every one) MRI scans even if all the parameters are the same. >> >> thanks again >> >> Francesco >> >> >> 2014-08-07 17:16 GMT+02:00 Douglas N Greve <greve(a)nmr.mgh.harvard.edu>: >> Have you looked in transforms/talairach_avi.log? >> >> On 08/07/2014 07:57 AM, Francesco Deleo wrote: >> > Thank you Doug! >> > but i tried it in many cases but I've always received the same >> error >> > message... >> > Is there something else I can try? >> > >> > Francesco >> > >> > >> > 2014-08-07 0:46 GMT+02:00 Douglas N Greve >> <greve(a)nmr.mgh.harvard.edu >> > <mailto:greve@nmr.mgh.harvard.edu>>: >> > >> > Try it with -notal-check >> > doug >> > >> > On 08/06/2014 04:39 PM, Francesco Deleo wrote: >> > > I all! >> > > >> > > I am a new freesurfer user. >> > > I have a problem when I perform the recon-all -all, in about >> 15% of >> > > MRI scans, all made with the same scanning protocol (T1 MPRAGE >> in a >> > > SIEMENS Avanto 1,5 T). >> > > >> > > I can't recognize any difference between those scans which >> work >> > > correctly and those not. >> > > I have never found the same error on 3T MRI scans. >> > > >> > > I've already tried to add these flags to the recon-all -all >> command: >> > > -use-mritotal >> > > -talairach -use-mritotal >> > > -notalairach >> > > but I've always received an error message >> > > >> > > Thank you very much >> > > >> > > ERROR: mpr2mni305 failed, see transforms/talairach_avi.log >> > > Darwin pro-di-villani.besta.local 13.3.0 Darwin Kernel Version >> > 13.3.0: >> > > Tue Jun 3 21:27:35 PDT 2014; >> > root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64 >> > > >> > > Thanks very much for your attention >> > > >> > > Francesco >> > > Milan, Italy >> > > >> > > >> > >> --------------------------------------------------------------------- >> > > >> > > FREESURFER_HOME: /Applications/freesurfer >> > > >> > > Build stamp: freesurfer-Darwin-lion-stable-pub-v5.3.0 >> > > >> > > Kernel info: Darwin 13.3.0 x86_64 >> > > >> > > >> > >> --------------------------------------------------------------------- >> > > >> > > >> > > LAST LINES IN TALAIRACH_AVI.LOG >> > > >> > > parameters >> > > 9.0270 134.9373 110.8627 -84.3566 -7.5458 -11.3475 >> > > eta,q 0.95791 3.72402 >> > > 0.0485 0.0470 0.0477 0.0513 0.0470 0.0452 >> > > 0.0475 0.0471 0.0478 0.0513 0.0457 0.0435 >> > > 0.0472 0.0472 0.0476 0.0428 0.0434 0.0415 >> > > 0.0471 0.0471 0.0476 0.0435 0.0430 0.0415 >> > > 0.0470 0.0478 0.0457 0.0525 0.0415 0.0430 >> > > 0.0473 0.0511 0.0430 0.0548 0.0442 0.0453 >> > > 0.0486 0.0426 0.0406 0.0672 0.0431 0.0503 >> > > niter,ni,del,rscale 7 3 12.0000 1.2000 >> > > imgrege: no voxels in register >> > > ERROR: 'imgreg_4dfp >> > > /Applications/freesurfer/average/711-2C_as_mni_average_305 >> > > >> /Applications/freesurfer/average/711-2B_as_mni_average_305_mask >> > > talsrcimg_g11 none talsrcimg_to_711-2C_as_mni_average_305_t4 >> 1283' >> > > failed! status=254 >> > > ERROR: mpr2mni305 execution aborted >> > > >> > > >> > > _______________________________________________ >> > > Freesurfer mailing list >> > > Freesurfer(a)nmr.mgh.harvard.edu >> > <mailto:Freesurfer@nmr.mgh.harvard.edu> >> > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> > >> > -- >> > 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: https://gate.nmr.mgh.harvard.edu/filedrop2 >> > www.nmr.mgh.harvard.edu/facility/filedrop/index.html >> > <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >> > Outgoing: >> > ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ >> > >> > _______________________________________________ >> > Freesurfer mailing list >> > Freesurfer(a)nmr.mgh.harvard.edu >> <mailto:Freesurfer@nmr.mgh.harvard.edu> >> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> > >> > >> > 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 mailing list >> > Freesurfer(a)nmr.mgh.harvard.edu >> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> -- >> 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: https://gate.nmr.mgh.harvard.edu/filedrop2 >> www.nmr.mgh.harvard.edu/facility/filedrop/index.html >> Outgoing: >> ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer(a)nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> >> > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > 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. > >

2 3

CBF map computed on surface and projected on fsaverage
by Matthieu Vanhoutte 21 Aug '14

21 Aug '14

Dear experts, I try to project on fsaverage CBF maps computed on surface, but when trying to look at the mri_info of the output file "meanCBF_0_s1.5asl.rem.mc.s6.fsaverage.lh.nii" I got this error : *niiRead(): bad number of dimensions (13734) in /home/matthieu/NAS/pierre/Epilepsy/FreeSurfer5.0/Patients_fmri_dti//Delforterie_Julien/asl_COR_PVEnew/meanCBF_0_s1.5asl.rem.mc.s6.fsaverage.lh.nii* Here below the command lines used : *# CBF map * *computed on surface**# fsaverage & lh* *mri_surf2surf --srcsubject Delforterie_Julien --srchemi lh --srcsurfreg sphere.reg --trgsubject fsaverage --trghemi lh --trgsurfreg sphere.reg --sval meanCBF_0_s1.5asl.rem.mc.s6.lh.nii --sfmt curv --noreshape --no-cortex --tval meanCBF_0_s1.5asl.rem.mc.s6.fsaverage.lh.nii --tfmt curv* You can find data file joined to this mail. Thanks in advance for helping ! Best regards, ------------------------------------- Matthieu Vanhoutte, MSc Research Engineer - Department of Neuroradiology Regional University Hospital, Lille, France

2 2

mri_tessellate: max vertices 1000000 exceeded
by Michiel Kleinnijenhuis 20 Aug '14

20 Aug '14

Hi, While doing a high resolution ex vivo recon job, I came across the error mri_tessellate: max vertices 1000000 exceeded As mentioned in the threads http://www.mail-archive.com/freesurfer%40nmr.mgh.harvard.edu/msg35305.html<http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg35305.html> http://www.mail-archive.com/freesurfer%40nmr.mgh.harvard.edu/msg31331.html<http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg31331.html> there seems to be an easy fix. Does anyone have a compiled version of mri_tesselate with the vertex limit relaxed; for Mac (freesurfer-Darwin-lion-stable-pub-v5.3.0)? Thanks! Michiel Kleinnijenhuis == Michiel Kleinnijenhuis Postdoctoral researcher FMRIB Centre Nuffield Department of Clinical Neurosciences University of Oxford

3 2

Open MP parallel processing scaling factor?
by O'Shea,Andrew 20 Aug '14

20 Aug '14

Hello all, Traditionally I have only processed FS data using a single core per person, but processing many people at once. Now we have caught up with the backlog of scans, we have a continuos trickle of scans coming in 1 by 1. I was wondering if anyone has tested how the speed-up of open-mp varies with number of cores used simultaneously. For example how much faster is using 100 cores versus 10? I am trying to find a sweet spot of resource usage and speed. Thanks! -Andrew

3 3

← Newer
1
...
7
8
9
10
11
12
13
...
21
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 August 2014