Freesurfer October 2012

freesurfer@nmr.mgh.harvard.edu

119 participants
191 discussions

Average Thickness in QDEC
by Antonella Kis 02 Oct '12

02 Oct '12

Dear Experts, What is the best way to get the average thickness for each subject in QDEC, more exactly for the uncorrected clusters? I know when running QDEC theer is a stats_tables file saved so I wonder if the lh. aparc.thickness.stas.dat represents the mean cortical thickness. Should this values be the same with my thickness values under cache.th20.abs.y.ocn.dat obtained by running the mri_glmfit-sim with the option --cache where in order to catch all the clusters since I need the uncorrected one I used --cwpvalthresh .999? Thank you for you time and clarifications. Best regards, Antonella

1 0

Lesioned brain (surface) registration to fs average
by octavian lie 02 Oct '12

02 Oct '12

Dear all, I need to mark the cortical extent of a lesion (intersection of the lesion and pial surface, where "lesion" represent a epilepsy related resection). After the pial labeling of the resection, I need to register the labeled surface to the fsaverage. I completed recon-all routine on the postop T1, and went nicely, corrected pial surface in a few places. Question: what is the best way to mark the pial extent of a resection? Is there a way to accurately register the lesioned pia to the fsaverage, potentially by masking the resection ROI? Thank you for your insight, Octavian.

2 1

ADC map negative values
by Efrat Kliper 01 Oct '12

01 Oct '12

Dear FreeSurfers Users, When i am using the dt_recon function to create adc map i get quite a lot negative values, dose anyone encounter this problem? Thanks, Efrat

1 0

random effects analysis with performance values
by Maryam Vaziri Pashkam 01 Oct '12

01 Oct '12

Hi Dough, I have run a searchlight analysis on 10 subjects and want to run a random effects analysis with mri_glmfit across subject. I have the results of each subject projected on the fsaverage surface. But I have no idea how to make it to 1) compare the values in each voxel with 0.5 instead of 0 2) how to make it ignore the fact that I dont have variance for each subject and only have a single performance value (support vector machine performance) for each voxel (it looks like the mri_glmfit needs a ces.var.nii) Any idea how I can do this? Sorry if this is a rookie question. I am totally new to searchlight and random effects analysis in fsfast. Thanks, Maryam

3 5

Triangulated surfaces
by Efrat Kliper 01 Oct '12

01 Oct '12

Dear FreeSurfer Users, I have created a binary mask for the hippocampi and now i want to create the triangulated surfaces of the hippocampi? An one know how to do it? Thanks, Efrat

2 1

Error with mri_volcluster
by Antonella Kis 01 Oct '12

01 Oct '12

Dear Doug, I was running the mri_glmfit-sim \ --glmdir GroupAnalysis_abs.glmdir \ --sim perm 1000 3 permcsd \ --sim-sign abs \ --cwpvalthresh .05 just to get an idea of how my FA Group Analysis data is looking and I got an error before to get the permcsd.sig.cluster.summary file from the mri_volcluster: mri_volcluster --in GroupAnalysis_abs.glmdir/contrast/sig.mgh --mask GroupAnalysis_abs.glmdir/mask.mgh --reg /usr/local/freesurfer/subjects/fsaverage/mri.2mm/reg.2mm.dat --no-fixmni --cwsig GroupAnalysis_abs.glmdir/contrast/permcsd.sig.cluster.mgh --sum GroupAnalysis_abs.glmdir/contrast/permcsd.sig.cluster.summary --ocn GroupAnalysis_abs.glmdir/contrast/permcsd.sig.ocn.mgh --cwpvalthresh .05 --seg fsaverage aparc+aseg.mgz --csdpdf GroupAnalysis_abs.glmdir/contrast/permcsd.pdf.dat --csd GroupAnalysis_abs.glmdir/csd/permcsd.j001-contrast.csd --vwsig GroupAnalysis_abs.glmdir/contrast/permcsd.sig.voxel.mgh ERROR: cannot find /media/2Tra/Antonella_2011/DTI_FS/GLM_CVS/fsaverage/mri/aparc+aseg.mgz I replaced the fsaverage/mri/aparc+aseg.mgz with the cvs_avg35/mri/aseg.mgz and to get the cluster summary I was running: mri_volcluster --in GroupAnalysis_abs.glmdir/contrast/sig.mgh --mask GroupAnalysis_abs.glmdir/mask.mgh --reg /usr/local/freesurfer/subjects/fsaverage/mri.2mm/reg.2mm.dat --no-fixmni --cwsig GroupAnalysis_abs.glmdir/contrast/permcsd.sig.cluster.mgh --sum GroupAnalysis_abs.glmdir/contrast/permcsd.sig.cluster.summary --ocn GroupAnalysis_abs.glmdir/contrast/permcsd.sig.ocn.mgh --cwpvalthresh .05 --seg cvs_avg35 aseg.mgz --csdpdf GroupAnalysis_abs.glmdir/contrast/permcsd.pdf.dat --csd GroupAnalysis_abs.glmdir/csd/permcsd.j001-contrast.csd --vwsig GroupAnalysis_abs.glmdir/contrast/permcsd.sig.voxel.mgh but then I am getting the following error: NOT Adjusting threshold for 1-tailed test Using defalt ctab /usr/local/freesurfer/FreeSurferColorLUT.txt INFO: loading mask volume: GroupAnalysis_abs.glmdir/mask.mgh INFO: MRIbinarize01(): nhits = 961260 Found 961260 voxels in mask ERROR: Input volume voxel dimensions do not match those in the registration file. If the input volume is in bshort/bfloat format, check that there is an accompanying bhdr file. Can you please help me to solve this problem. I am not sure what to do. Thank you very much! Antonella PS. Just to remember you that I registered my FA data over the CVS space but I have for each subject from dt_recom the register.dat file so I suppose I need to keeo the fsaverage in the --reg COMMAND-LINE ARGUMENTS.

3 2

Re: [Freesurfer] mri_glmfit-sim with pre-cached fails
by Ed Gronenschild 01 Oct '12

01 Oct '12

Doug, For the PCA residuals we found 37% for the first component. The same analysis has been done for FreeSurfer v4.5.0, and we found a residual FWHM of 15.27 and 30% for the first PCA component. The time courses showed some outliers for both versions, very much dependent on the position on the surface, i.e., each time different subjects were outside the confidence limits. Summarizing: v4.5.0: residualFWHM = 15.27; 1st PCA 30% v5.0.0: residualFWHM = 34.00; 1st PCA 37% (number of subjects is 53). So, it is a puzzle why the residual FWHM is that large for v5.0.0. Ed On 1 Oct 2012, at 9:15, Ed Gronenschild wrote: > > On 28 Sep 2012, at 18:00, freesurfer-request(a)nmr.mgh.harvard.edu > wrote: > >> Message: 27 >> Date: Fri, 28 Sep 2012 10:03:47 -0400 >> From: Douglas N Greve <greve(a)nmr.mgh.harvard.edu> >> Subject: Re: [Freesurfer] Fmri_glmfit-sim with pre-cached fails >> To: freesurfer(a)nmr.mgh.harvard.edu >> Message-ID: <5065AE43.7060103(a)nmr.mgh.harvard.edu> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Hmmm, that's a lot, but I'm very surprised that the final FWHM is >> over >> 30. How many subjects do you have? There might be one that is >> messed up. >> You can check this by loading the y.mgh as a "time course" in >> tksurfer. >> It will give you a graph with each subject. Finally, you can run >> mri_glmfit with the --pca option to get a PCA of the residuals. This >> will create a folder called pca-eres. Look at the stats.dat and >> see how >> much variance is explained by the first component (first row, 4th >> column). >> doug >> >> On 09/28/2012 03:31 AM, Ed Gronenschild wrote: >>> Hi Doug, >>> >>> For mri_glmfit I used a cortical thickness smoothed with a FWHM >>> of 20, >>> resulting from using the -qcache option in recon-all. >>> >>> Ed >>> >>> On 27 Sep 2012, at 18:00, freesurfer-request(a)nmr.mgh.harvard.edu >>> <mailto:freesurfer-request@nmr.mgh.harvard.edu> wrote: >>> >>>> Message: 16 >>>> Date: Thu, 27 Sep 2012 11:29:06 -0400 >>>> From: Douglas N Greve <greve(a)nmr.mgh.harvard.edu >>>> <mailto:greve@nmr.mgh.harvard.edu>> >>>> Subject: Re: [Freesurfer] mri_glmfit-sim with pre-cached fails >>>> To: freesurfer(a)nmr.mgh.harvard.edu >>>> <mailto:freesurfer@nmr.mgh.harvard.edu> >>>> Message-ID: <506470C2.5060906(a)nmr.mgh.harvard.edu >>>> <mailto:506470C2.5060906@nmr.mgh.harvard.edu>> >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>> >>>> Hi Ed, when I created the cache, I only went up to 30mm FWHM >>>> thinking >>>> that no one would ever go above it, or maybe should never go >>>> above it. I >>>> can create tables at higher smoothing levels, but 34mm is a lot of >>>> smoothing. How much did you apply to the data? >>>> doug >>>> >>>> On 09/27/2012 05:48 AM, Ed Gronenschild wrote: >>>> >>>>> Hi, >>>>> >>>>> I want to apply a cluster correction with mri_glmfit-sim with >>>>> the --cache option: >>>>> mri_glmfit-sim --glmdir my_glmdir --cache 1.3 abs >>>>> It fails with the error message that it can't find the file: >>>>> FSDir/average/mult-comp-cor/fsaverage/lh/cortex/fwhm34/abs/ >>>>> th1.3/mc- >>>>> z.csd >>>>> (FSDir is the directory where FreeSurfer is located, >>>>> version 5.0.0, Mac OSX10.5) >>>>> Looking at the content of the ....fsaverage/lh/cortex directory >>>>> than indeed, only the directories fwhm01, fwhm02, ..., fwhm30 >>>>> are present. >>>>> In the log file from mri_glmfit I can read that the residualFWHM >>>>> is 34.005014. Since this FWHM is automatically derived by >>>>> mri_glmfit, does it mean that I can never use the --cache option >>>>> in this case? > >>>>> Cheers, >>>>> >>>>> Ed >>>>> >

2 1

Re: [Freesurfer] command to check the regional cortical thicknesses and volumes
by Douglas N Greve 01 Oct '12

01 Oct '12

Hi Yawu, there is a file in the output called subject/stats/lh.aparc.stats (there is an rh.aparc.stats too as well as ?h.aparc.a2009s.stats files). doug ps. Please send emails to the FreeSurfer list instead of directly to me. Thanks! On 10/01/2012 03:36 AM, Liu Yawu wrote: > Hi Douglas, > After run "recon-all -cw256 -s AA -all", how to check the check the regional cortical thicknesses and volumes? > Regards, > Yawu > > -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(a)nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html

1 0

Re: [Freesurfer] CT Method Comparison
by Douglas N Greve 01 Oct '12

01 Oct '12

hi Gari, looking at this I don't really see a problem. Yes, the t-test is very significant, but I would expect that from a paired t looking across different methods. the size of the effect is very small, about 1.5%. Do you see this as a problem? doug On 09/28/2012 05:14 AM, Garikoitz Lerma-Usabiaga wrote: > Hi Doug, > I think that the differences are significant enough, but just in case > please find attached an excel file with the data and the t-test. > > Some of the ROI-s are small (Triangularis, Operculum, Orbitalis and > then all together in the IFG). I attached images for each of them for > reference. > > > If in any case you assume that there are going to be differences, > which method would you recommend and why? > > Thanks! > Gari > > PS after mri_preproc I didn't smooth the surface as in the qdec > example, ¿should I do that? > > > > > > > On Fri, Sep 28, 2012 at 4:24 AM, Douglas Greve > <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: > > > OK, got it (finally). I would not expect the answers to be > identical, but I would expect them to be "close". How close are > they? If the ROI is very small, there might be appreciable > differences between the two. > > doug > > > > On 9/27/12 6:26 PM, Garikoitz Lerma-Usabiaga wrote: >> Hi, >> You are right, this was one of the methods. The second one is as >> follows (I copy the repeated steps): >> >>> For a given ROI, you have a nifti file (roi.nii) in 2mm space >>> defined on colin27. This ROI volume has a voxel value == 1 if it >>> is in the ROI or 0 if it is out. >>> >>> You have a registration between roi.nii and orig.mgz >>> >>> You run mri_vol2surf on roi.nii to get lh.roi.mgh >> >> I run mris_preproc for every subject to Colin27: mris_preproc >> --out /subject/surf/ROI_toColin27.mgh --target Colin27 --hemi lh >> --meas thickness --s subject >> >> mri_segstats --seg /Colin27/surf/lh.roi.mgh --in >> /subject/surf/ROI_to_Colin127.mgh --sum >> subject/stats/target_lh.ROI.stats >> >> >> Thanks for your help, >> Gari >> >> >> Note: >> You said: You run mri_cor2label (with --surf option) to convert >> lh.roi.mgh into lh.roi.label >> Just in case, this is how I run it: >> >> * mri_cor2label --i /subjects/Colin27/lh.ROI.mgh --surf Colin27 >> lh --id 1 --l /subjects/Colin27/lh.ROI.label >> * mri_label2label --srclabel >> /subjects/Colin27/lh.ROI.label --srcsubject Colin27 >> --trgsubject subject --trglabel lh.ROI_Colin27_to_bert >> --regmethod surface --hemi lh >> >> >> >> >> On 26/09/2012, at 23:56, Douglas N Greve >> <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: >> >>> Sorry, I'm still a little lost. Let me see if I have it right: >>> >>> For a given ROI, you have a nifti file (roi.nii) in 2mm space >>> defined on colin27. This ROI volume has a voxel value == 1 if it >>> is in the ROI or 0 if it is out. >>> >>> You have a registration between roi.nii and orig.mgz >>> >>> You run mri_vol2surf on roi.nii to get lh.roi.mgh >>> >>> You run mri_cor2label (with --surf option) to convert lh.roi.mgh >>> into lh.roi.label >>> >>> You run mri_label2label on lh.roi.label to map it into an >>> individual subject >>> >>> You run mris_anatomical_stats on the individual lh.roi.label file >>> >>> Does this describe one of your processing streams correctly? If >>> so, what is the other processing stream (given in this kind of >>> detail)? >>> >>> doug >>> >>> >>> >>> On 09/25/2012 04:43 PM, Garikoitz Lerma-Usabiaga wrote: >>>> I have both. In origin, the ROI-s are 2mm volume based .nii >>>> that I convert to FS .mgh with register.dat I obtained with >>>> bbregister. >>>> -- In the case of label2label method I create the surface >>>> version with mri_vol2surf (and the correspondence is perfect), >>>> and then use mri_label2label in order to get the CT averages. >>>> -- In the case of surf2surf, I use the volume based .mgh with >>>> mri_preproc (mri_surf2surf) >>>> >>>> thanks! >>>> Gari >>>> >>>> On Tue, Sep 25, 2012 at 5:57 PM, Douglas N Greve >>>> <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> >>>> <mailto:greve@nmr.mgh.harvard.edu>> wrote: >>>> >>>> So you have ROIs in Colin27 space and you want to map them into >>>> your CT space and compute average CT intensities over them? Are >>>> the ROIs volume-based or surface-based? >>>> doug >>>> >>>> >>>> On 09/25/2012 05:09 AM, Garikoitz Lerma-Usabiaga wrote: >>>> >>>> Hi Doug, >>>> many thanks for your answer, I try to detail it more: >>>> >>>> 1.- bbregister is registering two Colin27 brains. First >>>> one is >>>> a 2mm found in spm/canonical/single_subject_T1.nii, and >>>> second >>>> one is the FS_spm_Canonical found in SurfRend >>>> distribution. It >>>> was in .COR format and I run recon-all to have a modern >>>> version of it. As they are almost the same brain the >>>> registration matrix is quite simple and the registration was >>>> perfect. This way I had exactly the same ROI-s for Colin27 in >>>> SPM and in FS (it did not work that well for fsaverage, >>>> that's >>>> why I took this approach). >>>> >>>> 2.- In any case, I have several ROI-s in Colin27 space in FS, >>>> and then when I try to obtain average CT values from my >>>> subjects I use these 2 different approaches: label2label and >>>> surf2surf. >>>> mri_anatomical_stats is run on the labels created by >>>> mri_label2label. >>>> >>>> >>>> If you think it will be of help I can send the detailed >>>> command line calls, >>>> thanks! >>>> Gari >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Sep 22, 2012 at 12:47 AM, Douglas N Greve >>>> <greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> >>>> <mailto:greve@nmr.mgh.harvard.edu> >>>> <mailto:greve@nmr.mgh.harvard.edu >>>> <mailto:greve@nmr.mgh.harvard.edu>>> wrote: >>>> >>>> Hi Gari, I'll need more information. I can't tell >>>> what you >>>> are doing. >>>> Eg, what is being registered with BBR? what is >>>> mris_anatomical_stats run >>>> on? Where does Colin27 come into it and why? >>>> doug >>>> >>>> On 09/19/2012 06:15 PM, Garikoitz Lerma-Usabiaga >>>> (Gari) wrote: >>>>> Dear Freesurfers, >>>>> We've been comparing 2 different methods to obtain CT averages >>>> for 4 Volume ROI-s (volume ROI-s were in Colin27 space). >>>>> We've used the 40 buckner subjects for the comparisons. >>>>> >>>>> METHOD L2L: bbregister>> mri_vol2surf (mgh)>> >>>> mri_binarize (mgh)>> mri_cor2label (label)>> >>>> mri_label2label>> >>>> mris_anatomical_stats >>>>> METHOD S2S: bbregister>> mri_vol2surf>> mri_preproc >>>> (mri_surf2surf)>> mri_segstats >>>>> >>>>> >>>>> After performing t-test-s over the results, we can observe that >>>> the results are in many cases different. >>>>> >>>>> -- Is there a way to choose the "best" method? Which one should >>>> we use for our work and why? >>>>> >>>>> Many thanks again for your help, >>>>> Gari >>>>> >>>>> PD We've tabulated a third method as well: >>>>> METHOD SurfRend: Surfrend (.w)>> mri_surf2surf(.mgh)>> >>>> mri_binarize(.mgh)>> mri_cor2label (.label)>> >>>> mris_anatomical_stats >>>>> _______________________________________________ >>>>> Freesurfer mailing list >>>>> Freesurfer(a)nmr.mgh.harvard.edu >>>>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.harvard.edu >>>> <mailto:Freesurfer@nmr.mgh.harvard.edu>> >>>> >>>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>>>> >>>>> >>>> >>>> -- >>>> Douglas N. Greve, Ph.D. >>>> MGH-NMR Center >>>> greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> >>>> <mailto:greve@nmr.mgh.harvard.edu> >>>> <mailto:greve@nmr.mgh.harvard.edu >>>> <mailto:greve@nmr.mgh.harvard.edu>> >>>> Phone Number: 617-724-2358 <tel:617-724-2358> >>>> <tel:617-724-2358 <tel:617-724-2358>> >>>> Fax: 617-726-7422 <tel:617-726-7422> <tel:617-726-7422 >>>> <tel:617-726-7422>> >>>> >>>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting >>>> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> FileDrop: >>>> www.nmr.mgh.harvard.edu/facility/filedrop/index.html >>>> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>>> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>>> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>>> >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> Freesurfer(a)nmr.mgh.harvard.edu >>>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.harvard.edu> >>>> <mailto:Freesurfer@nmr.mgh.harvard.edu >>>> <mailto: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. >>>> >>>> >>>> >>>> -- Douglas N. Greve, Ph.D. >>>> MGH-NMR Center >>>> greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> >>>> <mailto:greve@nmr.mgh.harvard.edu> >>>> Phone Number: 617-724-2358 <tel:617-724-2358> >>>> Fax: 617-726-7422 <tel:617-726-7422> >>>> >>>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting >>>> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>>> FileDrop: >>>> www.nmr.mgh.harvard.edu/facility/filedrop/index.html >>>> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>>> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>>> >>>> >>> >>> -- >>> Douglas N. Greve, Ph.D. >>> MGH-NMR Center >>> greve(a)nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> >>> Phone Number: 617-724-2358 >>> Fax: 617-726-7422 >>> >>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting >>> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> >>> FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html >>> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> >>> > > -- Douglas N. Greve, Ph.D. MGH-NMR Center greve(a)nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422 Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html

2 2

long_mris_slopes command: temporal average calculation
by Shannon Kogachi 01 Oct '12

01 Oct '12

Hi, I had a question about how the temporal average is calculated for subjects with multiple timepoints. I used the long_mris_slopes command on a longitudinal set of data. However, when I compared the average volumes calculated through this command to the average volumes calculated in excel after extracting the same vertices at the individual timepoints, these values did not match up. The average volumes calculated through long_mris_slopes were smaller. Please let me know if there is a way to explain this discrepancy. Thank you! -Shannon K.

2 8

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 October 2012