> 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

Reply via email to