glad it worked out Bruce On Fri, 22 Jul 2016, vars...@cns.iisc.ernet.in wrote:
> Hi Bruce, > > Thank you for your suggestion. I managed to figure out how to generate the > right look-up table. I realised that the indices for the left and right > hemispheres have 1000 and 2000 added to them. I created a look-up table > with the right indices and it worked fine. Thank you. > > Regards, > Varsha >> >> >> >>> Message: 17 >>> Date: Thu, 21 Jul 2016 09:31:57 -0400 (EDT) >>> From: Bruce Fischl <fis...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] Combined parcellation of the left and right >>> hemispheres >>> To: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <alpine.lrh.2.20.1607210931470.14...@door.nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset=US-ASCII; format=flowed >>> >>> Hi Varsha >>> >>> try using mri_aparc2aseg >> >> Hi Bruce, >> >> I tried using mri_aparc2aseg. While it gives me one volume file as I >> wanted, the indices on the volume don't seem to correspond to the look-up >> table that I created. I created the look-up table from the annotation >> files for the left and right hemispheres, appropriately changing the >> indices to make it a continuous list of ROIs. >> >> Regards, >> Varsha >> >>> cheers >>> Bruce >>> On Thu, 21 Jul 2016, vars...@cns.iisc.ernet.in >>> wrote: >>> >>>> >>>> Hi, >>>> >>>> I've been working on getting a finer parcellation of the >>>> Desikan-Killiany >>>> atlas using mris_divide_parcellation. I was able to generate two >>>> annotation files; one each for the left and right hemisphere. I want to >>>> create a volume similar to aparc+aseg.mgz, containing the labels and >>>> indices of the ROIs from both hemispheres. I tried using mri_label2vol. >>>> However, this gives me two separate volumes for the left and right >>>> hemispheres. Is there a way to combine these volumes into one? >>>> Alternatively, can one generate such a volume form an annotation file >>>> that >>>> has information of both hemispheres? >>>> >>>> Any help is greatly appreciated! >>>> >>>> Regards, >>>> Varsha >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> Freesurfer@nmr.mgh.harvard.edu >>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>>> >>>> >>>> >>> >>> >>> ------------------------------ >>> >>> Message: 18 >>> Date: Thu, 21 Jul 2016 09:33:29 -0400 (EDT) >>> From: Bruce Fischl <fis...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] Freesurfer build stamps do not match >>> To: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <alpine.lrh.2.20.1607210932310.14...@door.nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset=US-ASCII; format=flowed >>> >>> Hi Subin >>> >>> it looks more likely that you just don't have write access to your >>> SUBJECTS_DIR. Can you check that with ls -l? Or maybe you just haven't >>> set >>> it and it still points to the one we distribute? Typically you want to >>> set >>> the SUBJECTS_DIR env variable to some other directory where you will >>> store >>> all the subjects in a study. >>> >>> cheers >>> Bruce >>> >>> >>> On Thu, 21 Jul 2016, Lee >>> Subin Kristine wrote: >>> >>>> >>>> Hi FreeSurfer Team, >>>> >>>> >>>> After I have downloaded the FreeSurfer dev version, I get the following >>>> error >>>> whenever I use the recon-all comand: >>>> >>>> >>>> mkdir: cannot create directory '/usr/local/freesurfer/subjects/NYS': >>>> Permission >>>> denied >>>> mkdir: cannot create directory '/usr/local/freesurfer/subjects/NYS': >>>> Permission >>>> denied >>>> mkdir: cannot create directory '/usr/local/freesurfer/subjects/NYS': >>>> Permission >>>> denied >>>> cp: cannot create regular file >>>> '/usr/local/freesurfer/subjects/NYS/scripts/build-stamp.txt': No such >>>> file or >>>> directory >>>> cat: /usr/local/freesurfer/subjects/NYS/scripts/build-stamp.txt: No >>>> such >>>> file or >>>> directory >>>> INFO: FreeSurfer build stamps do not match >>>> Subject Stamp: >>>> Current Stamp: freesurfer-Linux-centos6_x86_64-dev-20160611-876a0e6 >>>> /usr/local/freesurfer/subjects/NYS/scripts/patchdir.txt: No such file >>>> or >>>> directory. >>>> >>>> recon-all used to work fine when I used the stable 5.3 version. >>>> I think it may have something to do with the fact that I previously ran >>>> recon-all >>>> in v.5.3, and so the current subject directory's stamp is still 5.3 (or >>>> blank..) >>>> and it does not match the current stamp of the dev version? I am not >>>> sure.. >>>> Could anyone tell me how I can fix this problem? >>>> >>>> Thanks in advance, >>>> Subin >>>> >>>> >>>> >>> >>> >>> ------------------------------ >>> >>> Message: 19 >>> Date: Thu, 21 Jul 2016 09:35:35 -0400 (EDT) >>> From: Bruce Fischl <fis...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] Subtracting overlays >>> To: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <alpine.lrh.2.20.1607210933500.14...@door.nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset="iso-8859-15" >>> >>> Hi Tobias >>> >>> yes, mris_calc should do it. If you give the output extension .mgz it >>> will >>> save in that format instead of curv I believe (and will work fine as an >>> overlay) >>> >>> cheers >>> Bruce >>> >>> >>> On Thu, 21 Jul 2016, Granberg, Erik Tobias wrote: >>> >>>> Hi,? >>>> Is there a way to subtract one surface overlay from another (for >>>> example >>>> in >>>> fsaverage) and still having the output being an .mgh overlay file?? >>>> I saw that mis_calc does a similar procedure but automatically outputs >>>> the result >>>> as out.mgz.? >>>> >>>> Thank you for the help!? >>>> >>>> Kind regards, >>>> Tobias >>>> ? >>>> _________________________________________? >>>> Tobias Granberg, MD, PhD? >>>> >>>> Post-doctoral research fellow >>>> A.A. Martinos Center for Biomedical Imaging? >>>> Massachusetts General Hospital | Harvard Medical School >>>> >>>> Resident in Radiology? >>>> Karolinska Institutet | Department of Clinical Science, Intervention >>>> and >>>> Technology >>>> Karolinska University Hospital | Department of Radiology >>>> >>>> >>> >>> ------------------------------ >>> >>> Message: 20 >>> Date: Thu, 21 Jul 2016 13:42:48 +0000 >>> From: "Granberg, Erik Tobias" <egranb...@mgh.harvard.edu> >>> Subject: Re: [Freesurfer] Subtracting overlays >>> To: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: <9294313c-f63a-420d-bf9c-d568a9a7b...@mgh.harvard.edu> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> Hi Bruce, >>> >>> Great, thanks for the quick reply! That worked beautifully. I was >>> apparently using the wrong output option. >>> Much appreciated! >>> >>> Kind regards, >>> Tobias >>> >>> _________________________________________ >>> Tobias Granberg, MD, PhD >>> >>> Post-doctoral research fellow >>> A.A. Martinos Center for Biomedical Imaging >>> Massachusetts General Hospital | Harvard Medical School >>> >>> Resident in Radiology >>> Karolinska Institutet | Department of Clinical Science, Intervention and >>> Technology >>> Karolinska University Hospital | Department of Radiology >>> >>> >>> On 21 jul 2016, at 09:35, Bruce Fischl >>> <fis...@nmr.mgh.harvard.edu<mailto:fis...@nmr.mgh.harvard.edu>> wrote: >>> >>> Hi Tobias >>> >>> yes, mris_calc should do it. If you give the output extension .mgz it >>> will >>> save in that format instead of curv I believe (and will work fine as an >>> overlay) >>> >>> cheers >>> Bruce >>> >>> >>> On Thu, 21 Jul 2016, Granberg, Erik Tobias wrote: >>> >>> Hi, >>> Is there a way to subtract one surface overlay from another (for example >>> in >>> fsaverage) and still having the output being an .mgh overlay file? >>> I saw that mis_calc does a similar procedure but automatically outputs >>> the >>> result >>> as out.mgz. >>> Thank you for the help! >>> Kind regards, >>> Tobias >>> >>> _________________________________________ >>> Tobias Granberg, MD, PhD >>> Post-doctoral research fellow >>> A.A. Martinos Center for Biomedical Imaging >>> Massachusetts General Hospital | Harvard Medical School >>> Resident in Radiology >>> Karolinska Institutet | Department of Clinical Science, Intervention and >>> Technology >>> Karolinska University Hospital | Department of Radiology >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20160721/f675b513/attachment-0001.html >>> >>> ------------------------------ >>> >>> Message: 21 >>> Date: Thu, 21 Jul 2016 13:49:26 +0000 >>> From: Falk L?sebrink <falk.luesebr...@ovgu.de> >>> Subject: Re: [Freesurfer] mri_ca_label with high resolution data >>> To: Bruce Fischl <fis...@nmr.mgh.harvard.edu> >>> Cc: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <54040dec6a0bcb4785840fff1f08d87891990...@chronos2.ads.uni-magdeburg.de> >>> >>> Content-Type: text/plain; charset="Windows-1252" >>> >>> Hi Bruce, >>> >>> I'm using the current dev build: >>> >>> ProgramName: mri_ca_label ProgramArguments: --all-info ProgramVersion: >>> $Name: $ TimeStamp: 2016/07/21-13:42:39-GMT BuildTimeStamp: Jul 12 >>> 2016 >>> 13:31:56 CVS: $Id: mri_ca_label.c,v 1.113 2016/05/13 18:02:49 fischl >>> Exp >>> $ User: luesebrink Machine: reco Platform: Linux PlatformVersion: >>> 3.16.0-4-amd64 CompilerName: GCC CompilerVersion: 40400 >>> >>> and in the log it says to use 12 threads >>> >>> == Number of threads available to mri_ca_label for OpenMP = 12 == >>> >>> however, at least while saving the intensity scale >>> >>> saving intensity scales to aseg.auto_noCCseg.label_intensities.txt >>> saving sequentially combined intensity scales to >>> aseg.auto_noCCseg.label_intensities.txt >>> >>> it doesn't seem to help. >>> >>> Best, >>> Falk >>> >>> ________________________________________ >>> Von: Bruce Fischl [fis...@nmr.mgh.harvard.edu] >>> Gesendet: Donnerstag, 21. Juli 2016 15:30 >>> An: Falk L?sebrink >>> Cc: Freesurfer support list >>> Betreff: Re: AW: [Freesurfer] mri_ca_label with high resolution data >>> >>> Hi Falk >>> >>> the dev version of mri_ca_label does use openmp, so should be faster. >>> >>> cheers >>> Bruce >>> On >>> Thu, 21 Jul 2016, Falk L?sebrink wrote: >>> >>>> Hi Bruce, >>>> >>>> I started the process again with openmp set to 12 using the dev build >>>> from 12th July. However, mri_ca_label uses only 1 thread at that point. >>>> So I don't assume any faster processing. >>>> >>>> Best, >>>> Falk >>>> >>>> >>>> -----Urspr?ngliche Nachricht----- >>>> Von: freesurfer-boun...@nmr.mgh.harvard.edu >>>> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce >>>> Fischl >>>> Gesendet: Dienstag, 19. Juli 2016 15:37 >>>> An: Freesurfer support list >>>> Betreff: Re: [Freesurfer] mri_ca_label with high resolution data >>>> >>>> Hi Falk >>>> >>>> I think openmp will help with this in V6, but probably not before Bruce >>>> >>>> On Tue, 19 >>>> Jul 2016, Falk L?sebrink wrote: >>>> >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> I?m currently processing a 250 ?m MPRAGE with a dev build from mid of >>>>> May. >>>>> Running recon-all with default parameters ran flawlessly. Afterwards I >>>>> added the -hires flag to process the data without conformation. >>>>> However, since Saturday morning it is kind of stuck at mri_ca_label >>>>> stating: >>>>> >>>>> >>>>> >>>>> saving sequentially combined intensity scales to >>>>> aseg.auto_noCCseg.label_intensities.txt >>>>> >>>>> >>>>> >>>>> while consuming around 30 GB of memory. I ran something similar >>>>> before and processing works, it?s just terribly slow. Maybe this >>>>> particular stage is just not very efficient as it does take a few >>>>> minutes on 1 mm data only? >>>>> Would it help to add the openmp flag in that case? >>>>> >>>>> >>>>> >>>>> Best, >>>>> >>>>> Falk >>>>> >>>>> >>>>> >>>>> ---------------------------------------- >>>>> >>>>> Falk L?sebrink, M. Sc. >>>>> >>>>> >>>>> >>>>> Otto-von-Guericke-Universit?t Magdeburg >>>>> >>>>> Forschungscampus STIMULATE >>>>> >>>>> http://www.forschungscampus-stimulate.de/ >>>>> >>>>> >>>>> >>>>> Universit?tsplatz 2 >>>>> >>>>> 39106 Magdeburg >>>>> >>>>> >>>>> >>>>> Raum: ExFa - 4.06 >>>>> >>>>> Telefon: 0391-67-19366 >>>>> >>>>> Fax: 0391-67-19347 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> 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. >>> >>> >>> >>> ------------------------------ >>> >>> Message: 22 >>> Date: Thu, 21 Jul 2016 09:52:09 -0400 (EDT) >>> From: Bruce Fischl <fis...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] mri_ca_label with high resolution data >>> To: Falk L?sebrink <falk.luesebr...@ovgu.de> >>> Cc: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <alpine.lrh.2.20.1607210951550.14...@door.nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset="windows-1252" >>> >>> Hi Falk >>> >>> not every part of it is accelerated, but some are >>> >>> cheers >>> Bruce >>> >>> >>> On Thu, 21 Jul 2016, Falk L?sebrink wrote: >>> >>>> Hi Bruce, >>>> >>>> I'm using the current dev build: >>>> >>>> ProgramName: mri_ca_label ProgramArguments: --all-info >>>> ProgramVersion: >>>> $Name: $ TimeStamp: 2016/07/21-13:42:39-GMT BuildTimeStamp: Jul 12 >>>> 2016 13:31:56 CVS: $Id: mri_ca_label.c,v 1.113 2016/05/13 18:02:49 >>>> fischl Exp $ User: luesebrink Machine: reco Platform: Linux >>>> PlatformVersion: 3.16.0-4-amd64 CompilerName: GCC CompilerVersion: >>>> 40400 >>>> >>>> and in the log it says to use 12 threads >>>> >>>> == Number of threads available to mri_ca_label for OpenMP = 12 == >>>> >>>> however, at least while saving the intensity scale >>>> >>>> saving intensity scales to aseg.auto_noCCseg.label_intensities.txt >>>> saving sequentially combined intensity scales to >>>> aseg.auto_noCCseg.label_intensities.txt >>>> >>>> it doesn't seem to help. >>>> >>>> Best, >>>> Falk >>>> >>>> ________________________________________ >>>> Von: Bruce Fischl [fis...@nmr.mgh.harvard.edu] >>>> Gesendet: Donnerstag, 21. Juli 2016 15:30 >>>> An: Falk L?sebrink >>>> Cc: Freesurfer support list >>>> Betreff: Re: AW: [Freesurfer] mri_ca_label with high resolution data >>>> >>>> Hi Falk >>>> >>>> the dev version of mri_ca_label does use openmp, so should be faster. >>>> >>>> cheers >>>> Bruce >>>> On >>>> Thu, 21 Jul 2016, Falk L?sebrink wrote: >>>> >>>>> Hi Bruce, >>>>> >>>>> I started the process again with openmp set to 12 using the dev build >>>>> from 12th July. However, mri_ca_label uses only 1 thread at that >>>>> point. >>>>> So I don't assume any faster processing. >>>>> >>>>> Best, >>>>> Falk >>>>> >>>>> >>>>> -----Urspr?ngliche Nachricht----- >>>>> Von: freesurfer-boun...@nmr.mgh.harvard.edu >>>>> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce >>>>> Fischl >>>>> Gesendet: Dienstag, 19. Juli 2016 15:37 >>>>> An: Freesurfer support list >>>>> Betreff: Re: [Freesurfer] mri_ca_label with high resolution data >>>>> >>>>> Hi Falk >>>>> >>>>> I think openmp will help with this in V6, but probably not before >>>>> Bruce >>>>> >>>>> On Tue, 19 >>>>> Jul 2016, Falk L?sebrink wrote: >>>>> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> I?m currently processing a 250 ?m MPRAGE with a dev build from mid of >>>>>> May. >>>>>> Running recon-all with default parameters ran flawlessly. Afterwards >>>>>> I >>>>>> added the -hires flag to process the data without conformation. >>>>>> However, since Saturday morning it is kind of stuck at mri_ca_label >>>>>> stating: >>>>>> >>>>>> >>>>>> >>>>>> saving sequentially combined intensity scales to >>>>>> aseg.auto_noCCseg.label_intensities.txt >>>>>> >>>>>> >>>>>> >>>>>> while consuming around 30 GB of memory. I ran something similar >>>>>> before and processing works, it?s just terribly slow. Maybe this >>>>>> particular stage is just not very efficient as it does take a few >>>>>> minutes on 1 mm data only? >>>>>> Would it help to add the openmp flag in that case? >>>>>> >>>>>> >>>>>> >>>>>> Best, >>>>>> >>>>>> Falk >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>> >>>>>> Falk L?sebrink, M. Sc. >>>>>> >>>>>> >>>>>> >>>>>> Otto-von-Guericke-Universit?t Magdeburg >>>>>> >>>>>> Forschungscampus STIMULATE >>>>>> >>>>>> http://www.forschungscampus-stimulate.de/ >>>>>> >>>>>> >>>>>> >>>>>> Universit?tsplatz 2 >>>>>> >>>>>> 39106 Magdeburg >>>>>> >>>>>> >>>>>> >>>>>> Raum: ExFa - 4.06 >>>>>> >>>>>> Telefon: 0391-67-19366 >>>>>> >>>>>> Fax: 0391-67-19347 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>> >>> ------------------------------ >>> >>> Message: 23 >>> Date: Thu, 21 Jul 2016 13:53:46 +0000 >>> From: "Koubiyr, Ismail" <ikoub...@bwh.harvard.edu> >>> Subject: Re: [Freesurfer] mri_convert : ERROR: cannot unpack mosiacs >>> without ASCII header >>> To: "zkauf...@nmr.mgh.harvard.edu" <zkauf...@nmr.mgh.harvard.edu> >>> Cc: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu>, Douglas >>> Greve <gr...@nmr.mgh.harvard.edu> >>> Message-ID: <fabe6622-956e-4136-82a6-4a71422d2...@partners.org> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> Doug, Zeke, >>> >>> Thank you very much for your help. >>> >>> Best, >>> >>> Ismail >>> >>> >>> On Jul 21, 2016, at 1:15 AM, >>> zkauf...@nmr.mgh.harvard.edu<mailto:zkauf...@nmr.mgh.harvard.edu> wrote: >>> >>> >>> Current versions of the Mac freesurfer binaries are not compatible with >>> the v5.3 release. Too much has changed since then. If you wanted to use >>> the newest version on the code you will need to download the latest dev >>> version of freesurfer from this page (see "Development Version"): >>> >>> https://surfer.nmr.mgh.harvard.edu/fswiki/DownloadAndInstall#Download >>> >>> Hope this helps. >>> >>> -Zeke >>> >>> There was an obscure error having to do with the ascii header when >>> unpacking skyra data on the mac, that might be it. Zeke, can you get >>> Ismail a version of mri_convert appropriate for his OS? >>> >>> doug >>> >>> >>> >>> On 7/20/16 10:34 AM, Koubiyr, Ismail wrote: >>> Hi Doug, >>> >>> I tried it on the cluster and it worked, which is weird because it was >>> not working before . Any idea what might be the problem on my system ? >>> Thanks again. >>> >>> Ismail >>> >>> On Jul 19, 2016, at 10:32 PM, Douglas Greve >>> <gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu> >>> <mailto:gr...@nmr.mgh.harvard.edu>> wrote: >>> >>> I used the same version, but I used it on linux. Do you have a linux >>> box with FS installed that you can try it on? >>> >>> >>> On 7/19/16 1:57 PM, Koubiyr, Ismail wrote: >>> I used the same command line as you did. And when I check with >>> mri_probedicom I can see the ASCII header. >>> >>> Here is the version of FS I am using : >>> freesurfer-i386-apple-darwin11.4.2-stable5-20130514 >>> >>> Do you think it might be related ? >>> >>> Thanks again. >>> >>> Ismail >>> >>> On Jul 19, 2016, at 1:27 PM, Douglas N Greve >>> <gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu> >>> <mailto:gr...@nmr.mgh.harvard.edu>> wrote: >>> >>> What is your exact command line? >>> >>> The version of the file that you gave me definitely has an ascii >>> header, >>> and I don't get that warning when I convert. What version of FS are >>> you >>> using on what platform? To check whether that file has an ascii >>> header, run >>> >>> mri_probedicom --i >>> MR.1.3.12.2.1107.5.2.19.45306.2014091812330393354083931 >>> >>> There should be a line like below >>> >>> ### ASCCONV BEGIN >>> >>> >>> On 07/19/2016 01:16 PM, Koubiyr, Ismail wrote: >>> Hi Doug, >>> >>> That's weird because I can't convert it using only mri_convert, here >>> is the error I get : >>> >>> WARNING: file >>> /Users/ismailkoubiyr/Documents/PFE/Tracula/dti/3T2/MR.1.3.12.2.1107.5.2.19.45306.2014091812330393354083931 >>> does not contain a Siemens ASCII header >>> has this file been anonymized? >>> ERROR: cannot unpack mosiacs without ASCII header >>> >>> Any idea why ? >>> >>> Best, >>> >>> Ismail >>> >>> On Jul 19, 2016, at 1:11 PM, Douglas N Greve >>> <gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu> >>> <mailto:gr...@nmr.mgh.harvard.edu><mailto:gr...@nmr.mgh.harvard.edu>> >>> wrote: >>> >>> I was able to convert it fine with >>> mri_convert MR.1.3.12.2.1107.5.2.19.45306.2014091812372179441003292 >>> output.nii.gz >>> If I included -it dicom, the conversion did not have an error, >>> but the >>> output had only one slice. Since these are mosaics, they need the >>> Siemens ascii header which is ignored with -it dicom. So ... >>> don't use >>> -it dicom >>> >>> >>> On 07/19/2016 11:06 AM, Koubiyr, Ismail wrote: >>> Hi Doug, >>> >>> It is still an issue. I uploaded the DICOMs to you. Hope it could >>> be >>> useful. >>> Thanks. >>> >>> Ismail >>> >>> On Jul 18, 2016, at 6:14 PM, Douglas N Greve >>> <gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu> >>> <mailto:gr...@nmr.mgh.harvard.edu><mailto:gr...@nmr.mgh.harvard.edu>> >>> wrote: >>> >>> Is this still a problem? If so, can you upload the dicom files >>> to our >>> file drop? >>> >>> On 07/05/2016 11:24 AM, Koubiyr, Ismail wrote: >>> The file has not been anonymized. >>> >>> Thanks, >>> >>> Ismail >>> >>> On Jul 5, 2016, at 11:20 AM, Douglas N Greve >>> <gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu> >>> <mailto:gr...@nmr.mgh.harvard.edu><mailto:gr...@nmr.mgh.harvard.edu>> >>> wrote: >>> >>> can you answer the question that it asks? >>> >>> On 07/05/2016 10:52 AM, Koubiyr, Ismail wrote: >>> Hi everyone, >>> >>> I'm having some issues converting my DICOMs (DWI) into NIFTI >>> using >>> mri_convert. I looked for other topics with people having >>> the same >>> kind of problem but couldn't find an answer. >>> >>> Each time I run mri_convert on my DICOMs I get the following >>> error : >>> WARNING: file >>> MR.1.3.12.2.1107.5.2.19.45306.2014091812330393354083931 >>> does not contain a Siemens ASCII header >>> has this file been anonymized? >>> ERROR: cannot unpack mosiacs without ASCII header >>> >>> Here are the following DICOMs informations : >>> Identification >>> NumarisVer syngo MR D13 >>> ScannerModel Skyra >>> PatientName xxxxx >>> Date and time >>> StudyDate 20140918 >>> StudyTime 121037.203000 >>> SeriesTime 123450.600000 >>> AcqTime 123257.367500 >>> Acquisition parameters >>> PulseSeq ep_b0 >>> Protocol AX DTI no angle MS NEX 4 2 >>> PhEncDir COL >>> EchoNo 1 >>> FlipAngle 90 >>> EchoTime 96 >>> InversionTime -1 >>> RepetitionTime 4700 >>> PhEncFOV 0 >>> ReadoutFOV 0 >>> Image information >>> RunNo 4 >>> SeriesNo 5 >>> ImageNo 1 >>> NImageRows 990 >>> NImageCols 990 >>> NFrames 64 >>> SliceArraylSize 0 >>> IsMosaic 1 >>> ImgPos 1075.1575 1069.8385 -48.6769 >>> VolRes 2.1818 2.1818 2.0000 >>> VolDim 0 0 0 >>> Vc -1.0000 -0.0000 0.0000 >>> Vr -0.0000 -1.0000 0.0000 >>> Vs 0.0000 0.0000 0.0000 >>> VolCenter 0.0000 0.0000 0.0000 >>> TransferSyntaxUID 1.2.840.10008.1.2.1 >>> >>> >>> Then I try using mri_convert -it dicom, it converts the files >>> but not >>> as it is expected, you could notice the difference when I run >>> mri_info >>> on my output : >>> Volume information for output.nii.gz >>> type: nii >>> dimensions: 990 x 990 x 1 x 64 >>> voxel sizes: 2.1818, 2.1818, 2.0000 >>> type: SHORT (4) >>> fov: 2160.000 >>> dof: 0 >>> xstart: -1080.0, xend: 1080.0 >>> ystart: -1080.0, yend: 1080.0 >>> zstart: -1.0, zend: 1.0 >>> TR: 4700.00 msec, TE: 0.00 msec, TI: 0.00 msec, flip >>> angle: 0.00 degrees >>> nframes: 64 >>> PhEncDir: UNKNOWN >>> ras xform present >>> xform info: x_r = -1.0000, y_r = -0.0000, z_r = -0.0000, >>> c_r = >>> -4.8425 >>> : x_a = -0.0000, y_a = -1.0000, z_a = -0.0000, >>> c_a = >>> -10.1615 >>> : x_s = 0.0000, y_s = 0.0000, z_s = 1.0000, >>> c_s = >>> -47.6769 >>> Orientation : LPS >>> Primary Slice Direction: axial >>> >>> voxel to ras transform: >>> -2.1818 -0.0000 -0.0000 1075.1575 >>> -0.0000 -2.1818 -0.0000 1069.8385 >>> 0.0000 0.0000 2.0000 -48.6769 >>> 0.0000 0.0000 0.0000 1.0000 >>> >>> voxel-to-ras determinant 9.52066 >>> >>> ras to voxel transform: >>> -0.4583 0.0000 0.0000 492.7805 >>> 0.0000 -0.4583 0.0000 490.3426 >>> -0.0000 -0.0000 0.5000 24.3384 >>> 0.0000 0.0000 0.0000 1.0000 >>> >>> I would really appreciate your help, thank you. >>> >>> Best, >>> >>> Ismail >>> >>> >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> <mailto:Freesurfer@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 >>> gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu> >>> <mailto:gr...@nmr.mgh.harvard.edu><mailto:gr...@nmr.mgh.harvard.edu> >>> Phone Number: 617-724-2358 >>> Fax: 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<http://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> >>> <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@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> <mailto:Freesurfer@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 >>> gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu> >>> <mailto:gr...@nmr.mgh.harvard.edu><mailto:gr...@nmr.mgh.harvard.edu> >>> Phone Number: 617-724-2358 >>> Fax: 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<http://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> >>> <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@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> <mailto:Freesurfer@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 >>> gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu> >>> <mailto:gr...@nmr.mgh.harvard.edu><mailto:gr...@nmr.mgh.harvard.edu> >>> Phone Number: 617-724-2358 >>> Fax: 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<http://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> >>> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>> Outgoing:ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/<http://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/> >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@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 >>> gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu> >>> <mailto:gr...@nmr.mgh.harvard.edu> >>> Phone Number: 617-724-2358 >>> Fax: 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<http://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> >>> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>> Outgoing:ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/<http://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/> >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu> >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20160721/95bd55dc/attachment-0001.html >>> >>> ------------------------------ >>> >>> Message: 24 >>> Date: Thu, 21 Jul 2016 10:34:58 -0400 (EDT) >>> From: Bruce Fischl <fis...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] Flattening the surface >>> To: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <alpine.lrh.2.20.1607211034250.14...@door.nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset="utf-8" >>> >>> is Brain_FS.mgz a segmented volume? How much memory do you have on that >>> machine? >>> >>> On Wed, 20 Jul 2016, Younghoon Kim wrote: >>> >>>> Hi Bruce, >>>> >>>> I tried "mri_tessellate Brain_FS.mgz 255 lh_test.orig.nofix? command to >>>> generate a >>>> surface, but received an error message as below: >>>> >>>> changing type of input volume to 8 bits/voxel... >>>> $Id: mri_tessellate.c,v 1.36 2011/03/02 00:04:25 nicks Exp $ >>>> ? $Id: mrisurf.c,v 1.693.2.7 2013/05/12 22:28:01 nicks Exp $ >>>> Cannot calloc() >>>> >>>> Would this be because my input data is not compatible with the >>>> mri_tessellate >>>> command? >>>> >>>> Thanks, >>>> >>>> Younghoon Kim >>>> >>>> -- >>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>> OMICS Lab >>>> Wellman Center, Massachusetts General Hospital >>>> Bouma?s Lab >>>> ---------------------------------------------- >>>> younghoon.h....@gmail.com >>>> aktivh...@kaist.ac.kr >>>> >>>> On July 20, 2016 at 5:29:24 PM, Bruce Fischl >>>> (fis...@nmr.mgh.harvard.edu) wrote: >>>> >>>> If you have a segmented volume, you can use mri_tessellate to create >>>> the >>>> surface, then introduce the cut(s) and run mris_flatten -1 on the >>>> resulting >>>> patch. You can check out our wiki >>>> >>>> http://surfer.nmr.mgh.harvard.edu/fswiki >>>> >>>> which has info on this process, although the flattening isn't terribly >>>> well >>>> documented. You need the -1 flag to tell it to only use that one >>>> surface >>>> that you are giving it, and not to assume that the entire FS directory >>>> structure exists. >>>> >>>> cheers >>>> Bruce >>>> >>>> >>>> On Wed, 20 Jul 2016, Younghoon Kim wrote: >>>> >>>>> Hi Bruce, >>>>> >>>>> Great! I?m not an expert in FreeSurfer, so can you give me some >>>> advice >>>> how >>>> to >>>>> generate a surface of our volumetric data and flatten it? >>>>> >>>>> Thanks, >>>>> >>>>> Younghoon Kim >>>>> >>>>> -- >>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>> OMICS Lab >>>>> Wellman Center, Massachusetts General Hospital >>>>> Bouma?s Lab >>>>> ---------------------------------------------- >>>>> younghoon.h....@gmail.com >>>>> aktivh...@kaist.ac.kr >>>>> >>>>> On July 20, 2016 at 5:12:59 PM, Bruce Fischl >>>> (fis...@nmr.mgh.harvard.edu) >>>> wrote: >>>>> >>>>> HI Younghoon >>>>> >>>>> I guess that could work. You will need to introduce at least one cut >>>> if not >>>>> more if you surface has substantial Gaussian curvature >>>>> >>>>> cheers >>>>> Bruce >>>>> >>>>> >>>>> On Wed, >>>>> 20 Jul 2016, Younghoon Kim wrote: >>>>> >>>>>> Hi Bruce, >>>>>> >>>>>> We are only interested in the surface image of the volumetric data. >>>>>> >>>>>> For flattening, we do not care about the interior of the volume, so >>>> we >>>>> would like >>>>>> to remove the volume data inside. >>>>>> >>>>>> So what we want is to peel off the surface from the segmented brain >>>> area >>>>> and >>>>>> flatten that surface. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Younghoon Kim >>>>>> >>>>>> -- >>>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>>> OMICS Lab >>>>>> Wellman Center, Massachusetts General Hospital >>>>>> Bouma?s Lab >>>>>> ---------------------------------------------- >>>>>> younghoon.h....@gmail.com >>>>>> aktivh...@kaist.ac.kr >>>>>> >>>>>> On July 20, 2016 at 5:00:55 PM, Bruce Fischl >>>> (fis...@nmr.mgh.harvard.edu) >>>>> wrote: >>>>>> >>>>>> Hi Younghoon >>>>>> >>>>>> what structure are you talking about? In general it doesn't make >>>> sense to >>>>>> flatten volumetric structures. We flatten the cortex, which is a >>>> folded >>>>>> 2D sheet. What would you do with the interior of the volume? >>>>>> >>>>>> cheers >>>>>> Bruce >>>>>> On Wed, 20 Jul >>>>>> 2016, Younghoon Kim wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> We have a volumetric data (mgz file) of a segmented brain >>>> region.?We >>>> want >>>>>> to detect >>>>>>> the surface of this segmented brain volume (i.e. deep brain >>>> region) and >>>>>> flatten it >>>>>>> into a 2D image with?its original surface texture. >>>>>>> >>>>>>> We?ve noticed that Freesurfer supports an algorithm to flatten >>>> volumetric >>>>>> data. We >>>>>>> wonder if this could be adapted to our data set.?Can anyone offer >>>> some >>>>>> advice on >>>>>>> how to apply FreeSurfer to this more generic task? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Younghoon Kim >>>>>>> >>>>>>> -- >>>>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>>>> OMICS Lab >>>>>>> Wellman Center, Massachusetts General Hospital >>>>>>> Bouma?s Lab >>>>>>> ---------------------------------------------- >>>>>>> younghoon.h....@gmail.com >>>>>>> aktivh...@kaist.ac.kr >>>>>>> >>>>>>> _______________________________________________ >>>>>> Freesurfer mailing list >>>>>> 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@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@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. >>>> >>>> >>>> >>> >>> ------------------------------ >>> >>> Message: 25 >>> Date: Thu, 21 Jul 2016 14:42:44 +0000 >>> From: Falk L?sebrink <falk.luesebr...@ovgu.de> >>> Subject: Re: [Freesurfer] mri_ca_label with high resolution data >>> To: Bruce Fischl <fis...@nmr.mgh.harvard.edu> >>> Cc: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <54040dec6a0bcb4785840fff1f08d87891990...@chronos2.ads.uni-magdeburg.de> >>> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> Hi Bruce, >>> >>> I thought so. Are there any other means to accelerate this procedure (in >>> the future)? >>> >>> Best, >>> Falk >>> >>> -----Urspr?ngliche Nachricht----- >>> Von: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] >>> Gesendet: Donnerstag, 21. Juli 2016 15:52 >>> An: Falk L?sebrink >>> Cc: Freesurfer support list >>> Betreff: Re: AW: AW: [Freesurfer] mri_ca_label with high resolution data >>> >>> Hi Falk >>> >>> not every part of it is accelerated, but some are >>> >>> cheers >>> Bruce >>> >>> >>> On Thu, 21 Jul 2016, Falk L?sebrink wrote: >>> >>>> Hi Bruce, >>>> >>>> I'm using the current dev build: >>>> >>>> ProgramName: mri_ca_label ProgramArguments: --all-info >>>> ProgramVersion: $Name: $ TimeStamp: 2016/07/21-13:42:39-GMT >>>> BuildTimeStamp: Jul 12 2016 13:31:56 CVS: $Id: mri_ca_label.c,v 1.113 >>>> 2016/05/13 18:02:49 fischl Exp $ User: luesebrink Machine: reco >>>> Platform: Linux PlatformVersion: 3.16.0-4-amd64 CompilerName: GCC >>>> CompilerVersion: 40400 >>>> >>>> and in the log it says to use 12 threads >>>> >>>> == Number of threads available to mri_ca_label for OpenMP = 12 == >>>> >>>> however, at least while saving the intensity scale >>>> >>>> saving intensity scales to aseg.auto_noCCseg.label_intensities.txt >>>> saving sequentially combined intensity scales to >>>> aseg.auto_noCCseg.label_intensities.txt >>>> >>>> it doesn't seem to help. >>>> >>>> Best, >>>> Falk >>>> >>>> ________________________________________ >>>> Von: Bruce Fischl [fis...@nmr.mgh.harvard.edu] >>>> Gesendet: Donnerstag, 21. Juli 2016 15:30 >>>> An: Falk L?sebrink >>>> Cc: Freesurfer support list >>>> Betreff: Re: AW: [Freesurfer] mri_ca_label with high resolution data >>>> >>>> Hi Falk >>>> >>>> the dev version of mri_ca_label does use openmp, so should be faster. >>>> >>>> cheers >>>> Bruce >>>> On >>>> Thu, 21 Jul 2016, Falk L?sebrink wrote: >>>> >>>>> Hi Bruce, >>>>> >>>>> I started the process again with openmp set to 12 using the dev build >>>>> from 12th July. However, mri_ca_label uses only 1 thread at that >>>>> point. >>>>> So I don't assume any faster processing. >>>>> >>>>> Best, >>>>> Falk >>>>> >>>>> >>>>> -----Urspr?ngliche Nachricht----- >>>>> Von: freesurfer-boun...@nmr.mgh.harvard.edu >>>>> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce >>>>> Fischl >>>>> Gesendet: Dienstag, 19. Juli 2016 15:37 >>>>> An: Freesurfer support list >>>>> Betreff: Re: [Freesurfer] mri_ca_label with high resolution data >>>>> >>>>> Hi Falk >>>>> >>>>> I think openmp will help with this in V6, but probably not before >>>>> Bruce >>>>> >>>>> On Tue, 19 >>>>> Jul 2016, Falk L?sebrink wrote: >>>>> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> I'm currently processing a 250 ?m MPRAGE with a dev build from mid of >>>>>> May. >>>>>> Running recon-all with default parameters ran flawlessly. Afterwards >>>>>> I added the -hires flag to process the data without conformation. >>>>>> However, since Saturday morning it is kind of stuck at mri_ca_label >>>>>> stating: >>>>>> >>>>>> >>>>>> >>>>>> saving sequentially combined intensity scales to >>>>>> aseg.auto_noCCseg.label_intensities.txt >>>>>> >>>>>> >>>>>> >>>>>> while consuming around 30 GB of memory. I ran something similar >>>>>> before and processing works, it's just terribly slow. Maybe this >>>>>> particular stage is just not very efficient as it does take a few >>>>>> minutes on 1 mm data only? >>>>>> Would it help to add the openmp flag in that case? >>>>>> >>>>>> >>>>>> >>>>>> Best, >>>>>> >>>>>> Falk >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------- >>>>>> >>>>>> Falk L?sebrink, M. Sc. >>>>>> >>>>>> >>>>>> >>>>>> Otto-von-Guericke-Universit?t Magdeburg >>>>>> >>>>>> Forschungscampus STIMULATE >>>>>> >>>>>> http://www.forschungscampus-stimulate.de/ >>>>>> >>>>>> >>>>>> >>>>>> Universit?tsplatz 2 >>>>>> >>>>>> 39106 Magdeburg >>>>>> >>>>>> >>>>>> >>>>>> Raum: ExFa - 4.06 >>>>>> >>>>>> Telefon: 0391-67-19366 >>>>>> >>>>>> Fax: 0391-67-19347 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>> >>> >>> >>> ------------------------------ >>> >>> Message: 26 >>> Date: Thu, 21 Jul 2016 10:43:32 -0400 (EDT) >>> From: Bruce Fischl <fis...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] mri_ca_label with high resolution data >>> To: Falk L?sebrink <falk.luesebr...@ovgu.de> >>> Cc: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <alpine.lrh.2.20.1607211043110.14...@door.nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> Hi Falk >>> >>> yes, it's an active area of devlopment for us >>> cheers >>> Bruce >>> >>> On Thu, 21 Jul 2016, Falk >>> L?sebrink wrote: >>> >>>> Hi Bruce, >>>> >>>> I thought so. Are there any other means to accelerate this procedure >>>> (in >>>> the future)? >>>> >>>> Best, >>>> Falk >>>> >>>> -----Urspr?ngliche Nachricht----- >>>> Von: Bruce Fischl [mailto:fis...@nmr.mgh.harvard.edu] >>>> Gesendet: Donnerstag, 21. Juli 2016 15:52 >>>> An: Falk L?sebrink >>>> Cc: Freesurfer support list >>>> Betreff: Re: AW: AW: [Freesurfer] mri_ca_label with high resolution >>>> data >>>> >>>> Hi Falk >>>> >>>> not every part of it is accelerated, but some are >>>> >>>> cheers >>>> Bruce >>>> >>>> >>>> On Thu, 21 Jul 2016, Falk L?sebrink wrote: >>>> >>>>> Hi Bruce, >>>>> >>>>> I'm using the current dev build: >>>>> >>>>> ProgramName: mri_ca_label ProgramArguments: --all-info >>>>> ProgramVersion: $Name: $ TimeStamp: 2016/07/21-13:42:39-GMT >>>>> BuildTimeStamp: Jul 12 2016 13:31:56 CVS: $Id: mri_ca_label.c,v 1.113 >>>>> 2016/05/13 18:02:49 fischl Exp $ User: luesebrink Machine: reco >>>>> Platform: Linux PlatformVersion: 3.16.0-4-amd64 CompilerName: GCC >>>>> CompilerVersion: 40400 >>>>> >>>>> and in the log it says to use 12 threads >>>>> >>>>> == Number of threads available to mri_ca_label for OpenMP = 12 == >>>>> >>>>> however, at least while saving the intensity scale >>>>> >>>>> saving intensity scales to aseg.auto_noCCseg.label_intensities.txt >>>>> saving sequentially combined intensity scales to >>>>> aseg.auto_noCCseg.label_intensities.txt >>>>> >>>>> it doesn't seem to help. >>>>> >>>>> Best, >>>>> Falk >>>>> >>>>> ________________________________________ >>>>> Von: Bruce Fischl [fis...@nmr.mgh.harvard.edu] >>>>> Gesendet: Donnerstag, 21. Juli 2016 15:30 >>>>> An: Falk L?sebrink >>>>> Cc: Freesurfer support list >>>>> Betreff: Re: AW: [Freesurfer] mri_ca_label with high resolution data >>>>> >>>>> Hi Falk >>>>> >>>>> the dev version of mri_ca_label does use openmp, so should be faster. >>>>> >>>>> cheers >>>>> Bruce >>>>> On >>>>> Thu, 21 Jul 2016, Falk L?sebrink wrote: >>>>> >>>>>> Hi Bruce, >>>>>> >>>>>> I started the process again with openmp set to 12 using the dev build >>>>>> from 12th July. However, mri_ca_label uses only 1 thread at that >>>>>> point. So I don't assume any faster processing. >>>>>> >>>>>> Best, >>>>>> Falk >>>>>> >>>>>> >>>>>> -----Urspr?ngliche Nachricht----- >>>>>> Von: freesurfer-boun...@nmr.mgh.harvard.edu >>>>>> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Bruce >>>>>> Fischl >>>>>> Gesendet: Dienstag, 19. Juli 2016 15:37 >>>>>> An: Freesurfer support list >>>>>> Betreff: Re: [Freesurfer] mri_ca_label with high resolution data >>>>>> >>>>>> Hi Falk >>>>>> >>>>>> I think openmp will help with this in V6, but probably not before >>>>>> Bruce >>>>>> >>>>>> On Tue, 19 >>>>>> Jul 2016, Falk L?sebrink wrote: >>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'm currently processing a 250 ?m MPRAGE with a dev build from mid >>>>>>> of >>>>>>> May. >>>>>>> Running recon-all with default parameters ran flawlessly. Afterwards >>>>>>> I added the -hires flag to process the data without conformation. >>>>>>> However, since Saturday morning it is kind of stuck at mri_ca_label >>>>>>> stating: >>>>>>> >>>>>>> >>>>>>> >>>>>>> saving sequentially combined intensity scales to >>>>>>> aseg.auto_noCCseg.label_intensities.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> while consuming around 30 GB of memory. I ran something similar >>>>>>> before and processing works, it's just terribly slow. Maybe this >>>>>>> particular stage is just not very efficient as it does take a few >>>>>>> minutes on 1 mm data only? >>>>>>> Would it help to add the openmp flag in that case? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Falk >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------- >>>>>>> >>>>>>> Falk L?sebrink, M. Sc. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Otto-von-Guericke-Universit?t Magdeburg >>>>>>> >>>>>>> Forschungscampus STIMULATE >>>>>>> >>>>>>> http://www.forschungscampus-stimulate.de/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Universit?tsplatz 2 >>>>>>> >>>>>>> 39106 Magdeburg >>>>>>> >>>>>>> >>>>>>> >>>>>>> Raum: ExFa - 4.06 >>>>>>> >>>>>>> Telefon: 0391-67-19366 >>>>>>> >>>>>>> Fax: 0391-67-19347 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> ------------------------------ >>> >>> Message: 27 >>> Date: Thu, 21 Jul 2016 10:50:20 -0400 >>> From: Trisanna Sprung-Much <trisanna.sprung-m...@mail.mcgill.ca> >>> Subject: Re: [Freesurfer] registering subject pial to fsaverage >>> To: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <cag+tortb+d8ytvyhzs30ytjs96g_qto4ggandmm1kfyqn2r...@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi Doug >>> >>> What I mean to say is that the pial surface created by recon-all and the >>> pial surface that has been nonlinearly registered to fsaverage look >>> pretty >>> much identical in sulcal patterns, but I do not understand how this can >>> be >>> the case if one surface has been registered to a surface template based >>> on >>> cortical folding. >>> Shouldn't the cortical folding for this registered surface change even a >>> little bit? >>> >>> best >>> Trisanna >>> >>> >>> -- >>> Ph.D. Candidate >>> McGill University >>> Integrated Program in Neuroscience >>> Psychology >>> >>> >>> On Tue, Jul 19, 2016 at 10:29 PM, Douglas Greve >>> <gr...@nmr.mgh.harvard.edu> >>> wrote: >>> >>>> I don't understand what you did or what the problem is. Can you >>>> elaborate? >>>> >>>> On 7/19/16 5:23 PM, Trisanna Sprung-Much wrote: >>>> >>>> Hi there >>>> >>>> I tested registering a subject's pial surface to fsaverage and compared >>>> the original pial (from recon-all) with this registered pial surface. >>>> It >>>> turns out that they are almost identical in nature, and I am wondering >>>> how >>>> this is possible if recon-all does not alter the input data. >>>> >>>> Below is the command that I ran. Is there something I am missing here? >>>> >>>> many thanks >>>> >>>> Trisanna >>>> >>>> >>>> trisanna@kaplan:~$ mri_surf2surf --srcsubject icbm-102 --sval-xyz pial >>>> --trgsubject fsaverage --tval-xyz --tval lh.pial.icbm102 --hemi lh >>>> srcsubject = icbm-102 >>>> srcval = (null) >>>> srctype = >>>> trgsubject = fsaverage >>>> trgval = lh.pial.icbm102 >>>> trgtype = >>>> srcsurfreg = sphere.reg >>>> trgsurfreg = sphere.reg >>>> srchemi = lh >>>> trghemi = lh >>>> frame = 0 >>>> fwhm-in = 0 >>>> fwhm-out = 0 >>>> label-src = (null) >>>> label-trg = (null) >>>> OKToRevFaceOrder = 1 >>>> Reading source surface reg >>>> /data-01/trisanna/freesurfer/icbm-102/surf/lh.sphere.reg >>>> Loading source data >>>> Reading surface file /data-01/trisanna/freesurfer/icbm-102/surf/lh.pial >>>> Reading target surface reg >>>> /data-01/trisanna/freesurfer/fsaverage/surf/lh.sphere.reg >>>> Done >>>> Mapping Source Volume onto Source Subject Surface >>>> surf2surf_nnfr: building source hash (res=16). >>>> Surf2Surf: Forward Loop (163842) >>>> >>>> surf2surf_nnfr: building target hash (res=16). >>>> Surf2Surf: Reverse Loop (169941) >>>> Reverse Loop had 44416 hits >>>> Surf2Surf: Dividing by number of hits (163842) >>>> INFO: nSrcLost = 0 >>>> nTrg121 = 131435, nTrgMulti = 32407, MnTrgMultiHits = 2.37057 >>>> nSrc121 = 140014, nSrcLost = 0, nSrcMulti = 29927, MnSrcMultiHits = >>>> 2.28035 >>>> Saving target data >>>> >>>> >>>> >>>> >>>> -- >>>> Ph.D. Candidate >>>> McGill University >>>> Integrated Program in Neuroscience >>>> Psychology >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freesurfer mailing >>>> listfreesur...@nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> 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. >>>> >>>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20160721/b6184c83/attachment-0001.html >>> >>> ------------------------------ >>> >>> Message: 28 >>> Date: Thu, 21 Jul 2016 11:06:01 -0400 >>> From: Younghoon Kim <younghoon.h....@gmail.com> >>> Subject: Re: [Freesurfer] Flattening the surface >>> To: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <cakemtoik5qmbkxgaj5hh11ieqxwuxy6u6yc2r9dwhowvk9p...@mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi Bruce, >>> >>> Yes Brain_FS.mgz is a segmented volume. It?s not a MRI image, and the >>> size >>> is about 3000x2000x140. (We obtained this brain image using different >>> imaging methods) >>> >>> Our machine has 16GB RAM. >>> >>> Thanks, >>> >>> Younghoon Kim >>> >>> -- >>> Younghoon Kim, >>> Dep. of Bio and Brain Engineering, KAIST >>> OMICS Lab >>> ---------------------------------------------- >>> younghoon.h....@gmail.com >>> aktivh...@kaist.ac.kr >>> >>> >>> On July 21, 2016 at 10:35:18 AM, Bruce Fischl >>> (fis...@nmr.mgh.harvard.edu) >>> wrote: >>> >>> is Brain_FS.mgz a segmented volume? How much memory do you have on that >>> machine? >>> >>> On Wed, 20 Jul 2016, Younghoon Kim wrote: >>> >>>> Hi Bruce, >>>> >>>> I tried "mri_tessellate Brain_FS.mgz 255 lh_test.orig.nofix? command to >>> generate a >>>> surface, but received an error message as below: >>>> >>>> changing type of input volume to 8 bits/voxel... >>>> $Id: mri_tessellate.c,v 1.36 2011/03/02 00:04:25 nicks Exp $ >>>> $Id: mrisurf.c,v 1.693.2.7 2013/05/12 22:28:01 nicks Exp $ >>>> Cannot calloc() >>>> >>>> Would this be because my input data is not compatible with the >>> mri_tessellate >>>> command? >>>> >>>> Thanks, >>>> >>>> Younghoon Kim >>>> >>>> -- >>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>> OMICS Lab >>>> Wellman Center, Massachusetts General Hospital >>>> Bouma?s Lab >>>> ---------------------------------------------- >>>> younghoon.h....@gmail.com >>>> aktivh...@kaist.ac.kr >>>> >>>> On July 20, 2016 at 5:29:24 PM, Bruce Fischl >>>> (fis...@nmr.mgh.harvard.edu) >>> wrote: >>>> >>>> If you have a segmented volume, you can use mri_tessellate to create >>>> the >>>> surface, then introduce the cut(s) and run mris_flatten -1 on the >>> resulting >>>> patch. You can check out our wiki >>>> >>>> http://surfer.nmr.mgh.harvard.edu/fswiki >>>> >>>> which has info on this process, although the flattening isn't terribly >>> well >>>> documented. You need the -1 flag to tell it to only use that one >>>> surface >>>> that you are giving it, and not to assume that the entire FS directory >>>> structure exists. >>>> >>>> cheers >>>> Bruce >>>> >>>> >>>> On Wed, 20 Jul 2016, Younghoon Kim wrote: >>>> >>>>> Hi Bruce, >>>>> >>>>> Great! I?m not an expert in FreeSurfer, so can you give me some >>>> advice >>> how >>>> to >>>>> generate a surface of our volumetric data and flatten it? >>>>> >>>>> Thanks, >>>>> >>>>> Younghoon Kim >>>>> >>>>> -- >>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>> OMICS Lab >>>>> Wellman Center, Massachusetts General Hospital >>>>> Bouma?s Lab >>>>> ---------------------------------------------- >>>>> younghoon.h....@gmail.com >>>>> aktivh...@kaist.ac.kr >>>>> >>>>> On July 20, 2016 at 5:12:59 PM, Bruce Fischl >>>> (fis...@nmr.mgh.harvard.edu) >>> >>>> wrote: >>>>> >>>>> HI Younghoon >>>>> >>>>> I guess that could work. You will need to introduce at least one cut >>>> if >>> not >>>>> more if you surface has substantial Gaussian curvature >>>>> >>>>> cheers >>>>> Bruce >>>>> >>>>> >>>>> On Wed, >>>>> 20 Jul 2016, Younghoon Kim wrote: >>>>> >>>>>> Hi Bruce, >>>>>> >>>>>> We are only interested in the surface image of the volumetric data. >>>>>> >>>>>> For flattening, we do not care about the interior of the volume, so >>> we >>>>> would like >>>>>> to remove the volume data inside. >>>>>> >>>>>> So what we want is to peel off the surface from the segmented brain >>> area >>>>> and >>>>>> flatten that surface. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Younghoon Kim >>>>>> >>>>>> -- >>>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>>> OMICS Lab >>>>>> Wellman Center, Massachusetts General Hospital >>>>>> Bouma?s Lab >>>>>> ---------------------------------------------- >>>>>> younghoon.h....@gmail.com >>>>>> aktivh...@kaist.ac.kr >>>>>> >>>>>> On July 20, 2016 at 5:00:55 PM, Bruce Fischl ( >>> fis...@nmr.mgh.harvard.edu) >>>>> wrote: >>>>>> >>>>>> Hi Younghoon >>>>>> >>>>>> what structure are you talking about? In general it doesn't make >>> sense to >>>>>> flatten volumetric structures. We flatten the cortex, which is a >>> folded >>>>>> 2D sheet. What would you do with the interior of the volume? >>>>>> >>>>>> cheers >>>>>> Bruce >>>>>> On Wed, 20 Jul >>>>>> 2016, Younghoon Kim wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> We have a volumetric data (mgz file) of a segmented brain >>> region. We >>>> want >>>>>> to detect >>>>>>> the surface of this segmented brain volume (i.e. deep brain >>>> region) >>> and >>>>>> flatten it >>>>>>> into a 2D image with its original surface texture. >>>>>>> >>>>>>> We?ve noticed that Freesurfer supports an algorithm to flatten >>>> volumetric >>>>>> data. We >>>>>>> wonder if this could be adapted to our data set. Can anyone offer >>> some >>>>>> advice on >>>>>>> how to apply FreeSurfer to this more generic task? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Younghoon Kim >>>>>>> >>>>>>> -- >>>>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>>>> OMICS Lab >>>>>>> Wellman Center, Massachusetts General Hospital >>>>>>> Bouma?s Lab >>>>>>> ---------------------------------------------- >>>>>>> younghoon.h....@gmail.com >>>>>>> aktivh...@kaist.ac.kr >>>>>>> >>>>>>> _______________________________________________ >>>>>> Freesurfer mailing list >>>>>> 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@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@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@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. >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> http://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/attachments/20160721/39b392eb/attachment-0001.html >>> >>> ------------------------------ >>> >>> Message: 29 >>> Date: Thu, 21 Jul 2016 11:15:31 -0400 (EDT) >>> From: Bruce Fischl <fis...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] Flattening the surface >>> To: Freesurfer support list <freesurfer@nmr.mgh.harvard.edu> >>> Message-ID: >>> <alpine.lrh.2.20.1607211107410.25...@gate.nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset="utf-8" >>> >>> and 255 is the label that you want to cover? 16G may not be enough. Do >>> you >>> have any machines with more RAM? >>> >>> On Thu, 21 Jul 2016, Younghoon >>> Kim wrote: >>> >>>> Hi Bruce, >>>> >>>> Yes Brain_FS.mgz is a segmented volume. It?s not a MRI image, and the >>>> size is about 3000x2000x140. (We obtained this brain image using >>>> different imaging methods) >>>> >>>> Our machine has 16GB RAM. >>>> >>>> Thanks, >>>> >>>> Younghoon Kim >>>> >>>> -- >>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>> OMICS Lab >>>> ---------------------------------------------- >>>> younghoon.h....@gmail.com >>>> aktivh...@kaist.ac.kr >>>> >>>> >>>> On July 21, 2016 at 10:35:18 AM, Bruce Fischl >>>> (fis...@nmr.mgh.harvard.edu) wrote: >>>> >>>> is Brain_FS.mgz a segmented volume? How much memory do you have on that >>>> machine? >>>> >>>> On Wed, 20 Jul 2016, Younghoon Kim wrote: >>>> >>>>> Hi Bruce, >>>>> >>>>> I tried "mri_tessellate Brain_FS.mgz 255 lh_test.orig.nofix? command >>>> to generate a >>>>> surface, but received an error message as below: >>>>> >>>>> changing type of input volume to 8 bits/voxel... >>>>> $Id: mri_tessellate.c,v 1.36 2011/03/02 00:04:25 nicks Exp $ >>>>> ? $Id: mrisurf.c,v 1.693.2.7 2013/05/12 22:28:01 nicks Exp $ >>>>> Cannot calloc() >>>>> >>>>> Would this be because my input data is not compatible with the >>>> mri_tessellate >>>>> command? >>>>> >>>>> Thanks, >>>>> >>>>> Younghoon Kim >>>>> >>>>> -- >>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>> OMICS Lab >>>>> Wellman Center, Massachusetts General Hospital >>>>> Bouma?s Lab >>>>> ---------------------------------------------- >>>>> younghoon.h....@gmail.com >>>>> aktivh...@kaist.ac.kr >>>>> >>>>> On July 20, 2016 at 5:29:24 PM, Bruce Fischl >>>> (fis...@nmr.mgh.harvard.edu) wrote: >>>>> >>>>> If you have a segmented volume, you can use mri_tessellate to create >>>> the >>>>> surface, then introduce the cut(s) and run mris_flatten -1 on the >>>> resulting >>>>> patch. You can check out our wiki >>>>> >>>>> http://surfer.nmr.mgh.harvard.edu/fswiki >>>>> >>>>> which has info on this process, although the flattening isn't >>>> terribly >>>> well >>>>> documented. You need the -1 flag to tell it to only use that one >>>> surface >>>>> that you are giving it, and not to assume that the entire FS >>>> directory >>>>> structure exists. >>>>> >>>>> cheers >>>>> Bruce >>>>> >>>>> >>>>> On Wed, 20 Jul 2016, Younghoon Kim wrote: >>>>> >>>>>> Hi Bruce, >>>>>> >>>>>> Great! I?m not an expert in FreeSurfer, so can you give me some >>>> advice how >>>>> to >>>>>> generate a surface of our volumetric data and flatten it? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Younghoon Kim >>>>>> >>>>>> -- >>>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>>> OMICS Lab >>>>>> Wellman Center, Massachusetts General Hospital >>>>>> Bouma?s Lab >>>>>> ---------------------------------------------- >>>>>> younghoon.h....@gmail.com >>>>>> aktivh...@kaist.ac.kr >>>>>> >>>>>> On July 20, 2016 at 5:12:59 PM, Bruce Fischl >>>> (fis...@nmr.mgh.harvard.edu) >>>>> wrote: >>>>>> >>>>>> HI Younghoon >>>>>> >>>>>> I guess that could work. You will need to introduce at least one >>>> cut >>>> if not >>>>>> more if you surface has substantial Gaussian curvature >>>>>> >>>>>> cheers >>>>>> Bruce >>>>>> >>>>>> >>>>>> On Wed, >>>>>> 20 Jul 2016, Younghoon Kim wrote: >>>>>> >>>>>>> Hi Bruce, >>>>>>> >>>>>>> We are only interested in the surface image of the volumetric >>>> data. >>>>>>> >>>>>>> For flattening, we do not care about the interior of the volume, >>>> so we >>>>>> would like >>>>>>> to remove the volume data inside. >>>>>>> >>>>>>> So what we want is to peel off the surface from the segmented >>>> brain area >>>>>> and >>>>>>> flatten that surface. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Younghoon Kim >>>>>>> >>>>>>> -- >>>>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>>>> OMICS Lab >>>>>>> Wellman Center, Massachusetts General Hospital >>>>>>> Bouma?s Lab >>>>>>> ---------------------------------------------- >>>>>>> younghoon.h....@gmail.com >>>>>>> aktivh...@kaist.ac.kr >>>>>>> >>>>>>> On July 20, 2016 at 5:00:55 PM, Bruce Fischl >>>> (fis...@nmr.mgh.harvard.edu) >>>>>> wrote: >>>>>>> >>>>>>> Hi Younghoon >>>>>>> >>>>>>> what structure are you talking about? In general it doesn't make >>>> sense to >>>>>>> flatten volumetric structures. We flatten the cortex, which is a >>>> folded >>>>>>> 2D sheet. What would you do with the interior of the volume? >>>>>>> >>>>>>> cheers >>>>>>> Bruce >>>>>>> On Wed, 20 Jul >>>>>>> 2016, Younghoon Kim wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> We have a volumetric data (mgz file) of a segmented brain >>>> region.?We >>>>> want >>>>>>> to detect >>>>>>>> the surface of this segmented brain volume (i.e. deep brain >>>> region) and >>>>>>> flatten it >>>>>>>> into a 2D image with?its original surface texture. >>>>>>>> >>>>>>>> We?ve noticed that Freesurfer supports an algorithm to flatten >>>>> volumetric >>>>>>> data. We >>>>>>>> wonder if this could be adapted to our data set.?Can anyone >>>> offer some >>>>>>> advice on >>>>>>>> how to apply FreeSurfer to this more generic task? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Younghoon Kim >>>>>>>> >>>>>>>> -- >>>>>>>> Younghoon Kim,Dep. of Bio and Brain Engineering, KAIST >>>>>>>> OMICS Lab >>>>>>>> Wellman Center, Massachusetts General Hospital >>>>>>>> Bouma?s Lab >>>>>>>> ---------------------------------------------- >>>>>>>> younghoon.h....@gmail.com >>>>>>>> aktivh...@kaist.ac.kr >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> Freesurfer mailing list >>>>>>> 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@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@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@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. >>>> >>>> >>>> >>> >>> ------------------------------ >>> >>> Message: 30 >>> Date: Thu, 21 Jul 2016 11:28:02 -0400 >>> From: Douglas N Greve <gr...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] Subtracting overlays >>> To: freesurfer@nmr.mgh.harvard.edu >>> Message-ID: <5790ea02.1070...@nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset=windows-1252; format=flowed >>> >>> You can use fscalc (which is a frontend for mris_calc) and handles all >>> file format issues >>> >>> On 07/21/2016 09:35 AM, Bruce Fischl wrote: >>>> Hi Tobias >>>> >>>> yes, mris_calc should do it. If you give the output extension .mgz it >>>> will save in that format instead of curv I believe (and will work fine >>>> as an overlay) >>>> >>>> cheers >>>> Bruce >>>> >>>> >>>> On Thu, 21 Jul 2016, Granberg, Erik Tobias wrote: >>>> >>>>> Hi, >>>>> Is there a way to subtract one surface overlay from another (for >>>>> example in >>>>> fsaverage) and still having the output being an .mgh overlay file? >>>>> I saw that mis_calc does a similar procedure but automatically >>>>> outputs the result >>>>> as out.mgz. >>>>> >>>>> Thank you for the help! >>>>> >>>>> Kind regards, >>>>> Tobias >>>>> >>>>> _________________________________________ >>>>> Tobias Granberg, MD, PhD >>>>> >>>>> Post-doctoral research fellow >>>>> A.A. Martinos Center for Biomedical Imaging >>>>> Massachusetts General Hospital | Harvard Medical School >>>>> >>>>> Resident in Radiology >>>>> Karolinska Institutet | Department of Clinical Science, Intervention >>>>> and Technology >>>>> Karolinska University Hospital | Department of Radiology >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> Freesurfer@nmr.mgh.harvard.edu >>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> -- >>> Douglas N. Greve, Ph.D. >>> MGH-NMR Center >>> gr...@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/ >>> >>> >>> >>> ------------------------------ >>> >>> Message: 31 >>> Date: Thu, 21 Jul 2016 11:38:37 -0400 >>> From: Douglas N Greve <gr...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] Error with mri_glmfit_sim (dev version f) >>> To: freesurfer@nmr.mgh.harvard.edu >>> Message-ID: <5790ec7d.3080...@nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset=windows-1252; format=flowed >>> >>> what is your mri_glmfit-sim command line? >>> >>> On 07/20/2016 05:56 PM, Nicola Toschi wrote: >>>> Hi List, >>>> >>>> I am getting a couple of strange error when running a 3-group F-test. >>>> >>>> WARNING: unrecognized mri_glmfit cmd option mri_glmfit.bin >>>> WARNING: 251446 NaNs found in volume >>>> analysis/Ftest/cache.th20.pos.sig.cluster.mgh... >>>> >>>> And as a result, I consistently get huge clusters: >>>> >>>> # ClusterNo Max VtxMax Size(mm^2) MNIX MNIY MNIZ CWP >>>> CWPLow CWPHi NVtxs WghtVtx Annot >>>> 1 inf 0 63247.45 -38.8 -19.0 66.9 0.00010 >>>> 0.00000 0.00020 98722 inf precentral >>>> >>>> However, this doesn't happen when running t-tests on the same data. >>>> Still, I think my F-contrast is correct (see below). >>>> >>>> Thanks in advance for any advice! >>>> >>>> Nicola >>>> >>>> PS: >>>> >>>> my F-contrast looks like this: >>>> >>>> 1 -1 0 0 0 0 >>>> 1 0 -1 0 0 0 >>>> >>>> and my design matrix looks like this: >>>> >>>> 0 0 1 1 179 110 >>>> 0 0 1 1 193 103 >>>> 0 0 1 1 176 108 >>>> 0 0 1 1 198 94 >>>> 0 1 0 1 186 87 >>>> 0 1 0 1 217 83 >>>> ..... >>>> >>>> and my versions are >>>> >>>> # $Id: mri_surfcluster.c,v 1.57 2014/03/06 17:02:46 greve Exp $ >>>> # $Id: mrisurf.c,v 1.776 2015/12/17 18:09:34 fischl Exp $ >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> Freesurfer@nmr.mgh.harvard.edu >>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>>> >>>> >>> >>> -- >>> Douglas N. Greve, Ph.D. >>> MGH-NMR Center >>> gr...@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/ >>> >>> >>> >>> ------------------------------ >>> >>> Message: 32 >>> Date: Thu, 21 Jul 2016 11:41:34 -0400 >>> From: Douglas N Greve <gr...@nmr.mgh.harvard.edu> >>> Subject: Re: [Freesurfer] registering subject pial to fsaverage >>> To: freesurfer@nmr.mgh.harvard.edu >>> Message-ID: <5790ed2e.6020...@nmr.mgh.harvard.edu> >>> Content-Type: text/plain; charset=windows-1252; format=flowed >>> >>> >>> So if I understand, you used mri_surf2surf to map the curv from your >>> subject to fsaverage. You then viewed the original curv on the original >>> subject and then you viewed the fsaveage-mapped curv on faverage and you >>> find that they are very similar. Is that right? This would not surprise >>> me much. If you still have questions, pictures would help alot >>> >>> >>> On 07/21/2016 10:50 AM, Trisanna Sprung-Much wrote: >>>> Hi Doug >>>> >>>> What I mean to say is that the pial surface created by recon-all and >>>> the pial surface that has been nonlinearly registered to fsaverage >>>> look pretty much identical in sulcal patterns, but I do not understand >>>> how this can be the case if one surface has been registered to a >>>> surface template based on cortical folding. >>>> Shouldn't the cortical folding for this registered surface change even >>>> a little bit? >>>> >>>> best >>>> Trisanna >>>> >>>> >>>> -- >>>> Ph.D. Candidate >>>> McGill University >>>> Integrated Program in Neuroscience >>>> Psychology >>>> >>>> >>>> On Tue, Jul 19, 2016 at 10:29 PM, Douglas Greve >>>> <gr...@nmr.mgh.harvard.edu <mailto:gr...@nmr.mgh.harvard.edu>> wrote: >>>> >>>> I don't understand what you did or what the problem is. Can you >>>> elaborate? >>>> >>>> >>>> On 7/19/16 5:23 PM, Trisanna Sprung-Much wrote: >>>>> Hi there >>>>> >>>>> I tested registering a subject's pial surface to fsaverage and >>>>> compared the original pial (from recon-all) with this registered >>>>> pial surface. It turns out that they are almost identical in >>>>> nature, and I am wondering how this is possible if recon-all does >>>>> not alter the input data. >>>>> >>>>> Below is the command that I ran. Is there something I am missing >>>>> here? >>>>> >>>>> many thanks >>>>> >>>>> Trisanna >>>>> >>>>> >>>>> trisanna@kaplan:~$ mri_surf2surf --srcsubject icbm-102 --sval-xyz >>>>> pial --trgsubject fsaverage --tval-xyz --tval lh.pial.icbm102 >>>>> --hemi lh >>>>> srcsubject = icbm-102 >>>>> srcval = (null) >>>>> srctype = >>>>> trgsubject = fsaverage >>>>> trgval = lh.pial.icbm102 >>>>> trgtype = >>>>> srcsurfreg = sphere.reg >>>>> trgsurfreg = sphere.reg >>>>> srchemi = lh >>>>> trghemi = lh >>>>> frame = 0 >>>>> fwhm-in = 0 >>>>> fwhm-out = 0 >>>>> label-src = (null) >>>>> label-trg = (null) >>>>> OKToRevFaceOrder = 1 >>>>> Reading source surface reg >>>>> /data-01/trisanna/freesurfer/icbm-102/surf/lh.sphere.reg >>>>> Loading source data >>>>> Reading surface file >>>>> /data-01/trisanna/freesurfer/icbm-102/surf/lh.pial >>>>> Reading target surface reg >>>>> /data-01/trisanna/freesurfer/fsaverage/surf/lh.sphere.reg >>>>> Done >>>>> Mapping Source Volume onto Source Subject Surface >>>>> surf2surf_nnfr: building source hash (res=16). >>>>> Surf2Surf: Forward Loop (163842) >>>>> >>>>> surf2surf_nnfr: building target hash (res=16). >>>>> Surf2Surf: Reverse Loop (169941) >>>>> Reverse Loop had 44416 hits >>>>> Surf2Surf: Dividing by number of hits (163842) >>>>> INFO: nSrcLost = 0 >>>>> nTrg121 = 131435, nTrgMulti = 32407, MnTrgMultiHits = 2.37057 >>>>> nSrc121 = 140014, nSrcLost = 0, nSrcMulti = 29927, >>>>> MnSrcMultiHits = 2.28035 >>>>> Saving target data >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Ph.D. Candidate >>>>> McGill University >>>>> Integrated Program in Neuroscience >>>>> Psychology >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freesurfer mailing list >>>>> Freesurfer@nmr.mgh.harvard.edu >>>>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>>> >>>> >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> Freesurfer@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@nmr.mgh.harvard.edu >>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> -- >>> Douglas N. Greve, Ph.D. >>> MGH-NMR Center >>> gr...@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@nmr.mgh.harvard.edu >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> End of Freesurfer Digest, Vol 149, Issue 42 >>> ******************************************* >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >> >> > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
