Re: [Freesurfer] Recon-all error: could not set locale

[가영 탁]

External Email - Use Caution

Hi Bruce,


Thank you for your prompt response.

Attached is the whole recon-all.log from a failed run.
The complete screen output:

kt@kt-B85M-DS3H-A:~/Downloads/Thalamus$ ./reconall
Subject Stamp: freesurfer-linux-centos7_x86_64-dev-20180703-82d87f8
Current Stamp: freesurfer-linux-centos7_x86_64-dev-20180703-82d87f8
INFO: SUBJECTS_DIR is /home/kt/Downloads/Thalamus/Outputs
Actual FREESURFER_HOME /home/kt/Downloads/freesurferDev
Linux kt-B85M-DS3H-A 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu Jun 14 
13:51:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
'/home/kt/Downloads/freesurferDev/bin/recon-all' -> 
'/home/kt/Downloads/Thalamus/Outputs/161019_x3DT1_SAG/scripts/recon-all.local-copy'
/home/kt/Downloads/Thalamus/Outputs/161019_x3DT1_SAG

 mri_convert /home/kt/Downloads/Thalamus/rf161019_x3DT1_SAG.nii 
/home/kt/Downloads/Thalamus/Outputs/161019_x3DT1_SAG/mri/orig/001.mgz

Could not set locale
No such file or directory
Could not set locale
No such file or directory
Could not set locale
mri_convert.bin /home/kt/Downloads/Thalamus/rf161019_x3DT1_SAG.nii 
/home/kt/Downloads/Thalamus/Outputs/161019_x3DT1_SAG/mri/orig/001.mgz
error parsing license file, expected 4 values
$Id: mri_convert.c,v 1.227 2017/02/16 19:15:42 greve Exp $
reading from /home/kt/Downloads/Thalamus/rf161019_x3DT1_SAG.nii...
--
GNU libc version: 2.19
ERROR: Systems running GNU glibc version greater than 2.15
  require a newly formatted license file (it's free). Please
  download a new one from the following page:
  http://surfer.nmr.mgh.harvard.edu/registration.html
--
Linux kt-B85M-DS3H-A 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu Jun 14 
13:51:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

recon-all -s 161019_x3DT1_SAG exited with ERRORS at 2018. 07. 05. (목) 10:45:52 
KST

For more details, see the log file 
/home/kt/Downloads/Thalamus/Outputs/161019_x3DT1_SAG/scripts/recon-all.log
To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting

Thank you again for your help.

Regards,
Kayeong Tak



From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Bruce Fischl 

Sent: Thursday, July 5, 2018 5:01 AM
To: Freesurfer support list
Subject: Re: [Freesurfer] Recon-all error: could not set locale

Hi Kayeong

can you send us the whole recon-all.log from a failed run and the complete
screen output? The locale is needed to specify the format of numbers I
believe (e.g. 1,00 vs. 1.00)

cheers
Bruce

On Wed, 4 Jul
2018, ?? ? wrote:

>
> External Email - Use Caution
>
> Hi Freesurfer Team,
>
>
> I am aware that segmentation of thalamic nuclei is only available in 
> developmental versions
> of Freesurfer.
>
> After I have downloaded the Freesurfer dev 
> version(freesurfer-linux-centos7_x86_64-dev), I
> get the following error whenever I use the recon-all command:
>
>
> Could not set locale
> No such file or directory
>
>
> Recon-all works fine when I use the stable 6.0 version.
>
> Could anyone tell me how I can fix this problem?
>
>
> Also, I was wondering it is ok to use recon-all from 6.0 version and thalamic 
> nuclei
> analysis from dev version.
>
>
> Thanks in advance,
>
> Kayeong Tak
>
>
>
2018. 07. 05. (목) 10:45:40 KST
/home/kt/Downloads/Thalamus/Outputs/161019_x3DT1_SAG
/home/kt/Downloads/freesurferDev/bin/recon-all
-i rf161019_x3DT1_SAG.nii -subjid 161019_x3DT1_SAG -all
subjid 161019_x3DT1_SAG
setenv SUBJECTS_DIR /home/kt/Downloads/Thalamus/Outputs
FREESURFER_HOME /home/kt/Downloads/freesurferDev
Actual FREESURFER_HOME /home/kt/Downloads/freesurferDev
build-stamp.txt: freesurfer-linux-centos7_x86_64-dev-20180703-82d87f8
Linux kt-B85M-DS3H-A 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu Jun 14 13:51:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
cputime  unlimited
filesize unlimited
datasize unlimited
stacksize8192 kbytes
coredumpsize 0 kbytes
memoryuseunlimited
vmemoryuse   unlimited
descriptors  1024 
memorylocked 64 kbytes
maxproc  63693 
maxlocks unlimited
maxsignal63693 
maxmessage   819200 
maxnice  0 
maxrtprio0 
maxrttimeunlimited

Re: [Freesurfer] Recon-all error: could not set locale

[Bruce Fischl]

Hi Kayeong

can you send us the whole recon-all.log from a failed run and the complete 
screen output? The locale is needed to specify the format of numbers I 
believe (e.g. 1,00 vs. 1.00)


cheers
Bruce

On Wed, 4 Jul 
2018, ?? ? wrote:




External Email - Use Caution

Hi Freesurfer Team,


I am aware that segmentation of thalamic nuclei is only available in 
developmental versions
of Freesurfer.

After I have downloaded the Freesurfer dev 
version(freesurfer-linux-centos7_x86_64-dev), I
get the following error whenever I use the recon-all command:


Could not set locale
No such file or directory


Recon-all works fine when I use the stable 6.0 version.

Could anyone tell me how I can fix this problem?


Also, I was wondering it is ok to use recon-all from 6.0 version and thalamic 
nuclei
analysis from dev version.


Thanks in advance,

Kayeong Tak


___
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] Recon-all error: could not set locale

[?? ?]

External Email - Use Caution

Hi Freesurfer Team,


I am aware that segmentation of thalamic nuclei is only available in 
developmental versions of Freesurfer.

After I have downloaded the Freesurfer dev 
version(freesurfer-linux-centos7_x86_64-dev), I get the following error 
whenever I use the recon-all command:


Could not set locale
No such file or directory


Recon-all works fine when I use the stable 6.0 version.

Could anyone tell me how I can fix this problem?


Also, I was wondering it is ok to use recon-all from 6.0 version and thalamic 
nuclei analysis from dev version.


Thanks in advance,

Kayeong Tak
___
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] Longitudinal processing in v6.0 using manual edits from v5.3.0 - recon-all.log

[Martin Reuter]

Hi Kaley, 

if you scroll down the log file you should find something like
new invocation of recon-all with the correct time stamp and v6 text. The old 
log is kept and the new one is appended. 

I am also not sure it is OK to re-run the base with 6.0. It could be that this 
looks OK in single cases and fails in others. The reason is that in 6.0 the 
position of the base image could be (slightly?) different than 5.3. So your 
edits, e.g. control points, would not be at the right anatomical spot. This is 
not a problem when re-running cross runs. 

You should check if the norm.mgz is at the same location in 5.3 base and the 
6.0 base. 
Also I would re-run the long from scratch. (probably there are no edits in long 
anyway)?
Optimally re-run bases also from scratch, could be you don’t need any edits 
because 6.0 is awesome (maybe). 

Best, Martin


> On 25. Jun 2018, at 18:41, KALEY E ELLIS  wrote:
> 
> Hello FreeSurfer experts,
> 
> I previously emailed regarding processing longitudinal data in v6.0 using 
> bases with manual edits that had been completed in v5.3. I went ahead and ran 
> recon-all -all on the base of a subject (originally generated in v5.3) in 
> v6.0, but it looks like the header of the recon-all.log still indicates v5.3. 
> Looking at the /stats output, all files indicate v6.0. Below is the head of 
> the log from running recon-all -all on this subject. Is this what you would 
> expect if you ran recon-all -all on a subject_base in v6.0 that was generated 
> in v5.3? If so, is this okay?
> 
> Recon-all log:
> setenv SUBJECTS_DIR /study1/nccam3/data/mri/freesurfer_v6/subjects
> FREESURFER_HOME /apps/x86_64_sci7/freesurfer-latest
> Actual FREESURFER_HOME /apps/freesurfer-5.3.0/x86_64_sci6
> build-stamp.txt: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0
> Linux c139.keck.waisman.wisc.edu  
> 3.10.0-514.6.1.el7.x86_64 #1 SMP Tue Jan 17 11:12:41 CST 2017 x86_64 x86_64 
> x86_64 GNU/Linux
> 
> Thank you!
> Kaley Ellis
> 
> Associate Research Specialist
> Center for Healthy Minds
> Waisman Center for Brain Imaging and Behavior
> University of Wisconsin-Madison
> ___
> 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] Longitudinal processing: cannot find input volume error

[Martin Reuter]

Hi Arsenije, 

I have never seen this. You could try:

- convert the norm.mgz to norm.nii.gz and back (keep a backup of the old one) 
and see if that changes anything
- you can also re-run this case from scratch to see if maybe anything else is 
wrong . Could have been an IO issue. 

Best, Martin


> On 16. Jun 2018, at 19:21, Arsenije Subotic  
> wrote:
> 
>
> 
> Dear Freesurfer experts,
> 
> I’m having problems with one of my participants when I am trying to create 
> the base template for my longitudinal analysis. I get an error saying that 
> the input volume (norm.mgz) for my followup time-point cannot be opened, even 
> though the volume is not missing and loads perfectly fine in Freeview. Is 
> this a bug or is something wrong with my norm.mgz volume by any chance? 
> Please let me know.
> 
> Thank you,
> Arsenije
> 
> ___
> 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] Longitudinal analysis of multiple scanner acquisitions

[Martin Reuter]

Hi Kody, 

scanner effects across vendor could be larger than disease effects. You can 
attempt an analysis but you will have a tough time to publish it given these 
differences and no real way to control for scanner effects. Maybe scan 5-10 
people on all these scanners and show that scanner effects remain small for the 
regions of interest (of course this would not help i there is an interaction, 
e.g. with diesease or age) but at least it could help convince reviewers. Also 
if you only analyse the first 2 time points  and find large differences, you 
could argue that they are real, because the same scanner should not course 
large effects. But who knows (different head coils? Different callibrations, 
software versions?…). Better to test with a few subjects. 

Best, Martin



> On 7. Jun 2018, at 20:15, zalewk  wrote:
> 
> Good afternoon Freesurfer team,
> 
> I want to run the longitudinal pipeline on multiple groups of subjects, the 
> problem is we are at the mercy of the scanners available to us at the various 
> time-points. We have two different Siemens 1.5 scanners (same type of 
> scanner, there was an effort made to match them) at time point 1 and 2 with a 
> Phillips 3T at time point 3. Is it worth the time to attempt a longitudinal 
> analysis on this cohort?  
> 
> Best, 
> Kody Zalewski
> 
> ___
> 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] Longitudinal errors, Voxel size differs

[Erik O'Hanlon]

External Email - Use Caution

Thank you so much Martin.


This is super and very much appreciated. I'll try this and resample all my data 
and then hopefully it will run successfully through the longitudinal pipeline 
over my three time points.


Best regards and again thank you for your reply.


Cheers


Erik


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Martin Reuter 

Sent: 04 July 2018 16:32:41
To: Freesurfer support list
Subject: Re: [Freesurfer] Longitudinal errors, Voxel size differs

Hi Erik,

better late then never:
you should use mri_convert --conform input output



Best, Martin



Erik O'Hanlon
Postdoctoral researcher

[cid:rcsi-crest-signature_f581c185-1d03-45c8-a786-23d8ece3d391.png]

RCSI Psychiatry
Royal College of Surgeons in Ireland
Beaumont Road, Beaumont D9 Ireland
T: 8093740
E: erikohan...@rcsi.ie W: www.rcsi.com


Transforming Healthcare Education, Research and Service: RCSI Strategic Plan 
2018-2022


[cid:both3_b9da8717-e91f-4ea7-8729-dc2c4d0a7a5f.png]


On 16. May 2018, at 12:19, Erik O'Hanlon 
mailto:erikohan...@rcsi.ie>> wrote:

External Email - Use Caution

Thank Martin,

I've been looking into this and it appears that the slight changes in the 
sequence may have occurred software updates to the scanner. So essentially from 
what you say, this drastically impacts any longitudinal analyses as there will 
be a systematic bias across the data. Is there any point in trying to do 
longitudinal analyses with such data as it will be a factor in all output? Is 
it worth resampling all three time points to 1mm and then rerun the analysis as 
it will be difficult to say if any patterns of change arent due to the 
acquistions as you said?

If I want to resample the data to a "standard 1mm3" voxel size, is there a FS 
command for that or should I use something in FSL or AFNI tools and then feed 
the resampled data back to the recon-all inistial step in FS.

Thanks for the help and guidance. Much appreciated

Erik



From: 
freesurfer-boun...@nmr.mgh.harvard.edu
 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 on behalf of Martin Reuter 
mailto:mreu...@nmr.mgh.harvard.edu>>
Sent: 15 May 2018 23:39
To: Freesurfer support list
Subject: Re: [Freesurfer] Longitudinal errors, Voxel size differs

Hi Erik,

you should investigate why this is the case. Any difference in acquisition will 
cause effects and it will be impossible to distinguish these from real effects.

Also you should never just resample one time point, as that will introduce 
processing bias. I would advise to
- find out why, and you need to report this in any analysis so that people are 
aware of this potential bias
- resample both time points to some 3rd space. Probably here simply conform 
them to 1mm isotropic.

Best, Martin


Erik O'Hanlon
Postdoctoral researcher

RCSI Psychiatry
Royal College of Surgeons in Ireland
Beaumont Road, Beaumont D9 Ireland
T: 8093740
E: erikohan...@rcsi.ie W: 
www.rcsi.com

Transforming Healthcare Education, Research and Service: RCSI Strategic Plan 
2018-2022

RCSI DEVELOPING HEALTHCARE LEADERS
WHO MAKE A DIFFERENCE WORLDWIDE




On 15. May 2018, at 07:20, Erik O'Hanlon 
mailto:erikohan...@rcsi.ie>> wrote:


Hi FS Experts,

I'm trying to run a longitudinal analysis across three timepoints and have run 
the cross steps for the data. I then ran the base step but found that my voxel 
dimensions are slightly different across the timepoints and I got the following 
error


ERROR: MultiRegistration::loadMovables: images have different voxel sizes.
  Currently not supported, maybe first make conform?
  Debug info: size(2) = 0.881117, 0.881117, 0.881117   size(0) = 0.884507, 
0.884507, 0.884507
MultiRegistration::loadMovables: voxel size is different 
/projects/pi-vokeane/HPC_16_00925/MC_FS_testdata_EOH/freesurfer/subjects/abd025_tp3/mri/norm.mgz.


I assume I need to resample the data to the voxel size of the first time point 
and then rerun. Can you advise on what command to use to resample the images 
from time 2 and time 3 to those of time 1 before rerunning from scratch. I 
assume I can't avoid rerunning the initial reconall step once I resample my 
data.

Any guidance is much appreciated

Best regards

Erik

Erik O'Hanlon
Postdoctoral researcher

RCSI Psychiatry
Royal College of Surgeons in Ireland
Beaumont Road, Beaumont D9 Ireland
T: 8093740
E: erikohan...@rcsi.ie W: 
www.rcsi.com

Transforming Healthcare Education, Research and Service: RCSI Strategic Plan 
2018-2022

RCSI DEVELOPING HEALTHCARE LEADERS
WHO MAKE A DIFFERENCE WORLDWIDE




___
Freesurfer mailing list

Re: [Freesurfer] Longitudinal Process

[Martin Reuter]

Hi Samir, 

you can first conform all inputs to 1mm isotropic using mri_convert --conform 
input output

It may make sense to add a covariate in the statistics for the different 
acquisition to control for a linear effect. 

Best, Martin


> On 25. May 2018, at 08:29, Samir Rekic  wrote:
> 
> 
> 
> 
> Dear FreeSurfers,
> I am trying to run the longitudinal process including (recon-all -base and 
> -long) for 5 different timepoints.
> But in my original data one the of five differs in the acquisition 
> orientation and in the size of the field of view, so the results and 
> especially the statistic is distorted.
> Four of my data sets have RPI as acquisition Parameter and a FOV of 230,
> the last data set has LPI and a FOV of 257.
> Does it even make sense to include this last dataset – is it even possible 
> (due to different Parameters)?
> Do I have to pre-process this different data set?
>  
> Thank you in advance!
> Sam
> ___
> 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] Longitudinal errors, Voxel size differs

[Martin Reuter]

Hi Erik, 

better late then never: 
you should use mri_convert --conform input output



Best, Martin 


> On 16. May 2018, at 12:19, Erik O'Hanlon  wrote:
> 
> External Email - Use Caution
> Thank Martin,
> 
> I've been looking into this and it appears that the slight changes in the 
> sequence may have occurred software updates to the scanner. So essentially 
> from what you say, this drastically impacts any longitudinal analyses as 
> there will be a systematic bias across the data. Is there any point in trying 
> to do longitudinal analyses with such data as it will be a factor in all 
> output? Is it worth resampling all three time points to 1mm and then rerun 
> the analysis as it will be difficult to say if any patterns of change arent 
> due to the acquistions as you said?
> 
> If I want to resample the data to a "standard 1mm3" voxel size, is there a FS 
> command for that or should I use something in FSL or AFNI tools and then feed 
> the resampled data back to the recon-all inistial step in FS.
> 
> Thanks for the help and guidance. Much appreciated
> 
> Erik  
> 
> 
> From: freesurfer-boun...@nmr.mgh.harvard.edu 
>  
>  > on behalf of Martin Reuter 
> mailto:mreu...@nmr.mgh.harvard.edu>>
> Sent: 15 May 2018 23:39
> To: Freesurfer support list
> Subject: Re: [Freesurfer] Longitudinal errors, Voxel size differs
>  
> Hi Erik, 
> 
> you should investigate why this is the case. Any difference in acquisition 
> will cause effects and it will be impossible to distinguish these from real 
> effects. 
> 
> Also you should never just resample one time point, as that will introduce 
> processing bias. I would advise to
> - find out why, and you need to report this in any analysis so that people 
> are aware of this potential bias
> - resample both time points to some 3rd space. Probably here simply conform 
> them to 1mm isotropic. 
> 
> Best, Martin
> 
>> 
>> Erik O'Hanlon 
>> Postdoctoral researcher
>> 
>> RCSI Psychiatry 
>> Royal College of Surgeons in Ireland 
>> Beaumont Road, Beaumont D9 Ireland
>> T: 8093740 
>> E: erikohan...@rcsi.ie  W: www.rcsi.com 
>> 
>> 
>> Transforming Healthcare Education, Research and Service: RCSI Strategic Plan 
>> 2018-2022 
>> 
>> RCSI DEVELOPING HEALTHCARE LEADERS
>> WHO MAKE A DIFFERENCE WORLDWIDE
>> 
>> 
>> 
>> 
>> On 15. May 2018, at 07:20, Erik O'Hanlon > > wrote:
>> 
>> Hi FS Experts,
>> 
>> I'm trying to run a longitudinal analysis across three timepoints and have 
>> run the cross steps for the data. I then ran the base step but found that my 
>> voxel dimensions are slightly different across the timepoints and I got the 
>> following error
>> 
>> ERROR: MultiRegistration::loadMovables: images have different voxel sizes.
>>   Currently not supported, maybe first make conform?
>>   Debug info: size(2) = 0.881117, 0.881117, 0.881117   size(0) = 0.884507, 
>> 0.884507, 0.884507
>> MultiRegistration::loadMovables: voxel size is different 
>> /projects/pi-vokeane/HPC_16_00925/MC_FS_testdata_EOH/freesurfer/subjects/abd025_tp3/mri/norm.mgz.
>> 
>> 
>> I assume I need to resample the data to the voxel size of the first time 
>> point and then rerun. Can you advise on what command to use to resample the 
>> images from time 2 and time 3 to those of time 1 before rerunning from 
>> scratch. I assume I can't avoid rerunning the initial reconall step once I 
>> resample my data.
>> 
>> Any guidance is much appreciated 
>> 
>> Best regards
>> 
>> Erik
>> 
>> Erik O'Hanlon 
>> Postdoctoral researcher
>> 
>> RCSI Psychiatry 
>> Royal College of Surgeons in Ireland 
>> Beaumont Road, Beaumont D9 Ireland
>> T: 8093740 
>> E: erikohan...@rcsi.ie  W: www.rcsi.com 
>> 
>> 
>> Transforming Healthcare Education, Research and Service: RCSI Strategic Plan 
>> 2018-2022 
>> 
>> RCSI DEVELOPING HEALTHCARE LEADERS
>> WHO MAKE A DIFFERENCE WORLDWIDE
>> 
>> 
>> 
>> 
>> ___
>> 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 
> 
___
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 

Re: [Freesurfer] "WARNING: Image geometries differ across time" upon running base step of longitudinal pipeline

[Martin Reuter]

Hi Tudor, 

5.3 had some difficulties reporting image geometry differences even when they 
were tiny. That was fixed in 6.0. However Bruce’s recommendation (to reslice 
the second time point exactly as the first) should do the trick. Alternatively 
(in order to avoid processing bias) you could also simply conform both inputs 
first 

mri_convert - - conform in out 
(I think)

The other problems that you report are strange and could be caused by partially 
processing things and maybe incorrect ways to call recon-all. 
You would need to completely remove (or move to backup) existing cross runs, 
base runs and long runs. 

Then re-run the cross sectionals first (and make sure the norm.mgz exists). If 
it does not, this has nothing to do with the longitudinal stream but some other 
problem. It also has nothing to do with the geometries. Once you have completed 
cross runs, do the base run. Since both time points were conformed in the 
pre-processing step, there should be no error message due to geometry 
differences and it should work 

Best, Martin



> On 13. Jun 2018, at 16:34, Tudor Popescu  wrote:
> 
> 
> 
> Hi Bruce,
> 
> I am guessing that Martin might be unavailable for now, judging by the date 
> of his last input to the list. 
> 
> However, my intuition is that there is something really trivial that's 
> causing this chain of (circular!) errors...
> 
> For any more ideas of what I could try, I'd remain really indebted!
> 
> Cheers,
> Tudor
> 
> On Mon, 11 Jun 2018 at 16:03, Bruce Fischl  > wrote:
> Hi Tudor
> 
> I think Martin is probably better able to sort this out than I am.
> 
> Bruce
> 
> 
> On Mon, 11 Jun 2018, Tudor Popescu wrote:
> 
> > 
> > External Email - Use Caution
> > 
> > Hi Bruce,
> > I assumed a subject-specific target for the mri_convert, so I used this 
> > command to realign
> > subject1's post to his pre:
> >   mri_convert -rl 01_1.nii.gz 01_2.nii.gz 01_2resampled.nii.gz
> > 
> > (and renamed the resampled file to 01_2). However, then the base step
> >   recon-all -base 01 -tp 01_1 -tp 01_2 -all
> > 
> > still gives the same warning about geometries differing across time; and 
> > also in addition, this
> > error message (which might have been there earlier too but had gone 
> > unnoticed):
> >   mghRead(/media/FS/01_1/mri/norm.mgz, -1): could not open file
> > MultiRegistration::loadMovables: could not open input volume 
> > /media/FS/01_1/mri/norm.mgz.
> > 
> > Inside /media/FS/01_1/mri/ (where /media/FS is my $SUBJECTS_DIR), there is 
> > indeed no norm.mgz, which
> > suggests something in my previous commands:
> >   recon-all -i 01_1.nii.gz -subjid 01_1
> > recon-all -i 01_2.nii.gz -subjid 01_2
> > recon-all -subjid 01_1 -all
> > recon-all -subjid 01_2 -all
> > 
> > ..has gone wrong despite these having produced no errors. Although I 
> > thought the base step already
> > does autorecon1 as part of the longitudinal pipeline, I tried doing it 
> > manually:
> >   recon-all -autorecon1 -subjid 01
> > 
> > however this returns:
> >   ERROR: It appears that this subject ID is an existing base/template 
> > from longitudinal
> >   processing (-base). Please make sure you pass all necessary flags. 
> > For example, if you
> >   are trying to re-run a -base: \' -base  -tp  ... \'
> > 
> > ..and running autorecon1 and 2 for the first timepoint instead,
> >   recon-all -autorecon1  -autorecon2 -subjid 01_1
> > 
> > returns
> >   mri_em_register: could not open input volume nu.mgz
> > 
> > 
> > Not sure what to do at this stage!.. Thanks again for any pointers!
> > 
> > Cheers,
> > Tudor
> > 
> > On Thu, 7 Jun 2018 at 18:16, Tudor Popescu  > > wrote:
> >   Hi Bruce,
> > Thanks for your answer! Before seeing this warning (rather: error, as no 
> > output is produced),
> > I'd not have thought the pre-post images have different geometries, as I'm 
> > pretty sure their
> > acquisition parameters were the same. The pre and post of any one subject, 
> > as well as the
> > different subjects' images, all seem to have identical voxel size (1x1x1) 
> > and image size
> > (176x224x160). Furthemore, the (0,0,0) point seems to always overlap 
> > well-enough on the
> > anterior commissure... 
> > 
> > This all suggests to me the geometry differences are trivial, so the 
> > resampling is worth a
> > try. However, I'm unsure whether, in the call to mri_convert -rl, the 
> > target would have to
> > be subject-specific (e.g. resample each 'post' to the 'pre' baseline), or 
> > if I should use a
> > single target for all the pre images in the study, a bit like the 
> > study-specific template
> > used by VBM?
> > 
> > Cheers,
> > Tudor
> > 
> > 
> > 
> > On 6 June 2018 at 16:37, Bruce Fischl  > > wrote:
> >   Hi Tudor
> >
> >   if you are sure that the differences are trivial you can resample the 
> > images to
> >   all have exactly 

Re: [Freesurfer] recon-all -s 1 exited with ERRORS

[Bruce Fischl]

Hi Bernardo

can you send us the recon-all.log file?

cheers
Bruce
On Wed, 4 Jul 2018, Bernardo Regal 
wrote:




External Email - Use Caution

[3f59805705f4d8ccafe6527c8dff34e531a203d9.png?u=2457469]
Hi, 

Now appears this message:

 freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0 
Setting up environment for FreeSurfer/FS-FAST (and FSL)
FREESURFER_HOME   /opt/freesurfer-v5
FSFAST_HOME       /opt/freesurfer-v5/fsfast
FSF_OUTPUT_FORMAT nii.gz
SUBJECTS_DIR      /opt/freesurfer-v5/subjects
MNI_DIR           /opt/freesurfer-v5/mni
bash: /usr/share/virtualenvwrapper/virtualenvwrapper.sh: No such file or 
directory
11:50:16 regal@genedys2: ~ $ export 
SUBJECTS_DIR=/home/regal/Data/Subjects/test_old_version
11:50:20 regal@genedys2: ~ $ recon-all -s mysubject2 -i
/home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii -all
Subject Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0
Current Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0
INFO: SUBJECTS_DIR is /home/regal/Data/Subjects/test_old_version
Actual FREESURFER_HOME /opt/freesurfer-v5
Linux genedys2 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64 
GNU/Linux
/home/regal/Data/Subjects/test_old_version/mysubject2

 mri_convert /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz 

mri_convert /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz 
$Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
reading from /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii...
TR=2530.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (-1, 0, 0)
j_ras = (0, 0, -1)
k_ras = (0, 1, 0)
writing to 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz...
#
#@# MotionCor Wed Jul  4 11:50:37 CEST 2018
Found 1 runs
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz
Checking for (invalid) multi-frame inputs...
WARNING: only one run found. This is OK, but motion
correction cannot be performed on one run, so I'll
copy the run to rawavg and continue.

 cp /home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz 

/home/regal/Data/Subjects/test_old_version/mysubject2

 mri_convert 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz --conform 

mri_convert /home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz --conform 
$Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
reading from 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz...
TR=2530.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (-1, 0, 0)
j_ras = (0, 0, -1)
k_ras = (0, 1, 0)
Original Data has (1, 1, 1) mm size and (256, 256, 256) voxels.
Data is conformed to 1 mm size and 256 voxels for all directions
writing to /home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz...

 mri_add_xform_to_header -c
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/transforms/talairach.xfm
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz 

INFO: extension is mgz
#
#@# Talairach Wed Jul  4 11:50:44 CEST 2018
/home/regal/Data/Subjects/test_old_version/mysubject2/mri

 mri_nu_correct.mni --n 1 --proto-iters 1000 --distance 50 --no-rescale --i 
orig.mgz --o
orig_nu.mgz 

Linux genedys2 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64 
GNU/Linux

recon-all -s mysubject2 exited with ERRORS at Wed Jul  4 11:50:46 CEST 2018

For more details, see the log file
/home/regal/Data/Subjects/test_old_version/mysubject2/scripts/recon-all.log
To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting

11:50:46 regal@genedys2: ~ $ 



Do you think it is better to upgrade to the latest version?
Does anyone know how to fix this ?

Thank you for your help, 

Best regards, 

Bernardo

Mailtrack
Sender notified by
Mailtrack 07/04/18, 11:55:12 AM

2018-07-03 19:35 GMT+02:00 Douglas N. Greve :
  Your recon-all command line is not correct, try something like

  recon-all -s mysubject -i
  /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii -all



  On 07/03/2018 01:29 PM, Bernardo Regal wrote:
  >
  > External Email - Use Caution
  >
  > Hello FreeSurfer Developers,
  >
  > I have a problem to convert the files using the recon-all.
  > It appears, recon-all -s 1 exited with ERRORS.
  >
  > Before I had the last version (stable v6.0.0). As I did not find a
  > solution of how to fix this problem, so I decided to make a 

Re: [Freesurfer] Geometries-related error from base step & absent norm.mgz

[Tudor Popescu]

External Email - Use Caution

Quick follow-up note in case it will be helpful to anyone experiencing the
same problem: I got hold of a Linux machine and installed FreeSurfer 6.0 on
it; running these same commands there successfuly produced the norm.mgz
file.
Therefore, this appears to be a bug in FS v5.3.0 (which is sadly the only
version available to run on Windows, using a Linux Virtual Machine).
Cheers,
Tudor

On Wed, 27 Jun 2018 at 18:00, Tudor Popescu  wrote:

> Hi again,
>
> At a loss for more things to try here, I tried the following: for the
> first subject in my sample, I replaced the 'post' scan (01_2.nii.gz) with a
> copy of the pre (01_1.nii.gz ), to rule out the unlikely cause that an
> actual geometries problem is at the root here, as reported in the
> warning/error I mentioned earlier.
>
> While this removed the geometries message from the output of the base
> command, the error about norm.mgz not being there remained. Further
> searches of the FS mailing list revealed that this file's absence might be
> due to a bug in FS v6 (even though I am running 5.3.0, through
> VirtualBox, on Windows). Nevertheless, I followed the instructions
> for
> applying the bugfix patch, but when I redid everything (deleted subject
> folders, reissued the commands), the result was the same.
>
> It thus seems the base step expects norm.mgz to exist, whereas the
> previous steps ('-i' and 'cross') do not create it.
>
> I attach the recon-all logs for the pre, post and base of subject 01.
> Would remain thankful to anyone who can suggest what else I can try!
>
> Best wishes,
> Tudor
>
> On Thu, 21 Jun 2018 at 10:16, Tudor Popescu  wrote:
>
>> Dear FS list,
>>
>> ( Apologies for asking my question again which I am still struggling to
>> resolve and which I tried to clarify and condense below. )
>>
>> I have pre and post-intervention data for a single group of subjects, and
>> I'd like to extract the cortical thickness at both timepoints, for all
>> standard regions in the atlas. I followed the standard approach
>> for
>> longitudinal studies, however the third ('base') step immediately gives
>> this error:
>>
>> *"WARNING: Image geometries differ across time, maybe due to aquisition
>> changes? This can potentially bias a longitudinal study! "*
>>
>>
>> I don't think the acquisition parameters of the pre-post images actually 
>> differ:
>> I could verify that all images indeed have
>>   - identical voxel size (1x1x1)
>>   - identical image size (176x224x160)
>>   - a (0,0,0) point that overlaps well-enough on the anterior commissure
>>
>> This suggests trivial (if any) "geometry" differences, and at Bruce's
>> suggestion, I used  mri_convert to resample each subject's 'post' to
>> their 'pre' baseline:
>>
>> mri_convert -rl 01_1.nii.gz 01_2.nii.gz 01_2resampled.nii.gz
>>
>> (and renamed the resampled file to 01_2). However, the base step,
>>
>> recon-all -base 01 -tp 01_1 -tp 01_2 -all
>>
>> still gives the same error about geometries, and also in addition, this
>> one:
>>
>> mghRead(/media/FS/01_1/mri/norm.mgz, -1): could not open file
>> MultiRegistration::loadMovables: could not open input volume
>> /media/FS/01_1/mri/norm.mgz.
>>
>> Inside /media/FS/01_1/mri/ (where /media/FS is my $SUBJECTS_DIR), there
>> is indeed no norm.mgz, which suggests something in my previous commands for
>> subject1:
>>
>> recon-all -i 01_1.nii.gz -subjid 01_1
>> recon-all -i 01_2.nii.gz -subjid 01_2
>> recon-all -subjid 01_1 -all
>> recon-all -subjid 01_2 -all
>>
>> ..had gone wrong despite these having produced no errors. Although I
>> thought the base step already does autorecon1 as part of the longitudinal
>> pipeline, I tried doing it manually:
>>
>> recon-all -autorecon1 -subjid 01
>>
>> however this returns:
>>
>> ERROR: It appears that this subject ID is an existing base/template from
>> longitudinal processing (-base). Please make sure you pass all necessary
>> flags. For example, if you are trying to re-run a -base: \' -base
>>  -tp  ... \'
>>
>> ..whereas running autorecon1 and 2 for the first *timepoint *instead,
>>
>> recon-all -autorecon1  -autorecon2 -subjid 01_1
>>
>> returns
>>
>> mri_em_register: could not open input volume nu.mgz
>>
>>
>> Should I in fact use, in  mri_convert -rl , a *single *target for all
>> the pre images in the study, like the study-specific template
>> 
>>  used
>> by VBM? Or what else can I try to get the base step to continue? I'm
>> very grateful for any suggestions!
>>
>> Cheers,
>> Tudor
>>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information 

Re: [Freesurfer] recon-all -s 1 exited with ERRORS

[Mr. Tass]

External Email - Use Caution

make sure u have 8gb if ram at least

Get Outlook for Android


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Bernardo Regal 

Sent: Wednesday, July 4, 2018 12:56:14 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] recon-all -s 1 exited with ERRORS


External Email - Use Caution


Hi,

Now appears this message:

 freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0 
Setting up environment for FreeSurfer/FS-FAST (and FSL)
FREESURFER_HOME   /opt/freesurfer-v5
FSFAST_HOME   /opt/freesurfer-v5/fsfast
FSF_OUTPUT_FORMAT nii.gz
SUBJECTS_DIR  /opt/freesurfer-v5/subjects
MNI_DIR   /opt/freesurfer-v5/mni
bash: /usr/share/virtualenvwrapper/virtualenvwrapper.sh: No such file or 
directory
11:50:16 regal@genedys2: ~ $ export 
SUBJECTS_DIR=/home/regal/Data/Subjects/test_old_version
11:50:20 regal@genedys2: ~ $ recon-all -s mysubject2 -i 
/home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii -all
Subject Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0
Current Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0
INFO: SUBJECTS_DIR is /home/regal/Data/Subjects/test_old_version
Actual FREESURFER_HOME /opt/freesurfer-v5
Linux genedys2 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64 
GNU/Linux
/home/regal/Data/Subjects/test_old_version/mysubject2

 mri_convert /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz

mri_convert /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz
$Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
reading from /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii...
TR=2530.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (-1, 0, 0)
j_ras = (0, 0, -1)
k_ras = (0, 1, 0)
writing to 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz...
#
#@# MotionCor Wed Jul  4 11:50:37 CEST 2018
Found 1 runs
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz
Checking for (invalid) multi-frame inputs...
WARNING: only one run found. This is OK, but motion
correction cannot be performed on one run, so I'll
copy the run to rawavg and continue.

 cp /home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz

/home/regal/Data/Subjects/test_old_version/mysubject2

 mri_convert 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz --conform

mri_convert 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz --conform
$Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
reading from 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz...
TR=2530.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (-1, 0, 0)
j_ras = (0, 0, -1)
k_ras = (0, 1, 0)
Original Data has (1, 1, 1) mm size and (256, 256, 256) voxels.
Data is conformed to 1 mm size and 256 voxels for all directions
writing to /home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz...

 mri_add_xform_to_header -c 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/transforms/talairach.xfm
 /home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz 
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz

INFO: extension is mgz
#
#@# Talairach Wed Jul  4 11:50:44 CEST 2018
/home/regal/Data/Subjects/test_old_version/mysubject2/mri

 mri_nu_correct.mni --n 1 --proto-iters 1000 --distance 50 --no-rescale --i 
orig.mgz --o orig_nu.mgz

Linux genedys2 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64 
GNU/Linux

recon-all -s mysubject2 exited with ERRORS at Wed Jul  4 11:50:46 CEST 2018

For more details, see the log file 
/home/regal/Data/Subjects/test_old_version/mysubject2/scripts/recon-all.log
To report a problem, see http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting

11:50:46 regal@genedys2: ~ $



Do you think it is better to upgrade to the latest version?
Does anyone know how to fix this ?

Thank you for your help,

Best regards,

Bernardo

[Mailtrack] 

   Sender notified by
Mailtrack
 07/04/18, 11:55:12 AM

2018-07-03 19:35 GMT+02:00 Douglas N. Greve 
mailto:dgr...@mgh.harvard.edu>>:
Your recon-all command line is not correct, try something like

recon-all -s mysubject -i
/home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii -all



On 07/03/2018 01:29 PM, Bernardo Regal wrote:

Re: [Freesurfer] recon-all -s 1 exited with ERRORS

[Bernardo Regal]

External Email - Use Caution

Hi,

Now appears this message:

 freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0 
Setting up environment for FreeSurfer/FS-FAST (and FSL)
FREESURFER_HOME   /opt/freesurfer-v5
FSFAST_HOME   /opt/freesurfer-v5/fsfast
FSF_OUTPUT_FORMAT nii.gz
SUBJECTS_DIR  /opt/freesurfer-v5/subjects
MNI_DIR   /opt/freesurfer-v5/mni
bash: /usr/share/virtualenvwrapper/virtualenvwrapper.sh: No such file or
directory
11:50:16 regal@genedys2: ~ $ export
SUBJECTS_DIR=/home/regal/Data/Subjects/test_old_version
11:50:20 regal@genedys2: ~ $ recon-all -s mysubject2 -i
/home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii -all
Subject Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0
Current Stamp: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0
INFO: SUBJECTS_DIR is /home/regal/Data/Subjects/test_old_version
Actual FREESURFER_HOME /opt/freesurfer-v5
Linux genedys2 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64
GNU/Linux
/home/regal/Data/Subjects/test_old_version/mysubject2

 mri_convert /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz

mri_convert /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz
$Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
reading from
/home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii...
TR=2530.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (-1, 0, 0)
j_ras = (0, 0, -1)
k_ras = (0, 1, 0)
writing to
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz...
#
#@# MotionCor Wed Jul  4 11:50:37 CEST 2018
Found 1 runs
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz
Checking for (invalid) multi-frame inputs...
WARNING: only one run found. This is OK, but motion
correction cannot be performed on one run, so I'll
copy the run to rawavg and continue.

 cp /home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig/001.mgz
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz

/home/regal/Data/Subjects/test_old_version/mysubject2

 mri_convert
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz
--conform

mri_convert
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz
--conform
$Id: mri_convert.c,v 1.179.2.7 2012/09/05 21:55:16 mreuter Exp $
reading from
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/rawavg.mgz...
TR=2530.00, TE=0.00, TI=0.00, flip angle=0.00
i_ras = (-1, 0, 0)
j_ras = (0, 0, -1)
k_ras = (0, 1, 0)
Original Data has (1, 1, 1) mm size and (256, 256, 256) voxels.
Data is conformed to 1 mm size and 256 voxels for all directions
writing to
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz...

 mri_add_xform_to_header -c
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/transforms/talairach.xfm
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz
/home/regal/Data/Subjects/test_old_version/mysubject2/mri/orig.mgz

INFO: extension is mgz
#
#@# Talairach Wed Jul  4 11:50:44 CEST 2018
/home/regal/Data/Subjects/test_old_version/mysubject2/mri

 mri_nu_correct.mni --n 1 --proto-iters 1000 --distance 50 --no-rescale --i
orig.mgz --o orig_nu.mgz

Linux genedys2 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64
GNU/Linux

recon-all -s mysubject2 exited with ERRORS at Wed Jul  4 11:50:46 CEST 2018

For more details, see the log file
/home/regal/Data/Subjects/test_old_version/mysubject2/scripts/recon-all.log
To report a problem, see
http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting

11:50:46 regal@genedys2: ~ $



Do you think it is better to upgrade to the latest version?
Does anyone know how to fix this ?

Thank you for your help,

Best regards,

Bernardo

[image: Mailtrack]

Sender
notified by
Mailtrack

07/04/18,
11:55:12 AM

2018-07-03 19:35 GMT+02:00 Douglas N. Greve :

> Your recon-all command line is not correct, try something like
>
> recon-all -s mysubject -i
> /home/regal/Data/Subjects/test_old_version/01C_dislebi_T1.nii -all
>
>
>
> On 07/03/2018 01:29 PM, Bernardo Regal wrote:
> >
> > External Email - Use Caution
> >
> > Hello FreeSurfer Developers,
> >
> > I have a problem to convert the files using the recon-all.
> > It appears, recon-all -s 1 exited with ERRORS.
> >
> > Before I had the last version (stable v6.0.0). As I did not find a
> > solution of how to fix this problem, so I decided to make a downgrade
> > to the previous version (5.3.0 stable).  I thought