[Mne_analysis] Relevance of Freesurfer expert settings for MNE workflow

[Denis-Alexander Engemann]

Hi

Thanks for the pointers D,

I was referring to the so called expert preferences section at the wiki pages:
https://surfer.nmr.mgh.harvard.edu/fswiki/recon-all

And I was wondering how save I am with the defaults.

2012/10/10 dgw <dgwakeman at gmail.com>:
> Hi Denis,
>
> Well, I'm not sure what you mean by "expert settings". In my
> experience, as long as your FreeSurfer white matter surfaces look good
> (based on experience with the FreeSurfer Tutorial) and your BEM
> surfaces look good (most important for EEG), your results should be
> robust.

Ok, good to know that. So that should be fine.

Importantly, at least at the moment the pial surfaces are not
> used in MNE, so editing them does not affect the inverse solution.
> Obviously optimizing your MR acquisition for the highest quality
> possible will improve FreeSurfer's performance (the biggest effect I
> have noticed is in reduced manual editing necessary).
>
> The most concerning errors (outside of obvious problems e.g. missing
> lobes etc) are those where the surface becomes "sharp". This geometry
> will yield strange influences in your estimates and also is
> physiologically unlikely.

you mean anatomically implausible junctions or 'spikes'?

 Another important consideration is
> decimation (whether you do, and how you do), furthermore, I strongly
> recommend using --loosevar with any decimated data.
>

Actually I just sticked with the default parameters exposed in section
3 and 12 of the mne manual which implies --loose 0.2. Actually I
calculated patches on setting up the source space so loosevar could be
an option.
Is it actually possible to exactly tell the differences or make
recommendations for reasonably robust defaults or when to use which
option? For me as an MNE beginner it it still is somewhat difficult to
recognize the consequences of these options.

Thanks,
Denis

> HTH
> D
>
> On Wed, Oct 10, 2012 at 7:08 AM, Denis-Alexander Engemann
> <d.engemann at fz-juelich.de> wrote:
>> Dear MNEs,
>>
>> I just learned about the possibility that the Freesurfer segmentation
>> quality could depend on the set of imaging parameters used.
>> For my current measurements I have access to mprages measured on a 3T
>> Siemens Trio device with a 16-Ch coil.
>> The segmentation looks ok and also my source estimates, but I was
>> wondering whether the passing expert settings instead of the defaults
>> when invoking recon-all should make a practically significant
>> difference.
>> Does anyone have experience with this?
>>
>> Cheers,
>> Denis
>>
>>
>> ------------------------------------------------------------------------------------------------
>> ------------------------------------------------------------------------------------------------
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich
>> Sitz der Gesellschaft: Juelich
>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
>> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
>> Prof. Dr. Sebastian M. Schmidt
>> ------------------------------------------------------------------------------------------------
>> ------------------------------------------------------------------------------------------------
>>
>> Kennen Sie schon unsere app? http://www.fz-juelich.de/app
>>
>> _______________________________________________
>> Mne_analysis mailing list
>> Mne_analysis at nmr.mgh.harvard.edu
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/mne_analysis
>>
>>
>> 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.
>>