Right - yes, sorry about that, I think what's happening is that each
subject's second-level analysis is creating a bg_image that just
reflects that subject's structural, and the third-level thinks it can
just use the first of the second-level analyses (rather than
averaging them all) - will fix that for the next version.
Obviously this just affects the rendering and not any stats etc - you
could run your own avwmerge across 2nd-level bg_image files, and then
re-create the stats overlay images if you wanted, using avwmerge,
avwmaths and overlay.
Cheers, Steve.
On 13 Mar 2007, at 00:07, Stephane Jacobs wrote:
> Hi Steve,
>
> Thanks, that's actually what I've been doing right now, I should have
> thought about it before asking to the list, sorry...
>
> Here is what I have for the 2nd level report.log, the 2nd level
> being a
> cross-session averaging within the same subject (here subj n. 187):
>
>> /usr/local/fsl/bin/avwmerge -t bg_image
>> /mri_data/187/analyzed_data/run1/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run1/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run2/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run2/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run3/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run3/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run4/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run4/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run5/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run5/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run6/reg_standard/reg/highres
>> /mri_data/187/analyzed_data/run6/reg_standard/reg/highres
>
> So it seems to be averaging across 12 copies of the same high_res,
> twice
> per run... I don't understand exactly why it's doing this, but so
> far, I
> know that my bg_image at the 2nd level is my subject high_res.
>
> At the 3rd level I have this:
>
>> /usr/local/fsl/bin/avwmerge -t bg_image
>> /mri_data/187/analyzed_data/187_cross_session_average.gfeat/
>> cope1.feat/example_func
>>
> example_func at the second level being created, I believe, when
> featregapply is run at the beginning of the 3rd level analysis. And
> it's
> a high_res, right?
>
> So it's actually taking the example_func from the first subject in the
> list, even though the Post Stats option for the background image
> was set
> to Mean Highres...
>
> Any idea what could have gone wrong, if anything?
>
> Thanks
>
> Stephane
>
>
> Steve Smith wrote:
>> Hi, check in the report.log file in both (2nd and 3rd) higher-level
>> .gfeat directories and find the avmerge command that creates the
>> bg_image file - this should tell you what images were fed into
>> bg_image.
>>
>> Cheers, Steve.
>>
>>
>>
>> On 12 Mar 2007, at 22:29, Stephane Jacobs wrote:
>>
>>> Hello everyone,
>>>
>>> I'd like to check what exactly is the example_func file within each
>>> copeX.feat directory output by higher level analyses. When
>>> searching the
>>> archives, I found that quote from Mark Woolrich:
>>>
>>> "In higher-level analyses example_func.* in the copeX.feat dirs
>>> is soft
>>> linked to bg_image.* in the gfeat dir. The bg_image.* is the
>>> background
>>> image specified by the user in the GUI for rendering purposes (goto
>>> Post-stats tab on the Feat GUI).
>>> By default it is the group mean structural brain warped into
>>> standard space.
>>> Other options are available."
>>>
>>>
>>> That's what I expected, however I'm a bit surprised by how good and
>>> clear my
>>> bg_image looks at the output of a 3rd level analysis averaging
>>> across 20
>>> subjects... The Post_Stats option in FEAT was indeed set to MEAN
>>> HIGHRES, as
>>> it is by default, but I wonder if there could be a way this file is
>>> not what
>>> it's supposed to be (e.g. an individual high-res...).
>>>
>>> I can definitely upload the file if necessary. Any comment would be
>>> greatly
>>> appreciated.
>>>
>>> All the 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
------------------------------------------------------------------------
---
|