Freesurfer March 2017

freesurfer@nmr.mgh.harvard.edu

148 participants
263 discussions

Re: [Freesurfer] Faulty alignment to standard surface
by Daan Wesselink 14 Mar '17

14 Mar '17

Dear Douglas, Thank you for your response. The surface placement on the individual seems correct (see https://ibb.co/f4aeAa ). However, if I load the annotation files, the labels are wrong. In this screenshot (https://ibb.co/cycFiv ), I've loaded the BA annotation outlines and BA3a in yellow on the left hemisphere. It seems to think the wrong fold is the central sulcus. Thanks, Daan Message: 7 > Date: Sun, 12 Mar 2017 19:00:21 -0400 > From: Douglas Greve <greve(a)nmr.mgh.harvard.edu> > Subject: Re: [Freesurfer] Faulty alignment to standard surface > To: freesurfer(a)nmr.mgh.harvard.edu > Message-ID: <7ab364ef-539f-fd65-4346-db68d915ca05(a)nmr.mgh.harvard.edu> > Content-Type: text/plain; charset="windows-1252" > > not sure what you mean. Can you send a pic? Is the surface placement on > the individual correct (ie, are the white and pial surfaces properly > placed on the T1)? > > > > On 3/10/17 11:19 AM, Daan Wesselink wrote: > > Dear experts, > > > > I've run the standard recon-all pipeline on a subject, for whom the > > log does not report any errors and the white and pial surface follow > > the structural nicely. However, the coregistration to the standard > > surface has gone wrong: it seems like the central sulcus (e.g. labels > > BA1, BA3a) is placed on top of the postcentral sulcus. > > > > Does someone know how to fix this problem and/or better identify the > > step where it went wrong? > > > > Many thanks, > > > > Daan Wesselink > > > > > > _______________________________________________ > > Freesurfer mailing list > > Freesurfer(a)nmr.mgh.harvard.edu > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > >

2 1

Ventricles not filled
by Manuel Delgado 14 Mar '17

14 Mar '17

Dear Freesurfer list, Does anybody know how to deal with the parts of the ventricles that have not been filled in yellow when editing the white matter mask? (see enclosed image) Is it necessary to fill them as other parts of the wm that have not been included, such as vascular lesions? If I fill them using this, will that parts be considered white matter instead of ventricles? Or this is not relevant? Kind regards, Manuel

2 1

Brain to skull distance
by yusif Al-kheder 14 Mar '17

14 Mar '17

Hello, Is it possible to use freesurfer to determine the distance between the skull and brain? Youssif

2 1

Re: [Freesurfer] Can we use fressurfer 6 with the Human connectome project's pipeline ?
by Matt Glasser 13 Mar '17

13 Mar '17

Not yet. We are hoping FreeSurfer 6.1 will work nicely with the HCP Pipelines. For now version 6.0 has some regressions as far as surface placement goes and there are also some adaptations we need to make to the pipelines. Peace, Matt. From: <freesurfer-bounces(a)nmr.mgh.harvard.edu> on behalf of CAGNA Bastien <bastien.CAGNA(a)univ-amu.fr> Reply-To: Freesurfer support list <freesurfer(a)nmr.mgh.harvard.edu> Date: Monday, March 13, 2017 at 7:21 AM To: "freesurfer(a)nmr.mgh.harvard.edu" <freesurfer(a)nmr.mgh.harvard.edu> Subject: [Freesurfer] Can we use fressurfer 6 with the Human connectome project's pipeline ? Dear freesurfer experts, I'm wondering if it's possible to run the human connetome project's minimal processing pipeline using freesurfer 6 ? Does it require some update of the pipeline or is there anybody that have already enjoyed the new freesurfer version with this pipeline ? Thank you for your attention and your help, Bastien Cagna _______________________________________________ Freesurfer mailing list Freesurfer(a)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.

3 3

Re: [Freesurfer] Error viewing corrected results
by Antonin Skoch 13 Mar '17

13 Mar '17

Dear Sahil, -approx tail and -twotail are completely different things: -approx tail switch on the tail approximation which speeds up the permutations. -twotail switch on two-sided hypothesis, without -twotail the hypothesis is only one-sided. It is reassuring that you see some clusters in _tstat_fwep.mgz now. I think that this starts to make sense: Since without -twotail there was no value in clustere_tstat_fwep.mgz, I think that your setup without -twotail was testing the opposite one-sided hypothesis. You have to decide which hypothesis you want to test. If you want to test one-sided hypothesis of negative correlation and use cluster forming threshold 0.05 (~ 1.3 in FreeSurfer -log10(p) convention), then I think you should invert sign of your contrast vector in Contrast.csv. With one-sided hypothesis you can modify your cluster-forming threshold to qnorm(1-10^-1.3)=1.643704 to be consistent with the mri_glmfit-sim behaviour. If you are testing two-sided hypothesis, your command line is I think almost OK, with following recommendations When not using -approx tail, I would increase number of permutations at least to 5000. Or add -approx tail and then you are running with tail approximation. Then you can retain -n 500 as Anderson recommended and your execution time would be much shorter. To report on cluster by use mri_surfcluster, you can use the code snippet I send in some of my earlier mails. You can also get cluster-wise p-value by loading the *clustere_tstat_fwep.mgz into freeview and clicking on the cluster. You can get cluster area by clicking on particular cluster in clustere_tstat.mgz. For visualization purposes Anderson mentioned that it is better to use -log10(p) (use the option -logp). Then you can interactively threshold your clusters according to the cluster-wise p-values (put 1.3 to min to hide clusters not significant at cluster-wise p=0.05). Do not forget to apply Bonferroni correction on your p-values when you analyze both hemispheres. To get *cope.mgz for the comparison, you should add -saveglm. As for comparison of F.mgh and dpv_tstat.mgh: F should be (approximately?) square of _tstat at the same vertex, if your contrast vector has one row. The correspondence should be (almost?) exact in orthogonal design (as I wrote previously, I got exact correspondence in my testing orthogonal design). I am not sure for non-orthogonal but I think that this should approximately also correspond, so -2 in dpv_tstat.mgh and 12 in F.mgh in the same vertex is maybe OK, but I am not sure. Antonin Hi Antonin, Just quick updates and few more points: (A) Earlier, I was using "-approx tail" in my PALM command and I was not getting any thing close to that big cluster but I noticed that you mentioned '-twotail' in your last email. So I replaced "-approx tail" with ''-twotail'' so the command I am running now is: palm -i *.10.mgh -s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh -d Xg.csv -t Contrast.csv -m mask.mgh -o Left_Hemi_results -C 1.95 -twotail -n 500 -nouncorrected and I found that I can see a cluster when I view *_culstere_tstat_fwep or _dpv_tstat_fwep (both positive magnitude), which are very identical to sig.mgh (negative magnitude) from mri_glmfit and big cluster of very high negative PCC which I sent earlier. Here, I am sending you a screen of *_culstere_tstat_fwep, *_dpv_tstat_fwep and sig.mgh. Could you please confirm if thats correct? If so, I have few more questions: - When reporting about this cluster for publication, how can I find the size, annotation etc. of this cluster? - What 'min' and 'max' range of color bar would you recommend when reporting *_culstere_tstat_fwep results for the best view possible (at p < 0.05)? (B). Even though you said the matchings are valid for orthogonal design only, still I just check quickly and found that: 1. Here, I could not find any file with name: *cope.mgh 2. Here, clusters between F.mgh and *dpv_tstat.mgh are very similar but magnitude of dpv_tstat.mgh is very small and negative (~ -2) and of F.mgh is very high and positive (~ +12) 3. Here, magnitude of sig.mgh is roughly same as *dpv_tstat_uncp.mgh: both negative and similar big cluster (I am assuming that *dpv_tstat_uncp.mgh represents uncorrected p here and is same as *dpv_tstat.mgh, somehow I do not see *_uncp.mgh in my outputs). Thanks a lot for Antonin, Sahil On Fri, Mar 10, 2017 at 1:58 AM, Antonin Skoch <ansk(a)ikem.cz> wrote: > Dear Sahil, > > thinking of that, the comparisons I suggested in previous mail are > probably valid only for the case of orthogonal design. And even with the > orthogonal design as Anderson said, the values can a bit differ: > > https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1604&L= > FSL&D=0&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=318728 > > As I did my own tests with orthogonal design, the values were equal to the > reasonable precision, apart from the case 3. > > So you could produce some testing orthogonal design and make similar tests > on that. > > Antonin > > > > Dear Sahil, > > I would suggest at first to make check of your GLM PALM setup by comparing > mri_glmfit and PALM output files (using the same design and contrast): > > 1. values of gamma.mgh should correspond to values of *cope.mgh > > 2. values of F.mgh should be (*dpv_tstat.mgh) ^2. > > 3. values of sig.mgh should be {roughly) values of > -log10(*dpv_tstat_uncp.mgh) - I am currently not sure why I do not get > exact correspondence here. > > 4. When you threshold the sig.mgh by some threshold in freeview (let it be > x) and use the same corresponding cluster-forming z-score threshold -C in > PALM computed as > > qnorm(1-10^-x/2) > > (and use two-sided hypothesis by specifying -twotail), your > *clustere_tstat.mgz should show the clusters with the same shape > (regardless of their values, the clusters will be defined by non-zero > value, other vertices would be zero) as the thresholded display of sig.mgh > (computed by -two sided hypothesis). > > If there is any inconsistence, then there is probably something wrong with > your PALM setup. > > Antonin > > > Dear Antonin, > > Could you please have a look at the attached screen shot. This map is with > full number of permutations, without -approx tail -n 500 -nouncorrected > > Here, I noticed that its only *_dpv_tstat.mgz which looks correct and > giving very high negative value, close to that big cluster, small positive > values at red clusters and the value changes when I change the position of > cursor. > > *_dpv_tstat_fwep shows value of 1 mostly but shows between 0.97 and 1 > close/at the red clusters and 1 elsewhere, even at the big blue negative > cluster. > > Third, *_clustere_tstat_fwep and *_clustere_tstat shows 1 and 0 > respectively everywhere, even at the big blue negative cluster. > > If there is something fishy with the analysis, would you mind looking at > the data and the detailed commands I am using to run the analysis? > > Thanks a lot, > Sahil > > On Wed, Mar 8, 2017 at 11:54 PM, Antonin Skoch <ansk(a)ikem.cz> wrote: > > > Dear Sahil, > > > > to assure that there is no other issue with your setup, I would > recommend to obtain cluster-wise p-pvalue of that big cluster to see if it > is reasonable, i.e. if it is somewhat close to the significance. > > > > Therefore, I would load *_clustere_tstat_fwep and click to the area of > big cluster and see what the values of the vertices in that region are. > > > > Or, I would increase --thmax in mri_surfcluster to see the cluster-wise > p-value(s). If you use --thmax 0.9999 (or maybe 1), you should see > cluster-wise FWER corrected p-values of all clusters formed by used > cluster-forming threshold. > > > > I would also maybe try to switch-off tail approximation and run it in > full number of permutations (i.e. do not use -approx tail -n 500 > -nouncorrected). > > > > If there is no other issue, then yes, the conclusion would be, that for > the used cluster-extent inference and currently set cluster-forming > threshold, none of the clusters survived FWER correction at cluster-wise > p-value threshold of 0.05. > > > > Antonin > > > > > > > > Dear Antonin, > > > > Setting minimum to 1.3 for *_clustere_tstat_fwep doesn't show any > > significant cluster and similarly thresholded map *dpv_tstat.mgz also > > doesn't show anything at -log10(0.05) = 1.3. As you said, it seems like > > even though there is big cluster but after FWER correction, the > > significance goes away. Actually, even when I removed -logp, I still do > not > > see any significant cluster. > > > > Next, I tried to use mri_surfcluster using following three commands > > following instructions from the link you sent: > > > > mri_binarize --i Results_Left_clustere_tstat_fwep.mgz --min 1 --o > p_bin.mgz > > > > mris_calc --output pmap_filter.mgz Results_Left_clustere_tstat_fwep.mgz > sub > > p_bin.mgz > > > > mri_surfcluster --in pmap_filter.mgz --subject fsaverage --hemi lh > --surf > > white --annot aparc.a2009s --thmin 0.00000001 --thmax 0.05 --mask > > glmdir/mask.mgh --sum summary --nofixmni > > > > This gives me 'zero' cluster in the summary file. > > > > If the above steps are correct, would you conclude that the LGI results > are > > not significant and un-reportable for publication purpose and I should > give > > a try to thickness, volume and area maps? > > > > Thanks you so much Antonin for all your help. > > Sahil > > > > > > > > On Wed, Mar 8, 2017 at 3:05 PM, Antonin Skoch <a...(a)ikem.cz> wrote: > > > > > Dear Sahil, > > > > > > If you used -logp as Anderson suggested, you should set your min to > 1.3 to > > > threshold your *_clustere_tstat_fwep map and see the clusters. > > > > > > What is the value of *_clustere_tstat_fwep in the region of the big > > > cluster seen at thresholded map *dpv_tstat.mgz ? This should > correspond to > > > your -log10(p) of your cluster. > > > > > > I personally did not use -logp and use the mri_surfcluster for the > > > reporting of the clusters, as I wrote in previous mail here: > > > > > > freesurfer(a)nmr.mgh.harvard.edu > </msg52042.html"" target="_blank">http://www.mail-archive.com/%3Ca%20href=>/msg52042.html"; title=" > freesurfer(a)nmr.mgh.harvard.edu/msg52042.html"" title="http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52042.html"" target="_blank">http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52042.html"; > target="_blank">freesurfer(a)nmr.mgh.harvard.edu" title="http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu" target="_blank">http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu > /msg52042.html > > > > > > > > But it is only matter of personal preference. > > > > > > And, beware, that the LGI is very smooth measure, therefore also > rather > > > big cluster can be insignificant after FWER correction. > > > > > > Antonin > > > > > > > > > > > > > > > Hi Antonin, > > > > > > Here, I am sending you more information: > > > > > > (1). I used following command: > > > palm -i lh.Behav_LGI.10.mgh -s fsaverage/surf/lh.white > > > fsaverage/surf/lh.white.avg. > > area.mgh -d Xg_Behav.csv -t > > > Contrast_Behav.csv > > > -m lh.Behav_LGI.glmdir/mask.mgh -o Results_Left -Cstat extent -C 1.95 > > > -approx tail -n 500 -nouncorrected -logp > > > > > > (2). Somehow, view of *_clustere_tstat_fwep is single colored, > thresholded > > > 0 (min) and 1(max), which seems suspicious. Please find it attached. > > > > > > (3). Data showed in screen shot 1 is just partial correlation > coefficient > > > (PCC, limiting between 0.30-0.35), obtained after running glm_fit > command > > > and saved in glm directory. > > > > > > (4). *_clustere_tstat_fwep is attached here in this email. > > > > > > (5). If I load *dpv_tstat.mgz and threshold it between 1.3 (p = 0.05) > and > > > 2 > > > (max), I get the map attached 2nd in attached figure. I am not sure > > > how to "threshold > > > it by your cluster-forming threshold (I suppose that you should > correctly > > > convert z value to t-value), to see your initial clusters after > > > thresholding". > > > > > > Thanks a lot Antonin. > > > Sahil > > > > > > > > > > > > On Wed, Mar 8, 2017 at 2:06 PM, Antonin Skoch <a...(a)ikem.cz> wrote: > > > > > > > Dear Sahil, > > > > > > > > could you send the full command-line and unthresholded view of > > > > *_clustere_tstat_fwep ? > > > > > > > > How the data showed in screenshot 1 were produced? > > > > > > > > How are the actual p-values of your clusters in > *_clustere_tstat_fwep? > > > > > > > > You can also use -saveglm and inspect the files containing values of > GLM > > > > fit. > > > > You can load the *dpv_tstat.mgz file and threshold it by your > > > > cluster-forming threshold (I suppose that you should correctly > convert z > > > > value to t-value), to see your initial clusters after thresholding. > > > > > > > > Regards, > > > > > > > > Antonin > > > > > > > > > > > > > > > > Thanks a lot Anderson and Antonin, that's really useful. > > > > > > > > Actually, I am having trouble in interpreting the results. Could you > > > > please > > > > share any document explaining all these tests/outputs and their > > > > interpretation in simple terms? > > > > > > > > Here I am attaching a screen shot: (1) Simple partial correlations > (I > > > > adjusted the color bar between 0.30 and 0.35 to visualize the high > > > > correlation coefficients, which is ~0.35) and (2) Results I get when > I > > > > used cluster > > > > extent stats: *dpv_tstat > > > > But I do not see any significant clusters when I view > > > > *_clustere_tstat_fwep, *_dpv_tstat_fwep, which is very unexpected in > my > > > > data set. > > > > > > > > So basically I really doubt if I am running the stats correctly > because > > > > PCC > > > > looks high at that big cluster (shown in PCC in attached screen > shot). > > > > > > > > Could you please suggest if there is any alternative (less stronger) > > > stat > > > > flag I can use here while running PALM command? > > > > > > > > I would be more than happy sharing any required files to interpret > the > > > > results. > > > > > > > > Thanks. > > > > > > > > On Wed, Mar 8, 2017 at 10:20 AM, Sahil Bajaj <sahil.br...(a)gmail.com> > > > > > wrote: > > > > > > > > > Thanks a lot Anderson and Antonin, that's really useful. > > > > > > > > > > Actually, I am having trouble in interpreting the results. Could > you > > > > > please share any document explaining all these tests/outputs and > their > > > > > interpretation in simple terms? > > > > > > > > > > Here I am attaching two screen shots: (1) Results I get when I > used > > > > cluster > > > > > extent stats: *dpv_tstat and (2). Simple partial correlations (I > > > > adjusted > > > > > the color bar between 0.30 and 0.35 to visualize the high > correlation > > > > > coefficients, which is ~0.35). > > > > > I do not see any significant clusters when I view > > > *_clustere_tstat_fwep, > > > > > *_dpv_tstat_fwep, which is very unexpected in my data set. > > > > > > > > > > So basically I really doubt if I am running the stats correctly > > > because > > > > > PCC looks high at that big cluster (shown in PCC in attached > screen > > > > shot). > > > > > > > > > > Could you please suggest if there is any alternative (less > stronger) > > > > stat > > > > > flag I can use here while running PALM command? > > > > > > > > > > I would be more than happy sharing any required files to interpret > the > > > > > results. > > > > > > > > > > Thanks. > > > > > > > > > > On Wed, Mar 8, 2017 at 9:27 AM, Martin Juneja <mj70...(a)gmail.com> > > > > wrote: > > > > > > > > > >> Hi Antonin and Anderson, > > > > >> > > > > >> That's wonderful ! I am able to run PALM now, without any > problem. > > > > >> > > > > >> Thank you so much for your help and time, I really appreciate > that. > > > > >> > > > > >> Best, > > > > >> MJ > > > > >> > > > > >> > > > > >> > > > > >> On Wed, Mar 8, 2017 at 6:30 AM, Anderson M. Winkler < > > > > >> wink...(a)fmrib.ox.ac.uk> wrote: > > > > >> > > > > >>> Hi all, > > > > >>> > > > > >>> That's exactly as Antonin says -- I have very little to add :-) > > > > >>> > > > > >>> Only a few suggestions: > > > > >>> > > > > >>> - With surfaces, both cluster and TFCE statistics tend to be > slow. > > > > >>> Consider using the tail approximation ("-approx tail -n 500 > > > > -nouncorrected") > > > > >>> > > > > >>> - Include -logp, so that the p-values are in log-10 scale. > > > Significant > > > > >>> p-values are then those above 1.3 (i.e., -log10(0.05). This will > > > help > > > > to > > > > >>> make the figures nicer later. > > > > >>> > > > > >>> All the best, > > > > >>> > > > > >>> Anderson > > > > >>> > > > > >>> > > > > >>> > > > > >>> On 8 March 2017 at 00:19, Antonin Skoch <a...(a)ikem.cz> wrote: > > > > >>> > > > > >>>> Dear Sahil, > > > > >>>> > > > > >>>> I suppose, for qcache 1.3 the equivalent cluster-forming > threshold > > > > >>>> z-value is > > > > >>>> > > > > >>>> two-tailed test: > > > > >>>> qnorm(1-10^-1.3/2)=1.958949 > > > > >>>> > > > > >>>> for one-tailed test: > > > > >>>> qnorm(1-10^-1.3)=1.643704 > > > > >>>> > > > > >>>> (qnorm is R function call for quantile function of normal > > > > distribution, > > > > >>>> you can compute this by using other methods or use statistical > > > > z-tables) > > > > >>>> > > > > >>>> And, the directionality of the hypothesis is I suppose > specified by > > > > the > > > > >>>> sign of your contrast vector, as I wrote in my previous mail. > > > > >>>> > > > > >>>> As for the output files, you can look at the documentation: > > > > >>>> > > > > >>>> https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/PALM/UserGuide# > Output_files > > > > > > >>>> > > > > >>>> For example, if you are looking for the p-values, used cluster > > > extent > > > > >>>> inference and used t-contrast, the file with FWER-corrected > > > p-values > > > > would > > > > >>>> be something like > > > > >>>> > > > > >>>> output_basename_clustere_tstat_fwep.mgz > > > > >>>> > > > > >>>> Antonin > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> Hello Martin and Antonin, > > > > >>>> > > > > >>>> I was following this conversation very closely to understand > how to > > > > use > > > > >>>> PALM in FreeSurfer. > > > > >>>> > > > > >>>> Can any of you please confirm in case I am interested in > checking > > > > >>>> correlation between gyrification index (LGI) and behavioral > measure > > > > using > > > > >>>> two tailed, p < 0.05: > > > > >>>> Step 1: I used --cache 1.3 > > > > >>>> Step 2: Because (1-10^-1.3)= 0.95, so I will have to use -C > 0.95 in > > > > palm > > > > >>>> command > > > > >>>> > > > > >>>> Could you please confirm if thats correct and the output > > > *_tstat.mgz > > > > is the > > > > >>>> final two-tailed corrected significant correlation map between > LGI > > > > and > > > > >>>> behavioral data? > > > > >>>> > > > > >>>> Thanks a lot for this wonderful discussion. > > > > >>>> Sahil > > > > >>>> > > > > >>>> PS: For one-tailed: it will be -C -0.95 in palm command, > correct? > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On Tue, Mar 7, 2017 at 3:48 PM, Antonin Skoch <a...(a)ikem.cz> > > > wrote: > > > > >>>> > > > > >>>> > Dear Martin, > > > > >>>> > > > > > >>>> > after -s option, there have to be 2 arguments, as I specified > in > > > my > > > > previous > > > > >>>> > mail: > > > > >>>> > > > > > >>>> > -s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh > > > > > >>>> > > > > > >>>> > And beware that -C has to have negative sign, if your > hypothesis > > > is > > > > >>>> > one-tailed negative. > > > > >>>> > > > > > >>>> > Antonin > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > Hi Antonin, > > > > >>>> > > > > > >>>> > Thank you so much for this detailed explanation, that's > really > > > > useful. > > > > >>>> > > > > > >>>> > Following your instructions, I ran: > > > > >>>> > > > > > >>>> > palm -i lh.MEQ_LGI.10.mgh -s fsaverage/surf/lh.white.avg.area.mgh > > > > > > > > -d > > > > >>>> > check.csv -t Contrast_MEQ.csv -n 5000 -m > > > lh.MEQ_LGI.glmdir/mask.mgh > > > > -o > > > > >>>> > myresults -Cstat extent -C 3.719016 > > > > >>>> > > > > > >>>> > but I am getting following error: > > > > >>>> > > > > > >>>> > Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) with > the > > > > following > > > > >>>> > options: > > > > >>>> > -i lh.MEQ_LGI.10.mgh > > > > >>>> > -s fsaverage/surf/lh.white.avg.area.mgh > > > > >>>> > -d check.csv > > > > >>>> > -t Contrast_MEQ.csv > > > > >>>> > -n 5000 > > > > >>>> > -m lh.MEQ_LGI.glmdir/mask.mgh > > > > >>>> > -o myresults > > > > >>>> > -Cstat extent > > > > >>>> > -C 3.719016 > > > > >>>> > Loading surface 1/1: fsaverage/surf/lh.white.avg.area.mgh > > > > >>>> > Reading input 1/1: lh.MEQ_LGI.10.mgh > > > > >>>> > > > > > >>>> > Struct contents reference from a non-struct array object. > > > > >>>> > > > > > >>>> > Error in palm_takeargs (line 1632) > > > > >>>> > if any(size(plm.srf{s}.data.vtx, > > > > >>>> > 1) == ... > > > > >>>> > > > > > >>>> > Error in palm_core (line 33) > > > > >>>> > [opts,plm] = palm_takeargs(varargin{:}); > > > > >>>> > > > > > >>>> > Error in palm (line 81) > > > > >>>> > palm_core(varargin{:}); > > > > >>>> > > > > > >>>> > Could you please help me in resolving this error? > > > > >>>> > > > > > >>>> > Thanks much. > > > > >>>> > > > > > >>>> > On Tue, Mar 7, 2017 at 2:55 PM, Antonin Skoch <a...(a)ikem.cz> > > > > wrote: > > > > >>>> > > > > > >>>> > > Dear Martin, > > > > >>>> > > > > > > >>>> > > input -i input file is > > > > >>>> > > > > > > >>>> > > lh.MEQ_LGI.10.mgh file in your glmdir directory (for left > > > > hemisphere). > > > > >>>> > > > > > > >>>> > > As you could read in following messages in the referenced > > > thread > > > > in FSL > > > > >>>> > > discussion forum, cluster-forming threshold need to be > > > specified > > > > in z, not > > > > >>>> > > in t. > > > > >>>> > > > > > > >>>> > > Therefore, you would have to select cluster forming > threshold > > > and > > > > specify > > > > >>>> > > it as a z score. > > > > >>>> > > > > > > >>>> > > I think that your z-score for your original mri_glmfit-sim > > > > commandline > > > > >>>> > > argument > > > > >>>> > > > > > > >>>> > > --cache 4 neg > > > > >>>> > > > > > > >>>> > > will be -qnorm(1-10^-4)=-3.719016. (I am not perfectly > sure > > > > since I never > > > > >>>> > > tried negative one-side hypothesis testing in PALM). > > > > >>>> > > > > > > >>>> > > You could also use other statistics, such as cluster mass, > or > > > > TFCE. See > > > > >>>> > > PALM user guide. > > > > >>>> > > > > > > >>>> > > Do not include -pmethodp none and -pmethodr none, since you > > > would > > > > need the > > > > >>>> > > partitioning due your non-orthogonal design matrix. > > > > >>>> > > > > > > >>>> > > ?h.white.avg.area.mgh file (which you will find under > fsaverage > > > > directory) > > > > >>>> > > goes as second argument after -s option. > > > > >>>> > > > > > > >>>> > > Therefore I suppose the commandline for cluster extent > > > inference > > > > with > > > > >>>> > > cluster forming threshold p=0.0001, negative one-sided > > > > hypothesis, left > > > > >>>> > > hemisphere, will be hopefully something like > > > > >>>> > > > > > > >>>> > > palm > > > > >>>> > > -i y.mgh > > > > >>>> > > -s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh > > > > > > > > >>>> > > -d Xg.csv > > > > >>>> > > -t your_contrasts.csv > > > > >>>> > > -n number_of_permutations > > > > >>>> > > -m mask.mgh > > > > >>>> > > -o output_basename > > > > >>>> > > -Cstat extent > > > > >>>> > > -C -3.719016 > > > > >>>> > > -saveglm > > > > >>>> > > -savedof > > > > >>>> > > -savemetrics > > > > >>>> > > > > > > >>>> > > The last 3 commandline options are only for diagnostical > > > > purposes. > > > > >>>> > > > > > > >>>> > > The output is surface overlay you can visualize in > freeview. > > > > >>>> > > > > > > >>>> > > I use following code snippet for the reporting significant > > > > clusters in MNI > > > > >>>> > > coordinates: > > > > >>>> > > > > > > >>>> > > # PALM output cluster extent p maps have 1 outside cluster > - > > > > problem with > > > > >>>> > > mri_surfcluster and also for display in freeView > > > > >>>> > > #here we set values 1 to 0 in pmaps. > > > > >>>> > > #done by binarizing and subtracting > > > > >>>> > > if [[ $# -ne 2 ]]; then > > > > >>>> > > echo "get cluster summary of PALM statistics. Expecting 2 > > > > arguments: 1- > > > > >>>> > > input p-map, 2- hemisphere (lh/rh)" > > > > >>>> > > exit > > > > >>>> > > fi > > > > >>>> > > mri_binarize --i $1 --min 1 --o p_bin.mgz > > > > >>>> > > mris_calc --output ${1%%.mgz}_filtered.mgz $1 sub p_bin.mgz > > > > >>>> > > mri_surfcluster --in ${1%%.mgz}_filtered.mgz --subject > > > fsaverage > > > > --hemi $2 > > > > >>>> > > --surf white --annot aparc --thmin 0.000000001 --thmax 0.05 > > > > --mask mask.mgh > > > > >>>> > > --sum ${1%%.mgz}_cluster.summary --nofixmni > > > > >>>> > > rm p_bin.mgz > > > > >>>> > > > > > > >>>> > > They are not Bonferroni-corrected for 2 hemispheres > > > (--2spaces). > > > > >>>> > > > > > > >>>> > > Regarding your design and contrast: > > > > >>>> > > > > > > >>>> > > Design has to be matrix of values. You can use qdec to > produce > > > > Xg.dat file > > > > >>>> > > with design matrix, then rename it to Xg.csv to be > correctly > > > > readable by > > > > >>>> > > PALM. > > > > >>>> > > > > > > >>>> > > Regards, > > > > >>>> > > > > > > >>>> > > Antonin > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > Hi Antonin, > > > > >>>> > > > > > > >>>> > > As you suggested in discussion forum, I tried to run > following > > > > command > > > > >>>> > > after mri_glmfit: > > > > >>>> > > > > > > >>>> > > palm -s fsaverage/surf/lh.white -n 10000 -m mask.mgh -Cstat > > > > extent -C > > > > >>>> > > 1.974975 -pmethodp none -pmethodr none -twotail -d > > > Design_MEQ.txt > > > > -t > > > > >>>> > > Contrast_MEQ.txt > > > > >>>> > > > > > > >>>> > > Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) > with > > > the > > > > following > > > > >>>> > > options: > > > > >>>> > > > > > > >>>> > > -s fsaverage/surf/lh.white > > > > >>>> > > > > > > >>>> > > -n 10000 > > > > >>>> > > > > > > >>>> > > -m mask.mgh > > > > >>>> > > > > > > >>>> > > -Cstat extent > > > > >>>> > > > > > > >>>> > > -C 1.974975 > > > > >>>> > > > > > > >>>> > > -pmethodp none > > > > >>>> > > > > > > >>>> > > -pmethodr none > > > > >>>> > > > > > > >>>> > > -twotail > > > > >>>> > > > > > > >>>> > > -d Design.txt > > > > >>>> > > > > > > >>>> > > -t Contrast.txt > > > > >>>> > > > > > > >>>> > > Found FSL in /usr/share/fsl/5.0 > > > > >>>> > > > > > > >>>> > > Found FreeSurfer in /usr/local/freesurfer > > > > >>>> > > > > > > >>>> > > Found SPM in /usr/local/spm12 > > > > >>>> > > > > > > >>>> > > Error using palm_takeargs (line 1141) > > > > >>>> > > > > > > >>>> > > Missing input data (missing "-i"). > > > > >>>> > > > > > > >>>> > > Error in palm_core (line 33) > > > > >>>> > > > > > > >>>> > > [opts,plm] = palm_takeargs(varargin{:}); > > > > >>>> > > > > > > >>>> > > Error in palm (line 81) > > > > >>>> > > > > > > >>>> > > palm_core(varargin{:}); > > > > >>>> > > > > > > >>>> > > Looks like error is because its missing -i input here, I am > not > > > > sure what's > > > > >>>> > > input file here? > > > > >>>> > > > > > > >>>> > > Also, I am trying to correlate LGI versus behavioral score, > > > > regressing out > > > > >>>> > > the effect of sex and age. So I just wanted to confirm if > my > > > > design.txt and > > > > >>>> > > contrast.txt files are correct here. Please find both > > > following: > > > > >>>> > > > > > > >>>> > > Design file (Variables Behav, Age) as following: > > > > >>>> > > > > > > >>>> > > S001 Male 60 36 > > > > >>>> > > > > > > >>>> > > S003 Female 73 29 > > > > >>>> > > > > > > >>>> > > S004 Male 48 39 > > > > >>>> > > > > > > >>>> > > .......so on...... > > > > >>>> > > > > > > >>>> > > Contrast file as following: > > > > >>>> > > 0 0 0.5 0.5 0 0 (same as *.mtx file used for glm_fit) > > > > >>>> > > > > > > >>>> > > Thank you so much for your help and time. > > > > >>>> > > > > > > >>>> > > On Tue, Mar 7, 2017 at 10:49 AM, Martin Juneja < > > > mj70...(a)gmail.com> > > > > wrote: > > > > >>>> > > > > > > >>>> > > > Hi Antonin, > > > > >>>> > > > > > > > >>>> > > > Thanks a lot for your reply. > > > > >>>> > > > > > > > >>>> > > > Somehow, in the link you sent, I could not find any > response > > > to > > > > your > > > > >>>> > > > email. But I can see your email to Anderson and command > line > > > > parameters. > > > > >>>> > > > > > > > >>>> > > > As I am not an expert in using FreeSurfer, so would it be > > > > possible for you > > > > >>>> > > > to share detailed step-by-step guide and PALM command > after I > > > > run > > > > >>>> > > > mri_glmfit > > > > >>>> > > > command and how and where to include > '?h.white.avg.area.mgh' > > > > file? > > > > >>>> > > > > > > > >>>> > > > I would really appreciate any help. > > > > >>>> > > > > > > > >>>> > > > On Mon, Mar 6, 2017 at 4:28 PM, Antonin Skoch < > a...(a)ikem.cz> > > > > wrote: > > > > >>>> > > > > > > > >>>> > > >> Dear Martin, > > > > >>>> > > >> > > > > >>>> > > >> I think yes, you can use PALM with FreeSurfer surfaces, > see > > > my > > > > >>>> > > >> conversation with Anderson on FSL list: > > > > >>>> > > >> > > > > >>>> > > >> https://www.jiscmail.ac.uk/ > cgi-bin/webadmin?A2=ind1604&L=FSL > > > > >>>> > > > > >>>> > > > > > >>>> > > > > > > >>>> > > >> &D=0&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=239088 > > > > > > > > >>>> > > >> > > > > >>>> > > >> but beware not to forget to include average the vertex > area > > > > >>>> > > >> (?h.white.avg.area.mgh) file. > > > > >>>> > > >> > > > > >>>> > > >> Antonin > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> If you don't have an orthogonal design, then you can't > use > > > > >>>> > > >> mri_glmfit-sim. I think you can use PALM: > > > > >>>> > > >> > > > > >>>> > > >> https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/PALM > > > > >>>> > > >> > > > > >>>> > > >> I have not tried it yet. > > > > >>>> > > >> > > > > >>>> > > >> Anderson, can you use PALM with surfaces? > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> On 03/06/2017 05:23 PM, Martin Juneja wrote: > > > > >>>> > > >> > Hi Dr. Greve, > > > > >>>> > > >> > > > > > >>>> > > >> > I tried to run: mri_glmfit-sim --glmdir > lh.MEQ_LGI.glmdir > > > > --sim perm > > > > >>>> > > >> > 1000 3 permcsd --sim-sign abs --cwpvalthresh .05 > > > > >>>> > > >> > It gives error that ERROR: design matrix is not > > > orthogonal, > > > > cannot be > > > > >>>> > > >> > used with permutation. > > > > >>>> > > >> > > > > > >>>> > > >> > But when I run: mri_glmfit-sim --glmdir > lh.MEQ_LGI.glmdir > > > > --sim perm > > > > >>>> > > >> > 1000 3 permcsd --sim-sign abs --cwpvalthresh .05 > > > > --perm-force, it > > > > >>>> > > >> > works. > > > > >>>> > > >> > > > > > >>>> > > >> > I am not sure whether I will have to make the design > > > matrix > > > > >>>> > > >> > orthogonal. If so, could you please tell me how that > can > > > be > > > > done? > > > > >>>> > > >> > > > > > >>>> > > >> > Or using --perm-force should be fine? > > > > >>>> > > >> > > > > > >>>> > > >> > Thanks. > > > > >>>> > > >> > > > > > >>>> > > >> > On Mon, Mar 6, 2017 at 1:58 PM, Douglas N Greve > > > > >>>> > > >> > <gr...(a)nmr.mgh.harvard.edu <mailto: > gr...(a)nmr.mgh.harvard <gr...(a)nmr.mgh.harvard>. > > > edu > > > > <gr...(a)nmr.mgh.harvard.edu> > > > > >>>> > > >> > <gr...(a)nmr.mgh.harvard.edu> > > > > >>>> > > >> > <gr...(a)nmr.mgh.harvard.edu> > > > > >>>> > > >> > <gr...(a)nmr.mgh.harvard.edu>>> wrote: > > > > >>>> > > >> > > > > > >>>> > > >> > This is a problem with using LGI in that it is > already > > > > extremely > > > > >>>> > > >> > smooth > > > > >>>> > > >> > that the smoothness exceeds the limit of the look > up > > > > table that we > > > > >>>> > > >> > supply. I recommend that you not use a > gaussian-based > > > > correction > > > > >>>> > > >> > for > > > > >>>> > > >> > LGI. Instead, use permutation (see mri_glmfit-sim > > > > --help). > > > > >>>> > > >> > > > > > >>>> > > >> > > > > > >>>> > > >> > > > > > >>>> > > >> > On 03/06/2017 01:36 PM, Martin Juneja wrote: > > > > >>>> > > >> > > Hello everyone, > > > > >>>> > > >> > > > > > > >>>> > > >> > > I am trying to extract clusters showing > significant > > > > correlation > > > > >>>> > > >> > > between LGI and a behavioral measure. I am able > to > > > > extract PCC > > > > >>>> > > >> > and > > > > >>>> > > >> > > sig.mgh but at the last step when I try to run > > > > simulation command > > > > >>>> > > >> > to > > > > >>>> > > >> > > view corrected results and I run: > > > > >>>> > > >> > > > > > > >>>> > > >> > > mri_glmfit-sim --glmdir lh.MEQ_LGI.glmdir > --cache 4 > > > > neg --cwp > > > > >>>> > > >> > 0.05 > > > > >>>> > > >> > > --2spaces > > > > >>>> > > >> > > > > > > >>>> > > >> > > I get following error: > > > > >>>> > > >> > > > > > > >>>> > > >> > > ERROR: cannot find > > > > >>>> > > >> > > > > > > >>>> > > >> > > > > > >>>> > > >> > /usr/local/freesurfer/average/mult-comp-cor/fsaverage/lh/ > > > > > cortex/fwhm35/neg/th40/mc-z.csd > > > > >>>> > > >> > > > > > > >>>> > > >> > > But I can see mc-z.csd file in fwhm30 etc. > > > > >>>> > > >> > > > > > > >>>> > > >> > > Full message on terminal window is attached > > > following. > > > > >>>> > > >> > > > > > > >>>> > > >> > > Any help would be really appreciated. > > > > >>>> > > >> > > > > > > >>>> > > >> > > ----- Full message ---- > > > > >>>> > > >> > > > > > > >>>> > > >> > > cmdline mri_glmfit.bin --y lh.MEQ_LGI.10.mgh > --fsgd > > > > MEQ.fsgd > > > > >>>> > > >> > dods --C > > > > >>>> > > >> > > Corr-MEQ-cor.mtx --surf fsaverage lh --cortex > > > --glmdir > > > > >>>> > > >> > lh.MEQ_LGI.glmdir > > > > >>>> > > >> > > > > > > >>>> > > >> > > WARNING: unrecognized mri_glmfit cmd option > > > > mri_glmfit.bin > > > > >>>> > > >> > > > > > > >>>> > > >> > > SURFACE: fsaverage lh > > > > >>>> > > >> > > > > > > >>>> > > >> > > log file is lh.MEQ_LGI.glmdir/cache.mri_glmfit-sim.log > > > > > > > > > > > > >>>> > > >> > > > > > > >>>> > > >> > > /usr/local/freesurfer/bin/mri_glmfit-sim > > > > >>>> > > >> > > > > > > >>>> > > >> > > --glmdir lh.MEQ_LGI.glmdir --cache 4 neg --cwp > 0.05 > > > > --2spaces > > > > >>>> > > >> > > > > > > >>>> > > >> > > $Id: mri_glmfit-sim,v 1.60 2016/04/30 15:13:36 > greve > > > > Exp $ > > > > >>>> > > >> > > > > > > >>>> > > >> > > Mon Mar 6 11:11:13 MST 2017 > > > > >>>> > > >> > > > > > > >>>> > > >> > > setenv SUBJECTS_DIR > > > > >>>> > > >> > > /data/emot/Freesurfer/FreeSurferSegmentation/SB_AgingAll > > > > > > > > > > > > >>>> > > >> > > > > > > >>>> > > >> > > FREESURFER_HOME /usr/local/freesurfer > > > > >>>> > > >> > > > > > > >>>> > > >> > > Original mri_glmfit command line: > > > > >>>> > > >> > > > > > > >>>> > > >> > > cmdline mri_glmfit.bin --y lh.MEQ_LGI.10.mgh > --fsgd > > > > MEQ.fsgd > > > > >>>> > > >> > dods --C > > > > >>>> > > >> > > Corr-MEQ-cor.mtx --surf fsaverage lh --cortex > > > --glmdir > > > > >>>> > > >> > lh.MEQ_LGI.glmdir > > > > >>>> > > >> > > > > > > >>>> > > >> > > DoSim = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > UseCache = 1 > > > > >>>> > > >> > > > > > > >>>> > > >> > > DoPoll = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > DoPBSubmit = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > DoBackground = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > DiagCluster = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > gd2mtx = dods > > > > >>>> > > >> > > > > > > >>>> > > >> > > fwhm = 35.073391 > > > > >>>> > > >> > > > > > > >>>> > > >> > > ERROR: cannot find > > > > >>>> > > >> > > > > > > >>>> > > >> > > > > > >>>> > > >> > /usr/local/freesurfer/average/mult-comp-cor/fsaverage/lh/ > > > > > cortex/fwhm35/neg/th40/mc-z.csd > > > > >>>> > > >> > > > > > > >>>> > > >> > > > > _______________________________________________ > Freesurfer mailing list > Freesurfer(a)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. >

2 1

Can we use fressurfer 6 with the Human connectome project's pipeline ?
by CAGNA Bastien 13 Mar '17

13 Mar '17

Dear freesurfer experts, I'm wondering if it's possible to run the human connetome project's minimal processing pipeline using freesurfer 6 ? Does it require some update of the pipeline or is there anybody that have already enjoyed the new freesurfer version with this pipeline ? Thank you for your attention and your help, Bastien Cagna

2 1

incorrect surfaces and aseg labeling in subject with large occipital horns of lateral ventricle
by Antonin Skoch 13 Mar '17

13 Mar '17

Dear experts, in my longitudinal study with 2 timepoints I encountered issue with aseg.presurf labeling and white/pial surface estimation of one subject in region of occipital horns of lateral ventricle. The voxels in horns are mislabeled as either white or gray matter or contain zero values. I am still in the stage 1 of longitudinal stream, so this is classical cross-sectional recon-all stream. I tried to reprocess this subject by using recon-all -s subj -bigventricles -FLAIRpial (despite the fact that the subject does not have generally enlarged ventricles I thought that this could help nonlinear registration by mri_ca_register ). In case of timepoint 2 this helped to correctly label left occipital horn and corrected error with surfaces, but right occipital horn remained labeled as white matter. In contrast, in case of timepoint 1 the -bigventricles did not help to label left occipital horn and additionally new massive error with white surface placement appeared in the region of occipital horn of left lateral ventricle. See the attached screenshots to ilustrate this issue: tp1_nobigventricles_surface_OK tp1_bigventricles_surface_error tp2_nobigventricles_surface_error tp2_bigventricles_surface_OK I have uploaded file occipital_horn_ventricle_aseg_and_surf_error.tar.gz containing 4 recons (timepoint 1 and 2 with and withoug -bigventricles) to your server. I suppose that the root of the problem is incorrect nonlinear registration. Could you please advise how to diagnose and solve the error? I am using development version from beginning of february 2017. Regards, Antonin Skoch

2 1

mri_surfcluster to obtain ROI (label) centroid MNI coordinates
by Ladan Shahshahani 13 Mar '17

13 Mar '17

Hi, Following previous discussions on the mailing list, I am using mri_surfcluster to extract MNI (or Talairach) coordinates of a label using: mri_surfcluster --in $SUBJECTS_DIR/fsaverage/surf/lh.area --clabel lh.G_cingulate-Isthmus.label --sum ~/Desktop/pract3 --centroid --thmin 0 --hemi lh --subject fsaverage --nofixmni I tried different labels, but for all of them I get the following coordinates (for left hemisphere): -29.4 -22.0 17.4 I see that others are having the same problem, like the one in the following link: https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2015-November/042446… Am I missing something here? What can I do to solve this problem? Bests, Ladan

2 1

BUG: bbregister --init-best needs to unset InitCoreg
by Christopher Markiewicz 13 Mar '17

13 Mar '17

Hi all, bbregister --init-best always produces "ERROR: cannot spec an init method with --init-best", because InitCoreg is defined as 1 by default, and never set to 0 by --init-best. (Setting something else that unsets InitCoreg will trigger the same error.) Example, given SUBJ and EPI: $ bbregister --init-best --s $SUBJ --mov $EPI --o ${EPI%.nii.gz}_bbr.nii.gz --reg ${EPI%.nii.gz}_bbr.dat ERROR: cannot spec an init method with --init-best Using FreeSurfer 6.0 release installed on an Ubuntu 16.04 machine. Thanks, Chris

2 1

Clarification on FS 6.0
by elisa ferrari 13 Mar '17

13 Mar '17

Hello, I examined data from a public database (ABIDE) processed both with freesurfer 5.1 and freesurfer 6.0 and I noticed that in version 5.1 the equality "SubCortGrayVol"+"CortexVol" ="TotalGrayVol" holds for every patient while it is never true in version 6.1. I attach as proof two histograms of the distribution of the quantities in the equation above calculated on a dataset of 1076 patients. [cid:d80a9491-4bf9-4d0c-b4d8-1c62f6e13aab] For clarity I also attach the aseg.stats files of one patient obtained with the two different freesurfer versions in which I have highlighted the data I'm talking about. [cid:3eb0d89a-ff21-40c8-b3b1-d3ab0b43392a][cid:54bbdf12-ce54-4e8a-9eee-ec9d43f0e600] I observed that for almost every patient the values of "TotalGrayVol" and "CortexVol" haven't changed between the two versions while "SubCortGrayVol" differs widely. [cid:d0af9a9d-e9a3-4910-a0aa-03dd0874d4b1] I am thus asking if in version 6.0 "TotalGrayVol" is obtained from the sum of more than two quantities and not anymore by "SubCortGrayVol"+"CortexVol", if yes what are the quantities involved? Or could this be just due to an error in the measurement of "SubCortGrayVol"? I also have noticed that in files lh and rh aparc.stats (of FS 6.0) sometimes there are less cortical structures than the usual 34. I have always thought that this was due to the fact that freesurfer didn't manage to define these regions, however looking at aparc.DKTatlas.stats (FS 6.0) I realized that sometimes there are more than the usual 31 cortical structure. In particular sometimes appears the temporal pole, that doesn’t belong to the DKT atlas. What could be causing this error? I attach an example file. [cid:5c1e1627-6cd4-47e0-813d-1da5ca283470] Thank you for your attention. Elisa

2 1

← Newer
1
...
13
14
15
16
17
18
19
...
27
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Freesurfer March 2017