Hi Jeannette,
Thanks again for your help! I'm still a bit confused though, sorry...
> I finally see what you're getting at and I understand that if you
> entered the copes instead of the feats you might get a different
> ppheight in each case. For the same reason different runs shouldn't
> have different weights, different copes shouldn't have different
> weights (unless you're fixing a contrast scaling problem...say if in
> one cope you used -1 -1 1 1 and you need to scale by .5 and the other
> cope is 1 -1 0 0 and doesn't need scaling).
Do you mean different copes from the same run?
In the regular case (feed feat directories in the 2nd level), the
PPheight will be different for each copeX.feat output by the second
level analysis, correct?
> In that respect if I'm remembering your model correctly I think
> featquery will be using the same scale for both conditions.
Right, I get one single PPheight that is used for all my copes. That was
actually my concern, as in the regular case it seems to be different...
> If it seems like featquery isn't going to give you the result you
> desire, I recommend scripting it up yourself, it is only 2 lines of
> code.
Well, I just want to make sure I understand what I desire first! :)
Thanks again, all the best
Stephane
> Good luck!
> Jeanette
>
> On Mon, Mar 17, 2008 at 3:22 PM, Stephane Jacobs <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> Hi Jeannette,
>
> Thanks a lot for helping me with this! First of all, I should say
> that I did not really expect featquery to be doing exactly the
> same thing on outputs of 1st and 2nd level analyses, precisely
> because I have read you writeup already. :) Thanks for this very
> helpful document!
>
> I guess my questions boil down to this: assume you have 2
> conditions, represented by 2 contrasts at the 1st level (e.g.cond
> A > rest and cond B > rest).
>
> - if the conditions are run within the same run, when you run your
> cross-session 2nd level analysis with feat directories as inputs,
> you end up with cope1.feat and cope2.feat, corresponding to
> condition A and B, respectively. Cope1.feat contains a design.lcon
> file with an average PPheight value obtained by averaging all
> PPheight values obtained for condition A at the first level. Same
> goes for cope2.feat and condition B. When you run featquery on
> this 2nd level output, it will actually run separately for
> cope1.feat and cope2.feat, thus using different scaling factors
> for condition A and B. Right?
>
> - now if the conditions are run in different sessions, as in my
> case, and you want to combine them at the second level, you use
> cope images as inputs to the second level analysis. You then end
> up with a single cope1.feat directory containing cope images for
> both conditions, and a single design.lcon file that has only one
> average PPheight value, calculated by averaging all PPheight
> values obtained at the first level for condition A *and* condition
> B. When you run featquery on this 2nd level analysis, both
> condition A and B get scaled by the same factor.
>
> My question: is it normal that in these 2 cases conditions A and B
> get scaled either by different or by the same factor? Or should
> one correct for this in the second case by calculating the average
> PPheight value separately for each condition?
>
> Thanks again for your help!
>
> Stephane
>
> On Mon, 17 Mar 2008 11:16:09 -0700, Jeanette Mumford
> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
> > Hi
> Stephane, I'll have a try answering your questions.
> >
> >
> > On Fri, Mar 14, 2008 at 11:20 AM, Stephane Jacobs <
> [log in to unmask] <mailto:[log in to unmask]> > wrote:
> >
> Hi Steve,
> >
>
> >
> Sorry if this is a confusing discussion. I guess my question comes
> from
> >
> the fact that I would expect Feat query to do the same thing (if we
> >
> ignore the transformations of a mask in standard space, for example)
> >
> regardless of whether it's run on a 1st level or on a 2nd level
> output.
> >
> > I agree %-change can seem a bit confusing, but hopefully this
> will clear some things up for you. Actually you should not prefer
> first level featquery to produce exactly the same result as a
> second level featquery *especially* if the pp heights vary
> greatly. If they do vary, which can happen perhaps because you're
> only looking at correct trials across subjects or the event
> length is dependent on something like reaction time, which will
> vary across subjects, it doesn't make any sense to give different
> subjects different weights. After all, if this were necessary
> we'd be having huge problems with the multilevel GLMs since we
> don't re-weight subjects by their ppheight (it wouldn't make
> sense). This is why in the writeup that I made (Steve gave the
> link in an earlier email
> http://mumford.bol.ucla.edu/perchange_guide.pdf ) I advise *not*
> to run featquery on the first level GLM copes, especially in an
> event related study. Running at the second level makes more sense
> and if you don't like the interpretation of the featquery %-change
> (%-change using the average pp height), then the writeup gives
> instructions for doing it other ways.
> >
>
> >
> >
> >
> The way I understand things, in my case, the PPheights are combined
> >
> across all my conditions because I used cope images as inputs to
> my 2nd
> >
> level analysis rather than feat directories. Whereas, if I had
> used feat
> >
> directories as inputs to my 2nd level analysis, PPheights would have
> >
> been estimated separately for my different conditions. And the
> latter is
> >
> what happens when one runs Featquery on a 1st level output (one would
> >
> probably not combine PPheights from different conditions when doing
> >
> cross sessions and then cross subjects averaging). Am I right so far?
> >
>
> >
> > I think if you were to run an analysis both ways (feed copes,
> feed Feats) you'll find featquery will give you the same result.
> I realize you can't test this out on your data and I haven't
> tested it out myself, but it seems like that would be the case.
> Again, if your PPheights are different between runs/subjects the
> you wouldn't want to run featquery at the first level, actually
> the second level is more sensible since it uses the same scale
> factor, which is the average ppheight. For an event-related study
> design I think the most interpretable thing to do is choose your
> own scale factor as I describe in the writeup Steve referenced in
> his last email ( http://mumford.bol.ucla.edu/perchange_guide.pdf ).
> >
>
> >
> >
> > Hope that clears a few things up for you.
> >
> > Cheers,
> > Jeanette
> >
> >
>
> >
> If I am, the difference between the 2 cases (feat directories vs. cope
> >
> images input into a 2nd level analysis) is indeed probably minor if
> >
> PPheights are similar from one condition to the other, but I wanted to
> >
> make sure I understood the logic behind this.
> >
> Also, is it realistic to imagine that one could get fairly different
> >
> PPheights between conditions, or should these always be pretty
> similar?
> >
> in other words, would this always be alright to combine PPheights
> across
> >
> different conditions?
> >
>
> >
> Thanks again for your time and help!
> >
>
> >
> Best,
> >
>
> >
> >
> >
> >
> >
> Stephane
> >
>
> >
> Steve Smith wrote:
> >
> > Hi,
> >
> >
> >
> > On 26 Feb 2008, at 23:13, Stephane Jacobs wrote:
> >
> >
> >
> >> Hi Steve,
> >
> >>
> >
> >> Thanks again for your answer, and sorry for resurrecting a
> somewhat
> >
> >> old discussion... I'm still confused about this, and unless I
> have a
> >
> >> wrong idea about what are the "relevant contrasts" at the first
> >
> >> level, I don't see how featquery could get the right PPheight
> values...
> >
> >>
> >
> >> So, to make sure I'm clear, here's my precise case. At the first
> >
> >> level, I have for each subject two different types of run, each
> >
> >> containing 2 of my four conditions:
> >
> >> Run1: conditions A1 and B2
> >
> >> Run2: conditions A2 and B1
> >
> >>
> >
> >> At the first level, I modeled each condition versus modeled rest
> >
> >> periods. Therefore, the design.con file for each feat directory
> >
> >> contains the PPheight values for condition A1 and B2 or A2 and B1,
> >
> >> depending on the type of run.
> >
> >>
> >
> >> At the second level, I wanted to include all 4 conditions, so I
> used
> >
> >> cope images instead of feat directories as inputs, and
> included cope
> >
> >> images corresponding to conditions A1, A2, B1 and B2. In my
> >
> >> understanding, what happens then is that the PPheight value
> contained
> >
> >> in the design.lcon file at the output of the 2nd level analysis is
> >
> >> the average of the first level PPheight values across all inputs,
> >
> >> that is in my case, all four conditions.
> >
> >>
> >
> >> I understand that this should be fine for FEAT, but what
> happens when
> >
> >> one runs featquery on the output of the second level analysis?
> From
> >
> >> the code I've read, I don't see how it could get anything else but
> >
> >> this average PPheight value across different conditions, which I
> >
> >> don't think is what we want... Especially if different conditions
> >
> >> give very different PPheight values.
> >
> >
> >
> > I'm not sure exactly what you're saying is problematic with this, or
> >
> > even how this is different from what you are doing below..... in
> >
> > general is you have very different ppheights for the different
> >
> > first-level conditions, then there's probably a problem in combining
> >
> > their resulting PEs/COPEs, surely? Or are you talking about the
> >
> > fine-detail tuning of such issues, such as is addressed in
> Jeanette's
> >
> > excellent techrep at
> http://mumford.bol.ucla.edu/perchange_guide.pdf
> >
> > ? As far as I can see, both FEAT and Featquery are in general
> doing
> >
> > the right thing for most situations......?
> >
> >
> >
> > Cheers.
> >
> >
> >
> >
> >
> >>
> >
> >>
> >
> >> So, what I've done is to go back to the first level output and the
> >
> >> design.con files, computed the average PPheight values for each
> >
> >> condition separately (I had several occurrences of each run type),
> >
> >> and had featquery use these values instead of the average PPheight
> >
> >> value across conditions.
> >
> >>
> >
> >> Does this make sense, or am I even more confused than I
> thought? :-)
> >
> >>
> >
> >> Thanks again for your help and time!
> >
> >>
> >
> >> Best,
> >
> >>
> >
> >> Stephane
> >
> >>
> >
> >>
> >
> >> On Fri, 1 Feb 2008 08:51:30 +0000, Steve Smith <
> [log in to unmask] <mailto:[log in to unmask]> >
> >
> >> wrote:
> >
> >>> Hi,
> >
> >>>
> >
> >>> Reasonable question - however, I still believe that this is
> fine: the
> >
> >>> higher-level .lcon has already (at the start of the
> higher-level FEAT
> >
> >>> run) been created to contain the average of all the relevant
> first-
> >
> >>> level contrasts' PPheight values - this averaging has already been
> >
> >>> done and Featquery just reads this single value in.
> >
> >>>
> >
> >>> Hope this answers the query?
> >
> >>>
> >
> >>> Cheers.
> >
> >>>
> >
> >>>
> >
> >>> On 29 Jan 2008, at 02:00, Stephane Jacobs wrote:
> >
> >>>
> >
> >>>> Hi Steve,
> >
> >>>>
> >
> >>>> Steve Smith wrote:
> >
> >>>>>> My question was: is this correct in this case to go back to the
> >
> >>>>>> first
> >
> >>>>>> level design.con file, and selectively average the ppheight
> value
> >
> >>>>>> for
> >
> >>>>>> each contrast separately, and have featquery use those
> instead?
> >
> >>>>>
> >
> >>>>> I think what FEAT/Featquery are doing should be right - it
> should be
> >
> >>>>> averaging the effective ppheight across all the relevant
> first-level
> >
> >>>>> contrasts, and as far as I can see this should be correct.
> >
> >>>>>
> >
> >>>>> Cheers, Steve.
> >
> >>>>>
> >
> >>>> I'm probably missing something here. I did not check into
> details for
> >
> >>>> FEAT, but I have looked into the Featquery script, and here
> is what I
> >
> >>>> understood: when calculating the scaling factor, it
> determines whether
> >
> >>>> it's a first or higher level analysis just by looking whether a
> >
> >>>> design.lcon file exists within the feat directory. If not (first
> >
> >>>> level),
> >
> >>>> it uses the ppheight from the design.con file, which specifies a
> >
> >>>> ppheight value for each EV. If it does find design.lcon (higher
> >
> >>>> level),
> >
> >>>> however, then it uses the single value contained in this file
> to scale
> >
> >>>> all the copes contained in the feat directory - which, in my
> case,
> >
> >>>> come
> >
> >>>> from different 1st level copes. If this is right, then I
> don't see how
> >
> >>>> this ppheight is related only to the relevant 1st level
> contrasts...
> >
> >>>>
> >
> >>>> Could you tell me where I'm getting lost here?
> >
> >>>>
> >
> >>>> Thanks again
> >
> >>>>
> >
> >>>> Best
> >
> >>>>
> >
> >>>> Stephane
> >
> >>>>
> >
> >>>>
> >
> >>>>>
> >
> >>>>>> Thanks again for your time!
> >
> >>>>>>
> >
> >>>>>> Stephane
> >
> >>>>>>
> >
> >>>>>>
> >
> >>>>>>
> >
> >>>>>> Steve Smith wrote:
> >
> >>>>>>> Hi,
> >
> >>>>>>>
> >
> >>>>>>> Yes, this should work fine; FEAT should extract the correct
> >
> >>>>>>> ppheight
> >
> >>>>>>> values from the correct contrast specification files,
> according
> >
> >>>>>>> to the
> >
> >>>>>>> copes that you have selected. It should appropriately
> estimate the
> >
> >>>>>>> right average ppheight for each of your second-level
> contrasts.
> >
> >>>>>>>
> >
> >>>>>>> Cheers, Steve.
> >
> >>>>>>>
> >
> >>>>>>>
> >
> >>>>>>>
> >
> >>>>>>> On 15 Jan 2008, at 19:39, Stephane Jacobs wrote:
> >
> >>>>>>>
> >
> >>>>>>>> Hello,
> >
> >>>>>>>>
> >
> >>>>>>>> I had a question about the way the model peak-to-peak
> height was
> >
> >>>>>>>> computed for a second level analysis of which input were cope
> >
> >>>>>>>> images
> >
> >>>>>>>> rather than feat directories, and about running featquery
> on it.
> >
> >>>>>>>> I had
> >
> >>>>>>>> forgotten to mention that I am interested in percent signal
> >
> >>>>>>>> change for
> >
> >>>>>>>> contrasts (condition vs. modeled rest), which explains
> why I'm
> >
> >>>>>>>> looking
> >
> >>>>>>>> at the ppheight values in design.lcon. Also, I'm looking at
> >
> >>>>>>>> contrasts
> >
> >>>>>>>> that have been set at the first level already, then I have
> >
> >>>>>>>> ppheight
> >
> >>>>>>>> values for each of those and for each first level run.
> >
> >>>>>>>>
> >
> >>>>>>>> Can anybody tell me whether I'm doing the right thing here?
> >
> >>>>>>>>
> >
> >>>>>>>> Thanks a lot,
> >
> >>>>>>>>
> >
> >>>>>>>> Stephane
> >
> >>>>>>>>
> >
> >>>>>>>>
> >
> >>>>>>>> Stephane Jacobs wrote:
> >
> >>>>>>>>> Hello,
> >
> >>>>>>>>>
> >
> >>>>>>>>> I would like to run featquery on a second level
> analysis (cross
> >
> >>>>>>>>> session -
> >
> >>>>>>>>> within subject level) to compute percent change of COPEs
> within a
> >
> >>>>>>>>> given ROI.
> >
> >>>>>>>>> I understand that featquery is using the average
> ppheight found
> >
> >>>>>>>>> in
> >
> >>>>>>>>> the
> >
> >>>>>>>>> design.lcon file in the copeX.feat directory as a scale
> factor to
> >
> >>>>>>>>> compute
> >
> >>>>>>>>> percent change.
> >
> >>>>>>>>> However, I am wondering whether this is still correct to
> do so
> >
> >>>>>>>>> in my
> >
> >>>>>>>>> case.
> >
> >>>>>>>>> Indeed, I have fed cope images into my second level
> analysis,
> >
> >>>>>>>>> instead of
> >
> >>>>>>>>> .feat directories, as I needed to contrast EVs coming from
> >
> >>>>>>>>> different
> >
> >>>>>>>>> runs.
> >
> >>>>>>>>> Then, I end up with one single cope1.feat directory at
> the output
> >
> >>>>>>>>> of my
> >
> >>>>>>>>> second level analysis, which contains as many cope
> images as I
> >
> >>>>>>>>> have set
> >
> >>>>>>>>> contrasts at the 2nd level (4), rather than getting
> >
> >>>>>>>>> cope1.feat..cope4.feat
> >
> >>>>>>>>> as when you feed feat directories containing all the
> same EVs.
> >
> >>>>>>>>>
> >
> >>>>>>>>> Therefore, it seems that the value contained in
> design.lcon is
> >
> >>>>>>>>> the
> >
> >>>>>>>>> average
> >
> >>>>>>>>> of the ppheight across all my contrasts. I wonder if I
> rather
> >
> >>>>>>>>> should
> >
> >>>>>>>>> compute
> >
> >>>>>>>>> an average ppheight for each of my 2nd level contrast
> >
> >>>>>>>>> separately, to
> >
> >>>>>>>>> be more
> >
> >>>>>>>>> accurate?
> >
> >>>>>>>>>
> >
> >>>>>>>>> Thanks in advance for all your thoughts and advice,
> >
> >>>>>>>>>
> >
> >>>>>>>>> Best,
> >
> >>>>>>>>>
> >
> >>>>>>>>> Stephane
> >
> >>>>>>>>>
> >
> >>>>>>>>>
> >
> >>>>>>>>>
> >
> >>>>>>>>
> >
> >>>>>>>
> >
> >>>>>>>
> >
> >>>>>>>
> ---------------------------------------------------------------------------
> >
> >>>>>>>
> >
> >>>>>>>
> >
> >>>>>>>
> >
> >>>>>>> Stephen M. Smith, Professor of Biomedical Engineering
> >
> >>>>>>> Associate Director, Oxford University FMRIB Centre
> >
> >>>>>>>
> >
> >>>>>>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
> >
> >>>>>>> +44 (0) 1865 222726 (fax 222717)
> >
> >>>>>>> [log in to unmask] <mailto:[log in to unmask]>
> http://www.fmrib.ox.ac.uk/~steve <http://www.fmrib.ox.ac.uk/%7Esteve>
> >
> >>>>>>>
> ---------------------------------------------------------------------------
> >
> >>>>>>>
> >
> >>>>>>>
> >
> >>>>>>>
> >
> >>>>>>>
> >
> >>>>>>>
> >
> >>>>>>
> >
> >>>>>
> >
> >>>>>
> >
> >>>>>
> ---------------------------------------------------------------------------
> >
> >>>>>
> >
> >>>>>
> >
> >>>>> Stephen M. Smith, Professor of Biomedical Engineering
> >
> >>>>> Associate Director, Oxford University FMRIB Centre
> >
> >>>>>
> >
> >>>>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
> >
> >>>>> +44 (0) 1865 222726 (fax 222717)
> >
> >>>>> [log in to unmask] <mailto:[log in to unmask]>
> http://www.fmrib.ox.ac.uk/~steve <http://www.fmrib.ox.ac.uk/%7Esteve>
> >
> >>>>>
> ---------------------------------------------------------------------------
> >
> >>>>>
> >
> >>>>>
> >
> >>>>>
> >
> >>>>>
> >
> >>>>
> >
> >>>
> >
> >>>
> >
> >>>
> ---------------------------------------------------------------------------
> >
> >>>
> >
> >>> Stephen M. Smith, Professor of Biomedical Engineering
> >
> >>> Associate Director, Oxford University FMRIB Centre
> >
> >>>
> >
> >>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
> >
> >>> +44 (0) 1865 222726 (fax 222717)
> >
> >>> [log in to unmask] <mailto:[log in to unmask]>
> http://www.fmrib.ox.ac.uk/~steve <http://www.fmrib.ox.ac.uk/%7Esteve>
> >
> >>>
> ---------------------------------------------------------------------------
> >
> >>>
> >
> >>>
> >
> >>
> >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------------
> >
> >
> >
> > Stephen M. Smith, Professor of Biomedical Engineering
> >
> > Associate Director, Oxford University FMRIB Centre
> >
> >
> >
> > FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
> >
> > +44 (0) 1865 222726 (fax 222717)
> >
> > [log in to unmask] <mailto:[log in to unmask]>
> http://www.fmrib.ox.ac.uk/~steve <http://www.fmrib.ox.ac.uk/%7Esteve>
> >
> >
> ---------------------------------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
>
> >
>
> >
> > --
> >
> :::::::::::::::::::::::::::::::::::::::::::::::::::
> >
> Stephane Jacobs
> >
>
> >
> Postdoctoral Research Associate
> >
> Human Neuroimaging and Transcranial Stimulation Lab
> >
> Department of Psychology
> >
> 1227 University of Oregon
> >
> Eugene, OR 97403 - USA
> >
>
> >
> Email: [log in to unmask] <mailto:[log in to unmask]>
> >
> Tel: (1) 541-346-4184
> >
> :::::::::::::::::::::::::::::::::::::::::::::::::::
> >
>
> >
> >
>
>
>
--
:::::::::::::::::::::::::::::::::::::::::::::::::::
Stephane Jacobs
Postdoctoral Research Associate
Human Neuroimaging and Transcranial Stimulation Lab
Department of Psychology
1227 University of Oregon
Eugene, OR 97403 - USA
Email: [log in to unmask]
Tel: (1) 541-346-4184
:::::::::::::::::::::::::::::::::::::::::::::::::::
|