<div dir="ltr"><div><div></div>Thanks for your responses, that's helped clarify a lot of points!<br><br></div>David<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 21 January 2014 11:15, Brian Murphy <span dir="ltr"><<a href="mailto:brian.murphy@qub.ac.uk" target="_blank">brian.murphy@qub.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello David,<br>
<br>
you have a few options. You can aim to get a single aggregate volume for<br>
each trial, by a) assuming a standard HRF corresponds well to the<br>
responses seen in your data, and use that to do a weighted average of<br>
your trial volumes (NiPy has a built in HRF); or b) do a simple block<br>
average as you suggest (e.g. taking an offset of 2 TRs, and block<br>
averaging the following couple).<br>
<br>
You could also do either of those things with a cross-validated<br>
parameter setting step (to decide on the optimal offset and block<br>
length, or HRF parameters) - keeping in mind that the HRF can vary by<br>
individual participant, task and brain area (the 'standard' HRFs are<br>
based on low level visual cortex responding to flashes of light).<br>
<br>
If your main interest is getting good classification results, you could<br>
also throw in all the volumes together (each trial would be comprised by<br>
V voxels x T TRs), and let the machine learning methods decide which<br>
volumes (or weighting thereof) are the ones it wants to listen too. The<br>
advantage there is that there you make no assumptions at all about the<br>
timing and shape of the response, and you don't assume a uniform<br>
response across people/locations/tasks. With that approach you'll need a<br>
classifier that works well with large numbers of co-linear dimensions -<br>
e.g. PLR or Random Forests.<br>
<br>
We wrote a paper covering some of that ground which you can look at for<br>
background:<br>
<a href="http://www.frontiersin.org/Journal/10.3389/fninf.2012.00024/abstract" target="_blank">http://www.frontiersin.org/Journal/10.3389/fninf.2012.00024/abstract</a><br>
... and I can dig out the associated code if that is helpful,<br>
<br>
best of luck,<br>
<br>
Brian<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, 2014-01-20 at 09:55 +0000, David Watson wrote:<br>
> Dear All,<br>
><br>
> I was wondering if anyone could give me some advice on how best to<br>
> account for the haemodynamic lag of the BOLD signal when performing a<br>
> pattern analysis on 4D fMRI data?  This seems like a fairly basic<br>
> issue, but I am struggling to find a clear answer on how best to deal<br>
> with it. I have spent some time reading around (e.g. this page from<br>
> the Princeton toolbox was quite informative:<br>
> <a href="http://code.google.com/p/princeton-mvpa-toolbox/wiki/HowtosRegressors#How_can_I_take_the_haemodynamic_lag_into_account" target="_blank">http://code.google.com/p/princeton-mvpa-toolbox/wiki/HowtosRegressors#How_can_I_take_the_haemodynamic_lag_into_account</a>) and I get the impression that there are two main ways that people tend to do this:<br>

><br>
> 1. Offset the timeseries or the sample labels by a suitable number of<br>
> TRs. For instance, my TR is 3 seconds, and the lag is estimated to be<br>
> approximately 6 seconds for most subjects, so I could either remove<br>
> the first 2 TRs of the timeseries, or increment my sample labels along<br>
> 2 time points. I could easily enough do this myself within python once<br>
> I've loaded in my sample attributes and dataset, although maybe PyMVPA<br>
> already has some built in support for this function that I have<br>
> missed. But I am a little concerned as to how accurate this is likely<br>
> to be, e.g. the lag is unlikely to be precisely 6 seconds in all<br>
> subjects.<br>
><br>
> 2. Convolve my model regressors with an HRF. This option seems like it<br>
> might be preferable, and I can easily enough derive a gamma HRF (e.g.<br>
> the nitime package seems to provide one), but I'm not sure how I would<br>
> then apply this to a given model within PyMVPA. Or does PyMVPA already<br>
> provide some functionality to let me do this?<br>
><br>
> As it happens I have a block design so perhaps I could get away with<br>
> just offsetting the timeseries, although convolving an HRF might still<br>
> be preferable. But if I ever wanted to do an event-related design<br>
> where measuring timings precisely is more important then I'm not sure<br>
> if simply offsetting the timeseries would still be considered<br>
> acceptable. Also, are there any other commonly used methods of<br>
> accounting for the lag that I have missed?<br>
><br>
><br>
> Regards,<br>
><br>
> David<br>
><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Dr. Brian Murphy<br>
Lecturer (Assistant Professor)<br>
Knowledge & Data Engineering (EEECS)<br>
Queen's University Belfast<br>
<a href="mailto:brian.murphy@qub.ac.uk">brian.murphy@qub.ac.uk</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Pkg-ExpPsy-PyMVPA mailing list<br>
<a href="mailto:Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org">Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-exppsy-pymvpa" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-exppsy-pymvpa</a><br>
</div></div></blockquote></div><br></div>