[Freesurfer] freesurfer 6 hippocampal longitudinal processing workflow question, more LH than RH files

[Salil Soman]

Hi,

I have run a number of cases through the FS6 hippocampal longitudinal
processing steps listed at
https://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalHippocampalSubfields
and https://surfer.nmr.mgh.harvard.edu/fswiki/LongitudinalProcessing

It seems that all steps completed, but when it came time to collect the
results, I find I have many more lh.hippoSfVolumes-T1.long.v10.txt (67)
than rh.hippoSfVolumes-T1.long.v10.txt files (25). Any suggestions on what
I may be doing incorrectly?

Thanks!

Salil Soman
___
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.

Re: [Freesurfer] Fwd: wm edits not incorporated

[Octavian Lie]

Thank you,
this is very helpful.
Octavian

On Thu, Apr 13, 2017 at 12:19 PM, Antonin Skoch  wrote:

> Dear Octavian,
>
> the current philosophy with wm.mgz edits is not to directly affect voxel 
> values in original T1 image.
>
> The wm.mgz serves as starting point for the white surface estimation. The 
> ?h.white surface is estimated according gradient in voxel values in 
> brain.finalsurfs.mgz (which is, basically, preprocessed T1 image) using 
> basically preprocessed surfaces obtained from wm.mgz (?h.orig) as a starting 
> position where to search for intensity gradient.
> The editing of wm.mgz helps to find out the GM/WM itensity gradient and 
> properly place ?h.white there.
> Therefore, where there is insufficient GM/WM contrast, the wm.mgz cannot help 
> out. I think that there is no change in the behavior between v5.3 and v6.0 in 
> this aspect. I have seen many cases where wm.mgz edit does not help to 
> improve ?h.white surfaces in the data processed by v5.3.
>
> There is an -overlay option in mris_make_surfaces which explicitly modifies 
> voxel values in input image for mris_make_surfaces (brain.finalsurfs.mgz as 
> default in recon-all). However, this option only works for cases when wm.mgz 
> is extended, not deleted:
> In voxels which have value 255 in wm.mgz, it replaces current voxel value in 
> input image by desired value of white matter. This option is currently not 
> used in recon-all.
> I would opt for implementation of similar option for deletion of voxels in 
> wm.mgz: Where wm.mgz voxel values equal 1, to replace input image voxel 
> values by desired values of GRAY matter. This should force ?h.white to 
> directly follow edits of wm.mgz
>
> As for editing of 001.mgz, beware the pitfall with editing images with 
> mutually different geometry in FreeView I posted today:
>
> http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52729.html
>
> Antonin Skoch
>
>
> Dear All,
>
> Regarding wm.mgz edits not incorporated into wm surface, which seems to
> have been reported on by several of us with FS 6.00. I followed Antonin's
> idea of editing 001.mgz by switching wm-intensity voxels clearly not wm
> (mostly in the subtemporal regions, at times close to bright dural portions
> in the crown) to gm intensities and ran recon-all -all, and this time all
> was OK. So it seems that the problem is that on re-initializing during
> -autorecon2-wm rerun, the routine does not edit out high intensity voxels
> even if manually excluded in wm.mgz. This seems to be different to some
> extent with how FS 5.3 was reacting, although I did not look at this
> systematically. There may be a reason that manual editing is just part of
> the story during rerun and does not automatically override the recon
> stream, but I do not know it.
> Octavian
>
>
>
>
> -- Forwarded message --
> From: Octavian Lie 
> Date: Sun, Apr 2, 2017 at 7:59 PM
> Subject: wm edits not incorporated
> To: octavian lie 
>
>
>
> Dear Bruce,
>
> I just transferred subject r02.tar.gz.
>
> Again, wm.mgz edits (all deleted voxels, no additions) are not incorporated
> on reruns using any of the
> recon-all -autorecon-wm -aitorecon3
> recon-all -autorecon2 -autorecon3
> recon-all -make all
>
> FOr example, the complete command line for  a rerun is
>
> recon-all -autorecon2-wm -autorecon3 -3T -bigventricles -cw256 -subjid r02
> -parallel > output.txt &
>
>
> Here are some of the edited voxels which are not excluded from the wm on
> rerun:
>
>
> -40.14, -2.67, 116.29 coronal slice 132
> 12.73, -23.67, 126.16 coronal slice 171
> 14.05, 12.33, 11.61 coronal slice 147
>
>
> ___
> 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.

Re: [Freesurfer] Freeview - corrupted pixel values after saving volume (via save as) when images with mutually different geometry are simultaneously loaded

[Antonin Skoch]

Dear Ruopeng,

thank you for the feedback. Yes, the behavior is exacly like you described. I 
suspected that this has something to do with resampling but I was not sure.
The stripes were result of nearest-neighbor interpolation.

Antonin


Hi Antonin,

When you load two images like that, the second image will be resampled,  using 
nearest neighbor method by default. And when you save, it will be  resampled 
back to its original space. So there will be shifted voxels  depending how 
oblique it is to the first image. So I think what you  observe makes sense. 
That is also why you should always edit volumes in  their local space. I didn't 
find any screenshots in your last email but my guess is the  oblique strip is 
due to nearest neighbor resampling. You can choose  "-trilinear" or "-cubic" in 
the command line when you load the images. Best,
Ruopeng

On 04/13/2017 12:28 PM, Antonin Skoch wrote:
Dear experts,

I encountered following issue with freeview:

When two images with mutually different geometry are simultaneously  loaded and 
one of them is saved (via save as), its pixel values get  somewhat corrupted. 
There are strips in image with modified pixel  values. It seems to affect only 
the latter image in the pair. Example (001.mgz and brainmask.mgz have different 
geometry):

freeview brainmask.mgz orig/001.mgz

Then I saved 001.mgz as 001_2.mgz (using "save as") and loaded  001_2.mgz to 
freeview. The attached screenshots show original 001.mgz  and 001_2.mgz with 
corrupted pixels. Note new oblique strips. This is not only display issue. The 
mri_diff 001.mgz 001_2.mgz outputs:

diffcount 287447
Volumes differ in pixel data
maxdiff 966. at 171 255 30 0

I am using recent development version of freesurfer from 04/2017.

Regards,

Antonin Skoch___
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.

Re: [Freesurfer] Surface down sample by taking cortical vertices only

[Dorothy Sincasto]

Hi

It is for computing sources correlation with symmetrical orthogonalized
correlations which is dependent on the rank of the data, so I am limited to
the number of sensors I use for estimating sources.

I would appreciate to know if there is any method to get about a 100
cortical vertices in the cortical surface, maybe with the inflated surface
generate an equidistant grid.

Thanks
Dorothy

On Mon, Apr 10, 2017 at 1:53 PM, dg wakeman  wrote:

> Hi Dorothy,
>
> That would be extreme under sampling. I don't expect it to be very
> meaningful.
>
> hth
> d
>
> On Mon, Apr 10, 2017 at 2:42 PM, Dorothy Sincasto 
> wrote:
> > Hi
> >
> > I want to do an MEG analysis and first I want to downsample the surface
> to
> > around 100 vertices per hemisphere.  I tried the command mris_downsample,
> > but when i plot the surface I see that the vertices go deep into the
> white
> > matter.
> >
> > Is there an option to extract for example 100 equidistant vertices from a
> > fsaverage?  Maybe knowing  how the vertices are organized when saved
> would
> > help, so for example, when I load a surface in matlab the vertices are
> shown
> > as a vector, is there a way to know the spatial order?
> >
> > Thanks
> > Dorothy
> >
> >
> > ___
> > 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
>
___
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.

Re: [Freesurfer] Fwd: wm edits not incorporated

[Antonin Skoch]

Dear Octavian,

the current philosophy with wm.mgz edits is not to directly affect voxel values 
in original T1 image.

The wm.mgz serves as starting point for the white surface estimation. The 
?h.white surface is estimated according gradient in voxel values in 
brain.finalsurfs.mgz (which is, basically, preprocessed T1 image) using 
basically preprocessed surfaces obtained from wm.mgz (?h.orig) as a starting 
position where to search for intensity gradient.
The editing of wm.mgz helps to find out the GM/WM itensity gradient and 
properly place ?h.white there.
Therefore, where there is insufficient GM/WM contrast, the wm.mgz cannot help 
out. I think that there is no change in the behavior between v5.3 and v6.0 in 
this aspect. I have seen many cases where wm.mgz edit does not help to improve 
?h.white surfaces in the data processed by v5.3. 

There is an -overlay option in mris_make_surfaces which explicitly modifies 
voxel values in input image for mris_make_surfaces (brain.finalsurfs.mgz as 
default in recon-all). However, this option only works for cases when wm.mgz is 
extended, not deleted: 
In voxels which have value 255 in wm.mgz, it replaces current voxel value in 
input image by desired value of white matter. This option is currently not used 
in recon-all. 
I would opt for implementation of similar option for deletion of voxels in 
wm.mgz: Where wm.mgz voxel values equal 1, to replace input image voxel values 
by desired values of GRAY matter. This should force ?h.white to directly follow 
edits of wm.mgz

As for editing of 001.mgz, beware the pitfall with editing images with mutually 
different geometry in FreeView I posted today:

http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52729.html

Antonin Skoch


Dear All,

Regarding wm.mgz edits not incorporated into wm surface, which seems to
have been reported on by several of us with FS 6.00. I followed Antonin's
idea of editing 001.mgz by switching wm-intensity voxels clearly not wm
(mostly in the subtemporal regions, at times close to bright dural portions
in the crown) to gm intensities and ran recon-all -all, and this time all
was OK. So it seems that the problem is that on re-initializing during
-autorecon2-wm rerun, the routine does not edit out high intensity voxels
even if manually excluded in wm.mgz. This seems to be different to some
extent with how FS 5.3 was reacting, although I did not look at this
systematically. There may be a reason that manual editing is just part of
the story during rerun and does not automatically override the recon
stream, but I do not know it.
Octavian


-- Forwarded message --
From: Octavian Lie 
Date: Sun, Apr 2, 2017 at 7:59 PM
Subject: wm edits not incorporated
To: octavian lie 



Dear Bruce,

I just transferred subject r02.tar.gz.

Again, wm.mgz edits (all deleted voxels, no additions) are not incorporated
on reruns using any of the
recon-all -autorecon-wm -aitorecon3
recon-all -autorecon2 -autorecon3
recon-all -make all

FOr example, the complete command line for  a rerun is

recon-all -autorecon2-wm -autorecon3 -3T -bigventricles -cw256 -subjid r02
-parallel > output.txt &


Here are some of the edited voxels which are not excluded from the wm on
rerun:


-40.14, -2.67, 116.29 coronal slice 132
12.73, -23.67, 126.16 coronal slice 171
14.05, 12.33, 11.61 coronal slice 147___
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.

Re: [Freesurfer] Freeview - corrupted pixel values after saving volume (via save as) when images with mutually different geometry are simultaneously loaded

[Ruopeng Wang]

Hi Antonin,

When you load two images like that, the second image will be resampled, 
using nearest neighbor method by default. And when you save, it will be 
resampled back to its original space. So there will be shifted voxels 
depending how oblique it is to the first image. So I think what you 
observe makes sense. That is also why you should always edit volumes in 
their local space.


I didn't find any screenshots in your last email but my guess is the 
oblique strip is due to nearest neighbor resampling. You can choose 
"-trilinear" or "-cubic" in the command line when you load the images.


Best,
Ruopeng

On 04/13/2017 12:28 PM, Antonin Skoch wrote:

Dear experts,

I encountered following issue with freeview:

When two images with mutually different geometry are simultaneously 
loaded and one of them is saved (via save as), its pixel values get 
somewhat corrupted. There are strips in image with modified pixel 
values. It seems to affect only the latter image in the pair.


Example (001.mgz and brainmask.mgz have different geometry):

freeview brainmask.mgz orig/001.mgz

Then I saved 001.mgz as 001_2.mgz (using "save as") and loaded 
001_2.mgz to freeview. The attached screenshots show original 001.mgz 
and 001_2.mgz with corrupted pixels. Note new oblique strips.


This is not only display issue. The mri_diff 001.mgz 001_2.mgz outputs:

diffcount 287447
Volumes differ in pixel data
maxdiff 966. at 171 255 30 0

I am using recent development version of freesurfer from 04/2017.

Regards,

Antonin Skoch


___
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


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.

Re: [Freesurfer] manual edits

[Antonin Skoch]

Dear John, David,

To great summarization of David, I would add following:

My personal preference is to run whole -autorecon2 -autorecon3 after editing of 
the brainmask.mgz. 
Early stages of -autorecon2 (normalization, registration, volumetric labeling) 
use brainmask.mgz, therefore I believe that their results can be improved when 
improved brainmask.mgz is provided (especially when the edits of the 
brainmask.mgz are of large extent).

When the pial surface extends to the cerebellum, different edits are needed as 
specified here:

http://freesurfer.net/fswiki/FsTutorial/PialEdits_freeview

Antonin Skoch



Hi David,
Thank you for the feedback! I followed your advice's and everything has been 
resolved. Highly appreciated!Cheers,
John

Sent with [ProtonMail](https://protonmail.com) Secure Email.

 Original Message 
Subject: Re: [Freesurfer] manual edits
Local Time: April 12, 2017 11:04 AM
UTC Time: April 12, 2017 3:04 PM
From: seman...@nyspi.columbia.edu
To: John Anderson , freesurfer@nmr.mgh.harvard.edu 


Hi John,

Yes understanding how freesurfer deals with edits can be a bit confusing. I 
have a lot of experience doing edits to the wm.mgz and brainmask.mgz for cross 
sectional data in Freesurfer 5.3 so perhaps I can help.

Recon-all is basically a script which runs a series of about 25 or so 
processing steps in a defined sequence. The software generally will be able to 
recognize when an edit has been done at a particular intervention point and 
will take those edits into account when running that step unless you 
specifically instruct it not to.

The most common types of edits are edits to the wm.mgz to fix white matter 
defects and tissue incorrectly identified as white matter, and edits to the 
brainmask.mgz to fix cases where the skull strip is insufficient to prevent 
dura and other non-cortical tissue from making it into the gray matter/pial 
surfaces. White matter edits need to be done directly on the wm.mgz and gray 
matter/skull strip edits need to be done on the brainmask.mgz. Editing those 
two files and saving them directly in freeview is sufficient to register those 
edits for recon-all.

If you have edited only the brainmask.mgz, it is sufficient to run 
–autorecon-pial since the white matter surfaces will not need to be 
regenerated. If you have edited the wm.mgz, you must run –autorecon2-wm (or 
–autorecon2-cp if you used control points as well as white matter edits). If 
you have edited both the brainmask.mgz and the wm.mgz, then you only need to 
run –autorecon2-wm since the pial surfaces will be regenerated taking into 
account the brainmask.mgz edits as part of that workflow. Keep in mind that you 
still need to run –autorecon3 to complete the reprocessing of these data 
(-autorecon-pial includes the steps from –autorecon3) but that can be done when 
you are happy with your final surfaces if you want to save processing time on 
iterative edits.

Here is the wiki page referring to edits: 
https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/TroubleshootingData

I hope this is helpful.

Best,

David P. Semanek, HCISPP

Research Technician, Posner Lab

Division of Child and Adolescent Psychiatry

Columbia University Medical Center

New York State Psychiatric Institute

1051 Riverside Drive, Pardes Bldg. Rm. 2424

New York, NY 10032

PH: (646) 774-5885

IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who was not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.

From:  John Anderson 
Reply-To: John Anderson 
Date: Wednesday, April 12, 2017 at 6:45 AM
To: "freesurfer@nmr.mgh.harvard.edu" 
Subject: [Freesurfer] manual edits

Dear Freesurfer experts,

I am not an expert in manual edits, so I highly appreciate any feedback 
regarding the issues in my questions below. I ran the following command line 
“recon-all -s subjid -all” on T1 image for one of the subjects. when reviewing 
the output images (i.e. wm.mgz, brainmask.mgz) I found issues as attached.

Attached is an output of the command: "Freeveiw orig.mgz wmparc.mgz wm.mgz"

1. When I reviewed “wm.mgz” I see interactions between the white matter (wm), 
and the cortex (yellow arrows). To fix this, I edited “wm.mgz” by removing the 
wm voxels from the cortex, and the data was saved in the file “wm.seg.mgz”

2. I found many holes in many slices similar to the (black arrow). I filled all 
these holes. The data saved in “wm.seg.mgz”

3. I fixed some issues related to dura 

[Freesurfer] Freeview - corrupted pixel values after saving volume (via save as) when images with mutually different geometry are simultaneously loaded

[Antonin Skoch]

Dear experts,

I encountered following issue with freeview: 

When two images with mutually different geometry are simultaneously loaded and 
one of them is saved (via save as), its pixel values get somewhat corrupted. 
There are strips in image with modified pixel values. It seems to affect only 
the latter image in the pair.

Example (001.mgz and brainmask.mgz have different geometry):

freeview brainmask.mgz orig/001.mgz

Then I saved 001.mgz as 001_2.mgz (using "save as") and loaded 001_2.mgz to 
freeview. The attached screenshots show original 001.mgz and 001_2.mgz with 
corrupted pixels. Note new oblique strips.

This is not only display issue. The mri_diff 001.mgz 001_2.mgz outputs:

diffcount 287447
Volumes differ in pixel data
maxdiff 966. at 171 255 30 0

I am using recent development version of freesurfer from 04/2017.

Regards,

Antonin Skoch
___
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.

Re: [Freesurfer] trac-all -stat

[Yendiki, Anastasia]

OK, thanks Amelia. That's interesting - keep me posted if you run into this 
with 6.0 in any new data set.


From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Versace, Amelia 
[versa...@upmc.edu]
Sent: Thursday, April 13, 2017 10:24 AM
To: Freesurfer support list
Subject: Re: [Freesurfer] trac-all -stat

Thanks, Anastasia!!
It should be it. I had run the same command before with slightly fewer subjects 
in my "set subjlist" and it did work fine. Then I rerun the -path (and added 
extra 18 subjects) to update the tracts with the recent implementation that you 
have done (FS 6). After, started having this issue with -stat However, I 
ended up running the dmri_group after manually creating the *inputs.txt files 
and it did work fine... ;-)
Thanks, Amelia

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Yendiki, Anastasia
Sent: Wednesday, April 12, 2017 5:04 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] trac-all -stat

Hi Amelia - This means that it can't find any of the tracts that you've 
specified (or any tracts period, if you haven't specified a list) for the 
subjects that you've specified in your config file. It'd be looking under:

/data/dprojects/BIOS/tracula/$subj/dpath/

Best,
a.y


From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Versace, Amelia 
[versa...@upmc.edu]
Sent: Wednesday, April 12, 2017 5:00 PM
To: Freesurfer support list
Subject: [Freesurfer] trac-all -stat

Hi Anastasia,

I am having some issues with the -stat option. Below is the error. I am not 
sure of what's causing the issue. Any idea?
Thanks a lot!! Amelia

-
trac-all -c scripts/dmrirc.stats -stat

INFO: SUBJECTS_DIR is /data/dprojects/BIOS/freesurfer
INFO: Diffusion root is /data/dprojects/BIOS/tracula Actual FREESURFER_HOME 
/data/software/freesurfer6
ERROR: no pathway reconstructions found
-

___
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


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

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] trac-all -stat

[Versace, Amelia]

Thanks, Anastasia!!
It should be it. I had run the same command before with slightly fewer subjects 
in my "set subjlist" and it did work fine. Then I rerun the -path (and added 
extra 18 subjects) to update the tracts with the recent implementation that you 
have done (FS 6). After, started having this issue with -stat However, I 
ended up running the dmri_group after manually creating the *inputs.txt files 
and it did work fine... ;-)
Thanks, Amelia

-Original Message-
From: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Yendiki, Anastasia
Sent: Wednesday, April 12, 2017 5:04 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] trac-all -stat

Hi Amelia - This means that it can't find any of the tracts that you've 
specified (or any tracts period, if you haven't specified a list) for the 
subjects that you've specified in your config file. It'd be looking under:

/data/dprojects/BIOS/tracula/$subj/dpath/

Best,
a.y


From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Versace, Amelia 
[versa...@upmc.edu]
Sent: Wednesday, April 12, 2017 5:00 PM
To: Freesurfer support list
Subject: [Freesurfer] trac-all -stat

Hi Anastasia,

I am having some issues with the -stat option. Below is the error. I am not 
sure of what's causing the issue. Any idea?
Thanks a lot!! Amelia

-
trac-all -c scripts/dmrirc.stats -stat

INFO: SUBJECTS_DIR is /data/dprojects/BIOS/freesurfer
INFO: Diffusion root is /data/dprojects/BIOS/tracula Actual FREESURFER_HOME 
/data/software/freesurfer6
ERROR: no pathway reconstructions found
-

___
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


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

Re: [Freesurfer] Bits of dura being captured as GM ..

[Bruce Fischl]

Hi Shane

by far the best way to do this is if you have a T2 or FLAIR scan that is 
high-enough resolution (i.e. around 1mm isotropic).


If not, you can try the graph cuts skull stripping option in recon-all. 
It is more aggressive than the watershed (which is the default).


cheers
Bruce



On Wed, 12 
Apr 2017, Shane S wrote:



Hi Freesurfer Users,
I am checking my data and there are many scans with a bit of dura
being captured as GM. I have attached some screenshots below. This happens
in more than 50% of my subjects.  I am removing them manually them
using Freeview, then running the autorecon-pial. But this will take a lot of
time on 200+ subjects.. Does anyone have any tips to deal with these little
inclusions? 
Thanks =)

[8D698381-1005-4719-B2FC-E8C0C496FB50_1_preview.jpg]
[EDA1574B-CAF0-45E7-ACDE-CDD777931400_1_preview.jpg]
[F256742A-4829-462D-A98F-3CC27AE52E01_1_preview.jpg]

Best Wishes,
Shane

___
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] mri_watershed script not working

[Mario Rossi]

Hello FreeSurfer Developers and experts,

I am trying to run our FSPGR sequences using the  -mri_watershed script, but I 
am not able to set and vary the -t threshold.
The aim of my work is to calculate the BPF in order to quantify parenchymal 
atrophy in patients with Multiple Sclerosis.

Instead of using the whole "-recon-all" command, I have tried to reduce the 
amount of datas (and the very long  time needed to calculate them) performing 
this script:

"-mri_watershed -atlas"

The result of the extraction of the brain is good and fast, but I still could 
need to adjust the cut limits. I have tried to modify it into this new script:

"-mri_watershed -atlas -t X"

(where "X" stands for a variable between 0 and 50) but in this case, no matter 
what "X" I choose the results are all identical.

Is it possible to set a -t threshold using -atlas?
If not, can you suggest us how to change our approach?
Is it possibile to use freesurfer with FLAIR sequences with the same aim 
(extract the BPF to evaluate  brain atrophy)?

Best regards,
Mario Rossi


1) FreeSurfer version:  freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0
2) Platform: Linux Mint  1 Debian MATE 64-bit



___
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.

Re: [Freesurfer] Using own parcellation atlas

[Bruce Fischl]

Hi Julie

what space is the Gordon Parcellation in? Did they use FreeSurfer? If so, 
then you just need to map it to each of your subjects.


And how is a surface-based parcellation stored in a nifti file?

cheers
Bruce



On Wed, 12 Apr 2017, Julie Hall 
wrote:



Hi experts,

I would like to use a different atlas other than the 'default' Freesurfer 
atlases, namely the Gordon Parcellation (surface based parcellation of 
333 ROIs of the cortex) to segment my T1 datasets. So I can go on to use 
these segmentations for DTI connectome analysis using MRTrix (or MatLab). 
I have two questions:

- I have this atlas as a nifti file. Do I need to transform this atlas
  into a different file for it to run in freesurfer?
- Can I run this step in autorecon3 (step 28)? Or should I rerun recon-all all 
together? If so, could you help me with what commands I need to run 
(mris_ca_train?)”


Thank you,
Julie


___
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


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.

Re: [Freesurfer] mris_ca_label giving error CTABfindAnnotation: ct was NULL

[Das S.]

Thanks . Its working now.
___T_
From: freesurfer-boun...@nmr.mgh.harvard.edu 
[freesurfer-boun...@nmr.mgh.harvard.edu] on behalf of Bruce Fischl 
[fis...@nmr.mgh.harvard.edu]
Sent: 11 April 2017 16:48
To: Freesurfer support list
Subject: Re: [Freesurfer] mris_ca_label giving error CTABfindAnnotation: ct was 
NULL

when you run mris_ca_train use -t  and it will embed it
in the .gcs file

On Tue, 11 Apr 2017, Das S. wrote:

> Hi,
> I have created a color table, an annot file and a .gcs file( attached with 
> the mail).
> But when I am trying to execute mris_ca_label with my own .gcs file I am 
> getting the error :
>
> mris_ca_label -l 100307/label/lh.cortex.label -aseg 
> 100307/mri/aseg.presurf.mgz 100307 lh lh.sphere.reg 
> 100307/label/lh.eq40aparc.gcs lh.aparc.annot
> using 100307/mri/aseg.presurf.mgz aseg volume to correct midline
> $Id: mris_ca_label.c,v 1.37 2014/02/04 17:46:42 fischl Exp $
>  $Id: mrisurf.c,v 1.781.2.6 2016/12/27 16:47:14 zkaufman Exp $
> reading atlas from 100307/label/lh.eq40aparc.gcs...
> average std = 0.2   using min determinant for regularization = 0.001
> 0 singular and 185 ill-conditioned covariance matrices regularized
> input 0: MEAN CURVATURE, flags 0, avgs 5, name mean_curvature
> labeling surface...
> CTABfindAnnotation: ct was NULL
> No such file or directory
> CTABfindAnnotation: ct was NULL
> No such file or directory
> CTABfindAnnotation: ct was NULL
> No such file or directory
>
> .
>
> Before this I have used the below commands, to sucessfully create the .annot 
> and .gcs file:
> 1. To create .annot file from label files and CTAB file--
> mris_label2annot --s 100307 --h lh --no-unknown --ctab 
> 100307/label/eq_parcellation_label/MyColorLUT.txt --a eq40aparc --ldir 
> 100307/label/eq_parcellation_label
>
> 2. To crate .gcs file from annot file.
> mris_ca_train rh 100307/surf/rh.sphere 100307/label/rh.eq40aparc.annot 100307 
> 100307/label/rh.eq40aparc.gcs
>
> I am not be able to understand where is the problem.
> Any help will be appreciated.
> Thanks
> Sarbani
>
___
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

Re: [Freesurfer] manual edits

[John Anderson]

Hi David,
Thank you for the feedback! I followed your advice's and everything has been 
resolved. Highly appreciated!

Cheers,
John

Sent with [ProtonMail](https://protonmail.com) Secure Email.

 Original Message 
Subject: Re: [Freesurfer] manual edits
Local Time: April 12, 2017 11:04 AM
UTC Time: April 12, 2017 3:04 PM
From: seman...@nyspi.columbia.edu
To: John Anderson , freesurfer@nmr.mgh.harvard.edu 


Hi John,

Yes understanding how freesurfer deals with edits can be a bit confusing. I 
have a lot of experience doing edits to the wm.mgz and brainmask.mgz for cross 
sectional data in Freesurfer 5.3 so perhaps I can help.

Recon-all is basically a script which runs a series of about 25 or so 
processing steps in a defined sequence. The software generally will be able to 
recognize when an edit has been done at a particular intervention point and 
will take those edits into account when running that step unless you 
specifically instruct it not to.

The most common types of edits are edits to the wm.mgz to fix white matter 
defects and tissue incorrectly identified as white matter, and edits to the 
brainmask.mgz to fix cases where the skull strip is insufficient to prevent 
dura and other non-cortical tissue from making it into the gray matter/pial 
surfaces. White matter edits need to be done directly on the wm.mgz and gray 
matter/skull strip edits need to be done on the brainmask.mgz. Editing those 
two files and saving them directly in freeview is sufficient to register those 
edits for recon-all.

If you have edited only the brainmask.mgz, it is sufficient to run 
–autorecon-pial since the white matter surfaces will not need to be 
regenerated. If you have edited the wm.mgz, you must run –autorecon2-wm (or 
–autorecon2-cp if you used control points as well as white matter edits). If 
you have edited both the brainmask.mgz and the wm.mgz, then you only need to 
run –autorecon2-wm since the pial surfaces will be regenerated taking into 
account the brainmask.mgz edits as part of that workflow. Keep in mind that you 
still need to run –autorecon3 to complete the reprocessing of these data 
(-autorecon-pial includes the steps from –autorecon3) but that can be done when 
you are happy with your final surfaces if you want to save processing time on 
iterative edits.

Here is the wiki page referring to edits: 
https://surfer.nmr.mgh.harvard.edu/fswiki/FsTutorial/TroubleshootingData

I hope this is helpful.

Best,

David P. Semanek, HCISPP

Research Technician, Posner Lab

Division of Child and Adolescent Psychiatry

Columbia University Medical Center

New York State Psychiatric Institute

1051 Riverside Drive, Pardes Bldg. Rm. 2424

New York, NY 10032

PH: (646) 774-5885

IMPORTANT NOTICE: This e-mail is meant only for the use of the intended 
recipient. It may contain confidential information which is legally privileged 
or otherwise protected by law. If you received this e-mail in error or from 
someone who was not authorized to send it to you, you are strictly prohibited 
from reviewing, using, disseminating, distributing or copying the e-mail. 
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS 
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.

From:  John Anderson 
Reply-To: John Anderson 
Date: Wednesday, April 12, 2017 at 6:45 AM
To: "freesurfer@nmr.mgh.harvard.edu" 
Subject: [Freesurfer] manual edits

Dear Freesurfer experts,

I am not an expert in manual edits, so I highly appreciate any feedback 
regarding the issues in my questions below. I ran the following command line 
“recon-all -s subjid -all” on T1 image for one of the subjects. when reviewing 
the output images (i.e. wm.mgz, brainmask.mgz) I found issues as attached.

Attached is an output of the command: "Freeveiw orig.mgz wmparc.mgz wm.mgz"

1. When I reviewed “wm.mgz” I see interactions between the white matter (wm), 
and the cortex (yellow arrows). To fix this, I edited “wm.mgz” by removing the 
wm voxels from the cortex, and the data was saved in the file “wm.seg.mgz”

2. I found many holes in many slices similar to the (black arrow). I filled all 
these holes. The data saved in “wm.seg.mgz”

3. I fixed some issues related to dura and bad skullstipping

Then I ran the command:

“recon-all -autorecon2-wm -autorecon3 -subjid ” which output the file 
“brain.finalsurfs.mgz”

and the command

“recon-all -autorecon-pial -subjid ”

Now, I want to understand where Freesurfer implement the new edits? Which files 
will be used as the main files that include the new edits. Logically, the edits 
must be implemented in "wm.mgz" and "brainmask.mgz". What confuses me is when I 
open orig.mgz wm.mgz and brainmask.mgz in freesview. I see the original 
non-edited files. I am not sure what I am doing wrong so I highly appreciate 
any help.

Re: [Freesurfer] Longitudinal Pipeline

[Martin Reuter]

Yes, that is why it is experimental. 

However, global atrophy will affect the ventricles (they are growing) which is 
an effect in the opposite direction, so maybe it cancels out to some extend. 

Best, Martin

> On 12 Apr 2017, at 23:55, Arman Eshaghi  wrote:
> 
> Thanks Martin. Should I be worried about affine transform masking out the 
> global atrophy if I am using the whole brain (no skull stripping)?
> 
> Arman
> 
> On Wed, Apr 12, 2017 at 9:36 PM, Martin Reuter  > wrote:
> Hi Arman,
> 
> should be possible by passing the - - affine flag. I think I also 
> experimented around with a -base-affine flag to recon-all for that (instead 
> of -base). It is experimental!
> 
> Best, Martin
> 
> 
> > On 07 Apr 2017, at 13:34, Arman Eshaghi  > > wrote:
> >
> > Hi,
> >
> > I wonder if there is a way for mri_robust_template to perform iterative 
> > registration with 9 DOF rather than 6-7 default. The rational is to allow 
> > for a bit of scaling to adjust for potential scanner drifts in a 
> > longitudinal study over years.
> >
> > Thanks,
> > Arman
> > ___
> > 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 
> 
> 
> 
> 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

___
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.