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]> 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] http://www.fmrib.ox.ac.uk/~steve
>>>>>> ---------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------------
>>>>
>>>> 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] http://www.fmrib.ox.ac.uk/~steve
>>>> ---------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------------
>> 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] http://www.fmrib.ox.ac.uk/~steve
>> ---------------------------------------------------------------------------
>>
>


---------------------------------------------------------------------------
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] http://www.fmrib.ox.ac.uk/~steve
---------------------------------------------------------------------------