On 03/07/2014 06:45 PM, Tudor Popescu wrote:
> Thanks Doug. I wasn't clear in my DOSS question, I meant to ask why 
> are categoricalXcontinuous interactions (e.g. such as the one probed 
> by the contrast "Does the thickness-age correlation differ between 
> group A and B?") still created in DOSS analyses, when by definition 
> DOSS imposes that (e.g.) thickness-age correlations have the same 
> slopes for all groups?
Do not use DOSS with QDEC. There is a bug in it that causes the 
contrasts to be in error at times.
>
> Two more questions:
>
> - If selecting the Volume-based radio-button in QDEC's Design tab, the 
> Measure drop-down list is replaced with "Not yet implemented", but 
> pressing Analyze still proceeds as normal and delivers the expected 
> contrasts. What does "Volume" exactly refer to, in those contrasts, 
> and how is that different to the "normalised volume" measured in 
> voxel-based morphometry (VBM)?
It was supposed to be an analysis like a VBM where you are looking a 
volume-structured data instead of surface-structured.
>
> - (Bailey, Zatorre, and Penhune 2013) say that "The thickness maps 
> produced are not restricted to the voxel resolution of the original 
> data and thus are capable of detecting submillimeter differences 
> between groups". Is it really the case that the power of a 
> surface-based analysis is completely independent of the resolution of 
> the T1 images? Isn't the accuracy of the mesh dependent on the 
> volumetric (T1) resolution?

Bruce may want to weigh in on this one, but it is not the case that any 
resolution will do. I think what they are saying is that the surface 
placement (and so thickness est) is better than the voxel size (subvox 
rsolution). This can be achieved because of smoothness constraints.

doug

>
> Thanks!
> Tudor
>
>
> On 6 March 2014 16:53, Douglas N Greve <gr...@nmr.mgh.harvard.edu 
> <mailto:gr...@nmr.mgh.harvard.edu>> wrote:
>
>
>     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?
>     By default QDEC users the monte carlo simulation. FSL randomise can do
>     either monte carlo or permutaion. mri_glmfit-sim can also do
>     permutation.
>     >
>     > 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?
>     What do you mean by "inverting the t-values"? It is the same as
>     changing
>     the sign of the t values. In FS we preserve the sign in our "sig" maps
>     (sign(t)*-log10(p)).
>     >
>     > 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?
>     I'm not sure what you mean here. If someone warped their T1 data
>     to some
>     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
>     >
>     > Thanks!
>     >
>     >
>     > On 6 March 2014 10:20, Tudor Popescu <tud...@gmail.com
>     <mailto:tud...@gmail.com>
>     > <mailto:tud...@gmail.com <mailto:tud...@gmail.com>>> wrote:
>     >
>     > Thank you very much Doug.
>     > Tudor
>     >
>     >
>     > On 6 March 2014 03:53, Douglas Greve <gr...@nmr.mgh.harvard.edu
>     <mailto:gr...@nmr.mgh.harvard.edu>
>     > <mailto:gr...@nmr.mgh.harvard.edu
>     <mailto:gr...@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
>     >> 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
>     >
>     >
>     > _______________________________________________
>     > Freesurfer mailing list
>     > 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.
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Freesurfer mailing list
>     > 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
>     gr...@nmr.mgh.harvard.edu <mailto:gr...@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: https://gate.nmr.mgh.harvard.edu/filedrop2
>     www.nmr.mgh.harvard.edu/facility/filedrop/index.html
>     <http://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 <mailto:Freesurfer@nmr.mgh.harvard.edu>
>     https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
>
>
> _______________________________________________
> 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
gr...@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

Reply via email to