By default QDEC users the monte carlo simulation. FSL randomise can do
On 03/06/2014 10:35 AM, Tudor Popescu wrote:
> Sorry, couple more questions:
>
> 1) I know that QDEC's/mri_glmfit's equivalent in FSL ("randomise")
> applies the GLM by doing permutations, and so already corrects for
> multiple comparisons in the process. How similar is this to what
> Monte-Carlo does (i.e. controlling FWE via repeated simulations) upon
> the initially uncorrected QDEC results?
either monte carlo or permutaion. mri_glmfit-sim can also do permutation.
>What do you mean by "inverting the t-values"? It is the same as changing
> 2) In FSL, a comparison between groups A and B is tested by defining
> both a "A>B" as well as a "B>A" contrast – the reason being (as far as
> I understand) that taking the logical complement of "A>B", i.e.
> inverting the t-values in the statistical map, is *not* equal to the
> map produced by the cotnrast "B>A". How come, then, that QDEC phrases
> the group contrast in a "two-tailed" way (i.e. "do groups A and B
> differ")? Is the dichotomy not necessary in QDEC, or is it simply done
> behind the scenes?
the sign of the t values. In FS we preserve the sign in our "sig" maps
(sign(t)*-log10(p)).
>I'm not sure what you mean here. If someone warped their T1 data to some
> 3) I've read papers where the thickness from *native*-space was used
> in the analyses, even though initially T1-weighted images were
> initially aligned to the ICBM 152 template. Why isn't thickness from
> this *standard*-space used, as happens in FSLVBM with grey matter
> density? Why even register to the template in the first place if
> you're then going to go back and use native-space values?
template space and then computed thickness, then that thickness will not
represent the thickness from the individual and the group stats will be
skewed by this
doug
> <mailto:tudor3@gmail.com>> wrote:
>
> Thank you very much Doug.
> Tudor
>
>
> On 6 March 2014 03:53, Douglas Greve <greve@nmr.mgh.harvard.edu
>> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>> <mailto:greve@nmr.mgh.harvard.edu>> wrote:
>
>
> On 3/5/14 5:25 PM, Tudor Popescu wrote:
>> Hello, I have some questions on doing group comparisons with
>> thickness, area and volume. Many thanks in advance for any help!
>>
>> 1) For a DOSS design with group and gender as categorical
>> factors, I see that an interaction contrast ("Is there a
>> group-gender interaction in the mean thickness?") still
>> exists - but what does this contrast mean, given that DOSS by
>> definition doesn't allow for interactions?
> Are you using QDEC? If so, don't use the DOSS as the contrasts
> are incorrect. It is possible to have an interaction among the
> categorical factors with a DOSS.
>
>>
>> 2) it makes sense that measures such as thickness are
>> analysed vertex-wise in QDEC, however what does it mean when
>> the dependent variable is area or volume - measures that do
>> not make physical sense for a single vertex but only at the
>> level of a region consisting of *several* vertices?
> The interpretation is a little more difficult. Each vertex is
> assigned an area equal to the average of the triangles
> adjacent to it. This is just a value that can be mapped to a
> common space like any other value (eg, thickness) (but there
> is a special jacobain correction to account for stretching or
> compression). Smoothing reduces the effect of having different
> sized triangles. One can think of it like this: in the common
> space (fsaverage) image having a patch of a certain size. When
> you mapped that patch back to each individual, how big would
> that patch be? You could then do group statistics on that
> number. In this way you could analyze the entire hemisphere.
> Now imagine doing this but making the patch smaller and smaller.
>>
>> 3) For values extracted from atlas regions with
>> aparcstats2table, it seems that the product of the extracted
>> CT and area is in the same order of magnitude as the
>> extracted volume, but never really the same or even close –
>> why, when the volume of a region should theoretically be the
>> product of its surface area by its thickness?
> It is an issue of how it is computed. Sum(CT*Area) !=
> Sum(CT)*Sum(Area). When computing volume, CT*Area is computed
> for each vertex then summed across vertices.
> doug
>
>>
>> Tudor
>>
>>
>> _______________________________________________
>> Freesurfer mailing list
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer> <mailto:Freesurfer@nmr.mgh.harvard.edu>
>
>
> _______________________________________________
> 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 mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Douglas N. Greve, Ph.D.
MGH-NMR Center
greve@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer