Re: [Freesurfer] 'help: aparcstats2table'

[Nolan, Jackson]

Hello Dr. Zeynep,

Are you running those commands in the directory containing that subject? The 
script needs the file path to the subject, and absolute paths tend to work 
better than relative paths.

If you have specified these are still getting those errors, please send your 
full terminal output with the command run and all error messages.

Best,
Jackson

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Zeynep Boz 

Sent: Saturday, May 29, 2021 3:15 PM
To: freesurfer@nmr.mgh.harvard.edu 
Subject: [Freesurfer] 'help: aparcstats2table'


External Email - Use Caution

Hello,
I am using Ubuntu 18.05 version and Freesurfer6 version.
I've completed all the recon-all parts without any problems, but I'm having 
trouble with the "aparcstats2table" part.
The command "aparcstats2table --subject H1_deneme --hemi lh --meas thickness 
--tablefile lh.thicknes.xlsx" gives the following error:
   File "/usr/local/freesurfer/bin/aparcstats2table", line 156
 print 'ERROR: atleast 1 subject must be provided'
   On the command "asegstats2table --subjects H1_deneme H1 --common-segs --meas 
volume --stats = aseg.stats --table = segstats.txt" gives the following error:
   File "/usr/local/freesurfer/bin/asegstats2table", line 195
 print 'ERROR: subjects are not specified (use --subjects SUBJECTS)'
Thank you in advance for your support



Dr.Zeynep YÜKSEL
Ondokuz Mayis University
Vocational School of Health Services,
Medical İmaging
55139, Atakum, Samsun, Turkey
Tel: +903623121919 Ext:5261

___
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 Mass General Brigham 
Compliance HelpLine at http://www.massgeneralbrigham.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.
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail. 

[Freesurfer] Time courses and Yeo’s boundaries

[stdp82]

 
 External Email - Use Caution
  
   Hi,
  
  
   
  
  
   I have two questions please:
  
  
   
  
  
   Hi
  
  
   
  
  
   1. I’d like to extract the time courses of fMRI data from some selected ROIs.
  
  
   How can I do it? For Yeo’s ROI (splitted atlas) is better to do it on surface or operate in volume?
  
  
   
  
  
   2. I’m using version 6.0. Probably also due to Mac OS X update, I can not use tksurfer. The using freeview I can not overlap the Yeo’s bunduries on FAST results. Freeviewer overlaps colored dots to indetify the location of Yeo’s components.
  
  
   How can I do to overlap on FAST results Yeo’s bundaries?
  
  
   
  
  
   Best regard
  
 

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

Re: [Freesurfer] Tracula registration failure

[Marena Manierka]

External Email - Use Caution

Hello Anastasia,

Not sure if you've had a chance to look at my previous message. I've
manually gone through the registrations of all the subjects in my dataset
now in Freeview. Although the anatomical scans appear to be complete, the
dtifit images show significant clipping of the temporal lobes in almost
every individual (even those scans where tracula prep, bedp and path steps
worked without casting an error). Is it still possible for me to run
tracula on this dataset? Should I be re-processing all subjects with the
config file set up to exclude the ILF tracts, or can I pull the data and
simply exclude those tracts running through temporal lobes in my final
analysis?

Any advice would be greatly appreciated. I'm new to this type of analysis
and no one in my lab has published using TRACULA previously.

Thanks very much,
Marena

On Wed, May 26, 2021 at 1:47 PM Marena Manierka 
wrote:

> Hi Anastasia,
>
> Thank you so much for your reply. I noticed the truncated temporal lobes
> in the registered dti_FA.bbr, but I do not see the same problem in either
> the T1.mgz or the aparc+aseg.mgz when loaded into freeview. In the
> subject's native space diffusion weighted image (dtifit_FA.nii.gz) it does
> seem like a portion of the temporal lobes is cut off.
>
> Let me know if there are other files/ screenshots I can provide to help
> with solving this issue.
>
> Best,
> Marena
>
> On Wed, May 26, 2021 at 1:04 PM Yendiki, Anastasia <
> ayend...@mgh.harvard.edu> wrote:
>
>> Hi Marena - How does the T1 of this subject and its freesurfer
>> segmentation (aparc+aseg) look? In the image the brain looks truncated, is
>> that the case with the T1?
>>
>> Anastasia.
>> --
>> *From:* freesurfer-boun...@nmr.mgh.harvard.edu <
>> freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Marena Manierka <
>> marena.manie...@gmail.com>
>> *Sent:* Tuesday, May 25, 2021 8:47 PM
>> *To:* freesurfer@nmr.mgh.harvard.edu 
>> *Subject:* [Freesurfer] Tracula registration failure
>>
>>
>> External Email - Use Caution
>>
>> To the Tracula team:
>>
>> I am attempting to complete my first project using the Tracula pipeline
>> on a mixed dataset of autism, schizophrenia, and control adult brains. I
>> ran the tracula prep, bedp and path steps for the autistic subject in
>> question without receiving any error messages. However, when I attempt to
>> view the registration of the FA.bbr.nii.gz image to the MNI brain the
>> registered image appears as a completely white, roughly brain-shaped mask.
>> This has not occurred with other subjects from the dataset. I have attached
>> a screenshot from freeview for reference.
>> When I load the subject's dtifit_FA.nii.gz in freeview it appears to be
>> relatively normal. Is this a fatal error in the registration process, and
>> is there any way to correct it?
>> I have also attached the log file for the subject in case this is helpful.
>>
>> Thank you for your help,
>> Marena
>>
>>
>> --
>> Marena Manierka, B.Sc
>> Graduate Student, Integrative Program in Neuroscience
>> Department of Psychology, MSS 414/ MS0296
>> University of Nevada, Reno
>> marena.manie...@gmail.com
>> ___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu
>> https://secure-web.cisco.com/1LDd5MsrztbHpVGjKftRDr9ofphqfDSzmEAwMmtMuXOHkLKE3xOpRsLTvE-NeXNKjDV9eCsF8oPIkmfLrtHkInK8AInc0CadwDeemj-0zPZO-HJmACcdw3ziLTcdNtuRUXcQYZGWN7EZn6oycr2eT3Fxhrn5rJ6yepj7exlJeua71WJQg1xzMEzcgksbZBQpJpV0CL__hLJQ2UDeu5DuilvRvDDkhFCNfCX8fIj4kFJCErlXhs7jTc-I6iN717yDQbdC5W2D58eGmQhao7Bijdw/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer
>> 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 Mass General
>> Brigham Compliance HelpLine at
>> http://secure-web.cisco.com/1-c7UY348j9-LDtjFFdGTs_uGqZ9ogrTO4m0sA1treUqdq5JyI-TC2JSH70vswRN_rGvoGl9XaDXI678GI0d8hjpJSoDELNODDlkQGH_D7xfv_0kKKA4Uw7XU6gBvVX4cpzKDU266ns4Q08WG2ROxise5Vu8eqMjJeA740C5jqr7H5ZYPGgNtYdJuerglGUWICTREtjAOVK6OaHUiMuDOgeUAF-q1ycXQm2ADZRvTQ4lU0wyIJPvadql9r2dsilSJAktuAog3xF58CUtGBuggXQ/http%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline
>>  . 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.
>> Please note that this e-mail is not secure (encrypted).  If you do not
>> wish to continue communication over unencrypted e-mail, please notify the
>> sender of this message immediately.  Continuing to send or respond to
>> e-mail after receiving this message means you understand and accept this
>> risk and wish to continue to communicate over unencrypted e-mail.
>>
>
>
> --
> Marena Manierka, B.Sc
> Graduate Student, Integrative Program in Neuroscience
> Department of Psychology, MSS 414/ MS0296
> Univer

Re: [Freesurfer] mris_fix_topology taking ages

[Ellen Ji]

   External Email - Use Caution


thanks Bruce and Douglas,
I was able to see the holes by looking at the surface of 
?h.smoothwm.nofix and I found the Freesurfer tutorial on how to correct 
topological defects.


However, as the automatic topology fixer runs during recon-all, how do 
we know that it failed? I see "CORRECTING DEFECT" for multiple defects 
in the recon-all.log, so I'm assuming it's fixing those holes.
How can I determine whether it's worth it to go in and manually fix 
them? Is there an indication somewhere?


Thank you!

On 6/2/2021 4:40 PM, Fischl, Bruce wrote:


Hi Diana

It’s not the number of defects that matters – it is the large ones. 
The time it takes to correct them is square in the (convex hull of 
the) number of vertices in the defect. We have a tutorial on our 
website about how to find them and fix them. I find it easiest to load 
the ?h.orig.nofix over the wm.mgz and norm.mgz then load the 
?h.defect_labels to onto the ?h.orig.nofix to color the vertices that 
are in a defect


Cheers

Bruce

*From:* freesurfer-boun...@nmr.mgh.harvard.edu 
 *On Behalf Of *DIANA ORTEGA CRUZ

*Sent:* Wednesday, June 2, 2021 3:12 AM
*To:* Freesurfer support list 
*Subject:* Re: [Freesurfer] mris_fix_topology taking ages

*External Email - Use Caution *

Dear Douglas and Bruce,

my name is Diana, I am encountering the same issue as Ellen with 
Fix-topology taking too long. Once we make sense of the origin of the 
issue (for example, I confirmed that my smoothwm.nofix has a lot of 
holes), do you know if is there any way to solve it? Could the data be 
modified in some way to get through this step?


Thanks a lot for your great help!! Best wishes,

Diana Ortega.

El mié, 2 jun 2021 a las 3:13, Fischl, Bruce (>) escribió:


Or the ?h.inflated.nofix can be helpful as well

*From:* freesurfer-boun...@nmr.mgh.harvard.edu

mailto:freesurfer-boun...@nmr.mgh.harvard.edu>> *On Behalf Of
*Douglas N. Greve
*Sent:* Tuesday, June 1, 2021 5:57 PM
*To:* freesurfer@nmr.mgh.harvard.edu

*Subject:* Re: [Freesurfer] mris_fix_topology taking ages

I mean mris_fix_topology. Try loading the ?h.smoothwm.nofix in
surface viewing (not in the volume). You can often see defects
better on this surface (they look likes holes or handles; you
should at least see some)

On 6/1/2021 4:55 PM, Ellen Ji wrote:

*External Email - Use Caution *

Hi Doug, when you say it did not finish, could you clarify
what process "it" refers to?
I loaded the files you suggested and nothing popped out to me
aside from the fact that the wm.mgz didn't seem to cover all
the white matter.
Is it possible that topology error labels don't necessarily
suggest that something went wrong and I can trust the results?
Thanks.

On 6/1/2021 2:51 AM, Douglas N. Greve wrote:

The topology error labels might be be created if it did
not finish. YOu can try just loading the brain.mgz, the
wm.mgz, and the orig.nofix and see if you can find a big
topo error

On 5/31/2021 11:16 AM, Ellen Ji wrote:

External Email - Use Caution
Dear experts,

mris_fix_topology has been running for several hours
now and the log suggests many more defects than
normal. I tried to follow Bruce's advice from the
thread here

https://secure-web.cisco.com/11N_pSFTUOEZsMU7wtMNfIhMmRNWqmvsxTQeTGxdl-E3X_FJ9XkuZNLzTomdCZZwiiC6gS9oiXPNWh-M2KVbb9fP-1Qt7J-woH5hdLFg1otls4745ZoOKkz_-HOcFhenNfrq2-hdM_aX4I_g63u4rUe-NJLArGfWzCA77LLGm4lm0GK5kbCLf4Y6EqC9wHUUa-pdXC-7yMwNoi3Ips7HILVXXSdMEYlu_BPlUFIyI78yqCt3CSo6lAnlXS7QmRQY6JMl9WsV56bEMNqz44Bdlkw/https%3A%2F%2Fwww.mail-archive.com%2Ffreesurfer%40nmr.mgh.harvard.edu%2Fmsg03182.html

,
but wasn't able to load the &h.defect_labels as I
received the error below.

Attached is part of the recon-all.log (starting from
mris_fix_topology). Is there any other way to
check/visualize what might have gone wrong?
FYI, I'm running recon-all thru the HCP Pipeline. Thanks!

tksurfer avoss_01 lh defect_labels

subject is avoss_01
hemi    is lh
surface is defect_labels
 

Re: [Freesurfer] mris_fix_topology taking ages

[Fischl, Bruce]

Hi Diana

It’s not the number of defects that matters – it is the large ones. The time it 
takes to correct them is square in the (convex hull of the) number of vertices 
in the defect. We have a tutorial on our website about how to find them and fix 
them. I find it easiest to load the ?h.orig.nofix over the wm.mgz and norm.mgz 
then load the ?h.defect_labels to onto the ?h.orig.nofix to color the vertices 
that are in a defect

Cheers
Bruce

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 On Behalf Of DIANA ORTEGA CRUZ
Sent: Wednesday, June 2, 2021 3:12 AM
To: Freesurfer support list 
Subject: Re: [Freesurfer] mris_fix_topology taking ages


External Email - Use Caution
Dear Douglas and Bruce,

my name is Diana, I am encountering the same issue as Ellen with Fix-topology 
taking too long. Once we make sense of the origin of the issue (for example, I 
confirmed that my smoothwm.nofix has a lot of holes), do you know if is there 
any way to solve it? Could the data be modified in some way to get through this 
step?

Thanks a lot for your great help!! Best wishes,
Diana Ortega.

El mié, 2 jun 2021 a las 3:13, Fischl, Bruce 
(mailto:bfis...@mgh.harvard.edu>>) escribió:
Or the ?h.inflated.nofix can be helpful as well

From: 
freesurfer-boun...@nmr.mgh.harvard.edu
 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 On Behalf Of Douglas N. Greve
Sent: Tuesday, June 1, 2021 5:57 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] mris_fix_topology taking ages

I mean mris_fix_topology. Try loading the ?h.smoothwm.nofix in surface viewing 
(not in the volume). You can often see defects better on this surface (they 
look likes holes or handles; you should at least see some)
On 6/1/2021 4:55 PM, Ellen Ji wrote:

External Email - Use Caution
Hi Doug, when you say it did not finish, could you clarify what process "it" 
refers to?
I loaded the files you suggested and nothing popped out to me aside from the 
fact that the wm.mgz didn't seem to cover all the white matter.
Is it possible that topology error labels don't necessarily suggest that 
something went wrong and I can trust the results?
Thanks.
On 6/1/2021 2:51 AM, Douglas N. Greve wrote:
The topology error labels might be be created if it did not finish. YOu can try 
just loading the brain.mgz, the wm.mgz, and the orig.nofix and see if you can 
find a big topo error
On 5/31/2021 11:16 AM, Ellen Ji wrote:
   External Email - Use Caution
Dear experts,

mris_fix_topology has been running for several hours now and the log suggests 
many more defects than normal. I tried to follow Bruce's advice from the thread 
here 
https://secure-web.cisco.com/11N_pSFTUOEZsMU7wtMNfIhMmRNWqmvsxTQeTGxdl-E3X_FJ9XkuZNLzTomdCZZwiiC6gS9oiXPNWh-M2KVbb9fP-1Qt7J-woH5hdLFg1otls4745ZoOKkz_-HOcFhenNfrq2-hdM_aX4I_g63u4rUe-NJLArGfWzCA77LLGm4lm0GK5kbCLf4Y6EqC9wHUUa-pdXC-7yMwNoi3Ips7HILVXXSdMEYlu_BPlUFIyI78yqCt3CSo6lAnlXS7QmRQY6JMl9WsV56bEMNqz44Bdlkw/https%3A%2F%2Fwww.mail-archive.com%2Ffreesurfer%40nmr.mgh.harvard.edu%2Fmsg03182.html,
 but wasn't able to load the &h.defect_labels as I received the error below.

Attached is part of the recon-all.log (starting from mris_fix_topology). Is 
there any other way to check/visualize what might have gone wrong?
FYI, I'm running recon-all thru the HCP Pipeline. Thanks!

tksurfer avoss_01 lh defect_labels

subject is avoss_01
hemiis lh
surface is defect_labels
surfer: current subjects dir: 
/home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w
surfer: not in "scripts" dir ==> using cwd for session root
surfer: session root data dir ($session) set to:
surfer: /mnt/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01/surf
checking for nofix files in 'defect_labels'
Reading image info 
(/home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01)
Reading 
/home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01/mri/orig.mgz
surfer: Reading header info from 
/home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01/mri/orig.mgz
nquads=4063237,  nvertices=664
ERROR: MRISread: file 
'/home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01/surf/lh.defect_labels'
 has many more faces than vertices!
Probably trying to use a scalar data file as a surface!

No such file or directory


___

Freesurfer mailing list

Freesurfer@nmr.mgh.harvard.edu

MailScanner has detected a possible fraud attempt from "secure-web.cisco.com" 
claiming to be 
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Recon-all error :Segmentation fault (core dumped)

[liub]

External Email - Use Caution

Yeah,you are right!

The prolem has been solved after modifying the 'bc' path.




Thank you very much!

Have a good day :)!

-原始邮件-
发件人:"Douglas N. Greve" 
发送时间:2021-06-02 05:52:10 (星期三)
收件人: freesurfer@nmr.mgh.harvard.edu
抄送:
主题: Re: [Freesurfer] Recon-all error :Segmentation fault (core dumped)

Actually, I think I see what the problem is. You apparently have a command 
called "bc" in your path. mri_nu_correct.mni is trying to use the linux-native 
bc command (a simple calculator usually located in /bin). What do you get when 
you run
which bc



On 6/1/2021 9:59 AM, liub wrote:


External Email - Use Caution

Thank you for your help !





I have run the command:

mri_nu_correct.mni --debug --i orig.mgz --o nu.mgz --uchar 
transforms/talairach.xfm --n 2 --ants-n4 >& nucor.log

and got the nucor.log.







-原始邮件-
发件人:"Douglas N. Greve" 
发送时间:2021-06-01 08:35:38 (星期二)
收件人:freesurfer@nmr.mgh.harvard.edu
抄送:
主题: Re: [Freesurfer] Recon-all error :Segmentation fault (core dumped)

Not sure, can you try this
cd /home/liubing/FreeSurfer/data/test_recon/ANDI1/mri
mri_nu_correct.mni --debug --i orig.mgz --o nu.mgz --uchar 
transforms/talairach.xfm --n 2 --ants-n4 >& nucor.log
and send the file nucor.log





On 5/28/2021 7:51 AM, liub wrote:


External Email - Use Caution

Hello FreeSurfer Developers,




I'm attempting to recon-all my NIfTI-1 data ,while after a few minutes of 
running,there was an error:

mris_calc -o /dev/shm/tmp.mri_nu_correct.mni.897826/nu0.mgz 
/dev/shm/tmp.mri_nu_correct.mni.897826/nu0.mgz mul

Segmentation fault (core dumped) 

Command exited with non-zero status 1

Also when I ran the command "recon-all -all -s bert" using the official data in 
*/freesurfer/subjects/bert ,it raised the same error. I googled this error,but 
there's still no answer.I've attached the recon-all.log. The recon-all.log is 
belong to bert and recon-all(1).log is belong to my data.

Here is my operating system info :

uname -a: Linux HEUBME.com 4.18.0-193.28.1.el8_2.x86_64 #1 SMP Thu Oct 22 
00:20:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Platform: CentOS Linux release 8.3.2011

FreeSurfer version: freesurfer-Linux-centos8_x86_64-7.1.1




Thank you for your kind help.




Best regards.



___
Freesurfer mailing list freesur...@nmr.mgh.harvard.eduMailScanner has detected 
a possible fraud attempt from "secure-web.cisco.com" claiming to be 
https://secure-web.cisco.com/1B5w2wF5qwtbUrPtw-T-AhxHsn6nFRaiABYGIwTWlprmPaq6YiwiBPcsu9d72mLiNviRyhNO5nYHnfhC4BUWrTBJP6OKL2r5K1-1lJ7xu6LLiHfOgOG9lfic2WKaGPa7aqyT-R2b4BIFo5jk0HGbx_b8_1SzR1UhMjJoY9O7xFrIqtvUe6ze2h9Jh5WuHvnbtGp4pJMzyTbeG2y8x6jwNuNnWR54_2fBc3ZpfR8IUEz9i9o9DwQK0eS84FG3TGjzT26m4GZoHoJzvZi03umKrEg/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer



___
Freesurfer mailing list 
freesur...@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

Re: [Freesurfer] recon-all errors

[Mark Wagshul]

External Email - Use Caution

Doug,

Thanks. The one thing I thought of - the FLAIR data were hi-res 3D FLAIR which 
have a pretty long T2 and not great grey/white contrast (it's an MS project, so 
mostly acquired for quantifying lesion load). Not sure if this would affect the 
calculations. I tried playing around with the T2_min/max_inside/outside 
parameter going into mris_place_surface, but that didn't seem to help.
One more thing. I don't see this in the recon-all.log file, but when I try to 
individually run mris_place_surface, it quits with a segmentation fault. Not 
sure if that helps, or why this error wouldn't show up in the log file.

Thanks for the help!

Mark


Mark Wagshul, PhD
Associate Professor
Gruss Magnetic Resonance Research Center
Albert Einstein College of Medicine
Bronx, NY 10461

Ph: 718-430-4011
FAX: 718-430-3399
Email: mark.wags...@einsteinmed.org

[einstein-logo-rgb]
This email message and any accompanying attachments may contain privileged 
information intended only for the named recipient(s). If you are not the 
intended recipient(s), you are hereby notified that the dissemination, 
distribution, and or copying of this message is strictly prohibited. If you 
receive this message in error, or are not the named recipient(s), please notify 
the sender at the email address above, delete this email from your computer, 
and destroy any copies in any form immediately.


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 On Behalf Of Douglas N. Greve
Sent: Tuesday, June 1, 2021 6:02 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] recon-all errors

OK, I'll have to take a look at the data. Someone will be in touch about 
getting it.

On 6/1/2021 11:02 AM, Mark Wagshul wrote:

External Email - Use Caution

External Email - Use Caution
It works fine in 6.0, was in 7.1. The registration looks fine (the FLAIR is 
brain extracted, while the orig.mgz is not, is this expected, or was that my 
error, I don't recall which FLAIR image I fed in).

Mark


Mark Wagshul, PhD
Associate Professor
Gruss Magnetic Resonance Research Center
Albert Einstein College of Medicine
Bronx, NY 10461

Ph: 718-430-4011
FAX: 718-430-3399
Email: mark.wags...@einsteinmed.org

[einstein-logo-rgb]
This email message and any accompanying attachments may contain privileged 
information intended only for the named recipient(s). If you are not the 
intended recipient(s), you are hereby notified that the dissemination, 
distribution, and or copying of this message is strictly prohibited. If you 
receive this message in error, or are not the named recipient(s), please notify 
the sender at the email address above, delete this email from your computer, 
and destroy any copies in any form immediately.


From: 
freesurfer-boun...@nmr.mgh.harvard.edu
 

 On Behalf Of Douglas N. Greve
Sent: Thursday, May 27, 2021 6:13 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] recon-all errors

Can you check the registration of the FLAIR and T1?
cd subject/mri
 tkregisterfv --mov orig/FLAIRraw.mgz --reg transforms/FLAIRraw.lta --targ 
orig.mgz



On 5/20/2021 4:33 PM, Mark Wagshul wrote:

External Email - Use Caution

External Email - Use Caution
Hi. I'm trying to run recon-all, with T1 and FLAIR images and running into 
errors, which seem to be associated with the FLAIR refinement of the pial 
surface.

recon-all -s 2019-10049-045-SP -FLAIR 
2019-10049-045-SP/VISIT_1/RAW/105_3D_FLAIR_SAGBrain.nii.gz -FLAIRpial -all


1.   Freesurfer version: 
freesurfer-Linux-centos6_x86_64-stable-pub-v6.0.0-2beb96c

2.   cat /proc/version:  Linux version 2.6.32-696.6.3.el6.694g.x86_64 
(root@-home-lgu-olaf-RHEL-6ES-9-x86_64.larkspur)
 (gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC) ) #1 SMP Wed Jul 12 
02:19:57 UTC 2017

3.   uname -a: Linux loginnode2 2.6.32-696.6.3.el6.694g.x86_64 #1 SMP 
Wed Jul 12 02:19:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

4.   recon-all.log attached

Thanks!

Mark


Mark Wagshul, PhD
Associate Professor
Gruss Magnetic Resonance Research Center
Albert Einstein College of Medicine
Bronx, NY 10461

Ph: 718-430-4011
FAX: 718-430-3399
Email: mark.wags...@einsteinmed.org

[einstein-logo-rgb]
This email message and any accompanying attachments may contain privileged 
information intended only for the named recipient(s). If you are not the 
intended recipient(s), you are hereby notified that the dissemination, 
distribution, and or copying of this message is strictly prohibited. If you 
receive this message in error, or are not the named recipient(s), please notify 
the sender at the

[Freesurfer] Freeview mghRead error

[Duvnjak, Aleksandar]

External Email - Use Caution

Dear Freesurfer Developers,

I have recently switched to a Mac for ease of use and have encountered an error 
upon trying to view output files from a previous data cohort which were 
processed on a remote computing server and copied to this Mac's local drive. I 
am able to view all surfaces and volumes of the native bert tutorial set, 
however am unable to view my own outputs.

In the terminal I receive the following error:


Katarinas-MacBook-Pro:mdc026 kduvnjak$ freeview -v 
/Applications/freesurfer/subjects/mdc026/mri/wm.mgz

mghRead(/Applications/freesurfer/subjects/mdc026/mri/wm.mgz, -1): could not 
open file

MRIread failed: Unable to read from 
/Applications/freesurfer/subjects/mdc026/mri/wm.mgz

mghRead(/Applications/freesurfer/subjects/mdc026/mri/wm.mgz, -1): could not 
open file

2021-06-02 11:07:49.903 Freeview[6760:441577] modalSession has been exited 
prematurely - check for a reentrant call to endModalSession:

Please find below any additional relevant information:

Freesurfer version: freesurfer-i386-apple-darwin11.4.2-stable6-20170119 
(freesurfer-Darwin-OSX-stable-pub-v6.0.0.dmg)
Platform: macOS Sierra Version 10.12.6
uname -a:

Darwin Katarinas-MacBook-Pro.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Dec 
20 21:53:35 PST 2018; root:xnu-3789.73.31~1/RELEASE_X86_64 x86_64

I am also strangely unable to attach the recon-all file to this email. Perhaps 
this is some sort of permissions issue, although I have sudo chown for this 
user on the dir and that didn't seem to help.

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

Re: [Freesurfer] mris_fix_topology taking ages

[DIANA ORTEGA CRUZ]

External Email - Use Caution

Dear Douglas and Bruce,

my name is Diana, I am encountering the same issue as Ellen with
Fix-topology taking too long. Once we make sense of the origin of the issue
(for example, I confirmed that my smoothwm.nofix has a lot of holes), do
you know if is there any way to solve it? Could the data be modified in
some way to get through this step?

Thanks a lot for your great help!! Best wishes,
Diana Ortega.

El mié, 2 jun 2021 a las 3:13, Fischl, Bruce ()
escribió:

> Or the ?h.inflated.nofix can be helpful as well
>
>
>
> *From:* freesurfer-boun...@nmr.mgh.harvard.edu <
> freesurfer-boun...@nmr.mgh.harvard.edu> *On Behalf Of *Douglas N. Greve
> *Sent:* Tuesday, June 1, 2021 5:57 PM
> *To:* freesurfer@nmr.mgh.harvard.edu
> *Subject:* Re: [Freesurfer] mris_fix_topology taking ages
>
>
>
> I mean mris_fix_topology. Try loading the ?h.smoothwm.nofix in surface
> viewing (not in the volume). You can often see defects better on this
> surface (they look likes holes or handles; you should at least see some)
>
> On 6/1/2021 4:55 PM, Ellen Ji wrote:
>
> *External Email - Use Caution*
>
> Hi Doug, when you say it did not finish, could you clarify what process
> "it" refers to?
> I loaded the files you suggested and nothing popped out to me aside from
> the fact that the wm.mgz didn't seem to cover all the white matter.
> Is it possible that topology error labels don't necessarily suggest that
> something went wrong and I can trust the results?
> Thanks.
>
> On 6/1/2021 2:51 AM, Douglas N. Greve wrote:
>
> The topology error labels might be be created if it did not finish. YOu
> can try just loading the brain.mgz, the wm.mgz, and the orig.nofix and see
> if you can find a big topo error
>
> On 5/31/2021 11:16 AM, Ellen Ji wrote:
>
>External Email - Use Caution
> Dear experts,
>
> mris_fix_topology has been running for several hours now and the log
> suggests many more defects than normal. I tried to follow Bruce's advice
> from the thread here
> https://secure-web.cisco.com/11N_pSFTUOEZsMU7wtMNfIhMmRNWqmvsxTQeTGxdl-E3X_FJ9XkuZNLzTomdCZZwiiC6gS9oiXPNWh-M2KVbb9fP-1Qt7J-woH5hdLFg1otls4745ZoOKkz_-HOcFhenNfrq2-hdM_aX4I_g63u4rUe-NJLArGfWzCA77LLGm4lm0GK5kbCLf4Y6EqC9wHUUa-pdXC-7yMwNoi3Ips7HILVXXSdMEYlu_BPlUFIyI78yqCt3CSo6lAnlXS7QmRQY6JMl9WsV56bEMNqz44Bdlkw/https%3A%2F%2Fwww.mail-archive.com%2Ffreesurfer%40nmr.mgh.harvard.edu%2Fmsg03182.html,
> but wasn't able to load the &h.defect_labels as I received the error below.
>
> Attached is part of the recon-all.log (starting from mris_fix_topology).
> Is there any other way to check/visualize what might have gone wrong?
> FYI, I'm running recon-all thru the HCP Pipeline. Thanks!
>
> tksurfer avoss_01 lh defect_labels
>
> subject is avoss_01
> hemiis lh
> surface is defect_labels
> surfer: current subjects dir:
> /home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w
> surfer: not in "scripts" dir ==> using cwd for session root
> surfer: session root data dir ($session) set to:
> surfer:
> /mnt/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01/surf
> checking for nofix files in 'defect_labels'
> Reading image info
> (/home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01)
> Reading
> /home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01/mri/orig.mgz
> surfer: Reading header info from
> /home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01/mri/orig.mgz
> nquads=4063237,  nvertices=664
> ERROR: MRISread: file
> '/home/eji/newdata/projects/avoss/HCP/subjects/avoss_01/T1w/avoss_01/surf/lh.defect_labels'
> has many more faces than vertices!
> Probably trying to use a scalar data file as a surface!
>
> No such file or directory
>
>
> ___
>
> Freesurfer mailing list
>
> Freesurfer@nmr.mgh.harvard.edu
>
> *MailScanner has detected a possible fraud attempt from 
> "secure-web.cisco.com" claiming to be* 
> https://secure-web.cisco.com/18DbLFYnkzpL_VG6cCKRH7JNf1r42Clxkaudup1Kh_EGSchdUrdpc-we4LJpSM1WCPet9d251usmpkBDXwVynpCA3mtsn4t3xWp9BZMVxG7sHawhEM9Mi1ghk2PviC4xhEt_vh6c2zHAscS2d7xgul62j5N2_PbC9Kpox0TTiT9WQQo36N8613LTsj6hZesreFdGLrWG5_yOr3056nU-5HpmpKykz6IzdWLtNLK37CtcxwYBLgTyMdSMfIl-ZLCiOqxoY9ZDQ9VWlYFpAkc8lMA/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer
>  
> 
>
>
>
>
> ___
>
> Freesurfer mailing list
>
> Freesurfer@nmr.mgh.harvard.edu
>
> *MailScanner has detected a possible fraud attempt from 
> "secure-web.cisco.com" claiming to be* 
> https://secure-web.cisco.com/18DbLFYnkzp