1. Yes, I would expect that

2. Because the pial surface is bigger. (Unless I'm misunderstanding the 
question?)


________________________________
From: freesurfer-boun...@nmr.mgh.harvard.edu 
<freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Gerrits, Niels 
<n.gerr...@vumc.nl>
Sent: Thursday, August 27, 2015 10:36 AM
To: Freesurfer support list
Subject: Re: [Freesurfer] Computing SA from an older FS version


Dear Experts,

With your help, I recalculated the surface area, now using the pial surface 
instead of the wm/gm boundary. I am, however, somewhat surprised by the 
discrepancy between my previous and current results, because the cortical 
surface area that is calculated using the pial is surface is consistently (a 
lot) larger than the SA that was calculated using the WM/GM boundary (please 
see below for an example). While computing the new SA measure, FS also 
automatically calculated both volume and thickness. Since these two measures 
are exactly the same as previously when SA was calculated using the wm/gm 
boundary (as was to be expected), I assume that the calculation of SA using the 
pial surface was correctly executed.

Nonetheless, I am wondering: 1) is such a large difference to be expected, and 
2) what could be a physiological explanation for this discrepancy?

All suggestions are much appreciated!

Best wishes,
Niels Gerrits




LH_cuneus_area

LH_entorhinal_area

LH_fusiform_area

LH_inferiorparietal_area

PP_01

1305

349

2563

3699

PP_02

1351

368

2989

4803

PP_03

1324

490

3489

3963

PP_04

1714

518

4107

4473

PP_05

1573

566

3750

5697

PP_06

1419

387

3206

4543

PP_07

1249

364

2636

4518

PP_08

1386

362

3174

5105

PP_09

1322

562

3239

6264

PP_10

1696

517

3926

5989













LH_cuneus_area

LH_entorhinal_area

LH_fusiform_area

LH_inferiorparietal_area

PP_01

1617

575

3231

4446

PP_02

1555

661

3970

5983

PP_03

1769

886

5059

5143

PP_04

1964

809

5402

5662

PP_05

1788

946

4832

6907

PP_06

1752

667

3944

5449

PP_07

1595

674

3631

5783

PP_08

1779

634

4074

6364

PP_09

1648

912

4353

7395

PP_10

1915

816

4758

7358






-----Original Message-----
From: freesurfer-boun...@nmr.mgh.harvard.edu 
[mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl
Sent: maandag 13 juli 2015 14:46
To: Freesurfer support list
Subject: Re: [Freesurfer] Computing SA from an older FS version



Hi Niels



the matlab commands should be:



>> [v, M,mr] = load_mgh('wm.mgz') ;

>> save_mgh(v, 'wm.mgz', M,mr);



cheers

Bruce

On Mon, 13 Jul 2015, Gerrits, Niels

wrote:



>

> Dear Bruce,

>

>

>

> Thanks for the quick reply! I think it might be possible that we used an

> unrelased or developmental version of FreeSurfer, because the building-stamp

> said: freesurfer-Linux-centos5_86_64_dev-20110315. I’m not sure how this

> version ended up onto the server I was working on. Do you think this is a

> problem?

>

>

>

> With respect to the error: you were right, it was longer. I copied the

> command line below:

>

>

>

> $ mris_anatomical_stats -mgz -cortex label/lh.cortex.label -f

> stats/lh.aparc.pial.stats -b -a label/lh.aparc.annot -c

> label/aparc.annot.ctab 0007 lh pial

> INFO: assuming MGZ format for volumes.

> INFO: using label/lh.cortex.label as mask to calc cortex NumVert, SurfArea

> and MeanThickness. computing statistics for each annotation in

> label/lh.aparc.annot. reading

> volume/data2/projects/ysbrand-vumc/pddatabase-freesurfer/niels_test//0007/mri/wm.

> mgz... znzTAGskip: tag=825050957, failed to calloc 1969843200 bytes!

>

>

>

> I then loaded wm.mgh into matlab and then saved it as you suggested and ran

> the command again to calculate SA of the pial surface, but it produces the

> exact same error…

>

>

>

> >> load.mgh wm.mgz;

>

> >> save.mgh wm.mgz;

>

>

>

> Am I doing anything wrong?

>

>

>

> Thanks again!

>

>

>

> Cheers,

>

> Niels

>

>

>

> -----Original Message-----

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

> [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] On Behalf Of Bruce Fischl

> Sent: zondag 12 juli 2015 16:44

> To: Freesurfer support list

> Subject: Re: [Freesurfer] Computing SA from an older FS version

>

>

>

> Hi Niels

>

>

>

> is that the entire error? Does it not say what volume produces the error?

>

> That was a bug we had briefly some time ago, but I didn't think it made it

>

> into anything we released.  If you can track down which volume is causing

>

> this problem you can just load it into matlab with load_mgh.m then save it

>

> with save_mgh.m and the error will go away (since the matlab code doesn't

>

> try to read or write the tagged information). Make sure to save all the

>

> volumes that you do this to somewhere before overwriting them.

>

>

>

> cheers

>

> Bruce

>

>

>

> On

>

> Sun, 12 Jul 2015, Gerrits, Niels wrote:

>

>

>

> > Dear FreeSurfer-experts,

>

> >

>

> > Unfortunately, nobody replied to my question so this is a repost (see the

>

> > original question below). Could anybody please give some advise on how to

>

> > proceed? The deadline for the revisions is drawing near, so any help is

>

> > greatly appreciated!

>

> >

>

> > Best wishes,

>

> > Niels

>

> >

>

> >---------------------------------------------------------------------------

>

> > ---------------------------------------------

>

> >

>

> > Dear FreeSurfer-experts,

>

> >

>

> > In 2012 I used a (currently outdated) version of FreeSurfer to analyze my

>

> > data on an external server and wrote an article about our findings. Now

> the

>

> > reviewers asked us to recalculate surface area using the pial surface,

>

> > instead of the WM/GM boundary. I found the command on the mailing list to

> do

>

> > so, but I got an error, which is probably related to the fact that there

> is

>

> > a new version of FreeSurfer installed on the server and that the old

> version

>

> > has been deleted.

>

> >

>

> > Command to obtain SA from the pial surface:

>

> >

>

> > mris_anatomical_stats -mgz -cortex label/lh.cortex.label -f

>

> > stats/lh.aparc.pial.stats -b –a label/lh.aparc.annot -c

>

> > label/aparc.annot.ctab subject lh pial

>

> >

>

> > Error:

>

> >

>

> > znzTAGskip: tag=825050957, failed to alloc 1969843200 bytes!

>

> >

>

> > Cannot allocate memory!

>

> >

>

> > Now I have two questions:

>

> >

>

> > 1) When trying to find in which version of FreeSurfer the existing files

>

> > were created, I checked both the build-stamp.txt file and the

> recon-all.log

>

> > file, and both say that the version of Freesurfer that was used was

>

> > freesurfer-Linux-centos5_86_64_dev-20110315. Is this an actual version? I

>

> > cannot find anything on the Internet about it. If not, what version could

>

> > this have been?

>

> >

>

> > 2) I understood that running two different versions of FreeSurfer on the

>

> > same data is not favourable. However, the numbers we are looking for are

>

> > already computed and now we only need to get them out of the existing

> files.

>

> > Do you have any advice on how to do that?

>

> >

>

> > Running recon-all again using the new version (5.3) does not seem to be an

>

> > option, since manual edits were made during the preprocessing. It is

>

> > therefore likely that we will obtain different results when compared with

>

> > our current findings when running recon-all again using the new version,

> and

>

> > we would have to rewrite our entire article.

>

> >

>

> > Any help is greatly appreciated!

>

> >

>

> > Best wishes,

>

> > Niels Gerrits

>

> >

>

> >

>

> >

>

> >

>

> >

>

> >

>

> >

>

>

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

Reply via email to