Dear Bas, list

I don’t think there is any truly ‘neutral’ way of plotting event-related 
responses. An FIR model is just a model, after all. But there are a couple 
of ways that one can keep one’s plots consistent across plots within a 
study.

1. As spm_graph does, adjust for everything else in the design when 
plotting any event type e.g. A, B. This means that as Bas says the PSTH for 
each event type will depend on how well the response to the other/s was 
modelled, but it won’t depend on whether one is plotting A vs. B, or A vs. 
B & C, etc.

2. As Darren & I have done, and Rik previously with code for SPM99, allow 
for certain event types not to be adjusted for, and only adjust for events 
really ‘of no interest’ which one will never want to plot. Then plots for 
A, B & C will show the response for each event type independent of how well 
the others are modelled and also independent of whether one plots A vs. B 
or B vs. C. However this also means that if the FIR-modelled responses for 
say A & C are correlated the plots for A will include a component that 
could also be attributed to C and vice versa. This is perfectly valid but 
doesn’t reflect the way the multiple regression model works when all events 
are in it and is in a sense therefore further away from most inferences.

3. Perhaps the most consistent policy is simply to model all event types 
using FIR (or another general basis set) in the first place. It is then 
easier to extract betas for the FIR for any event type and these will be 
consistent across different choices of plots. This is easy in SPM2.

Using the 3rd approach, inference can also be based on an FIR so plots are 
consistent with inference. Rik & Will have implemented this method for an 
example dataset - see 
ftp://ftp.fil.ion.ucl.ac.uk/spm/data/rfx-multiple/rfx-multiple.htm. It also 
seems that as long as sampling is sufficient to give reasonably good 
estimates for each peristimulus time point for each event, inferences based 
on (e.g.) a canonical-HRF-shaped weighted contrast at the 2nd level will be 
more sensitive than those resulting from the more traditional method of 
taking up ‘canonical’ contrasts from the 1st level

I imagine however that as usual people will have different preferences! ;) 

By the way, I'm fairly sure spm_graph adjusts for parametric modulations 
for any event types other than the one being plotted, since it leaves the 
rest of the design matrix alone and just fits an FIR for one event type at 
a time

Alexa


On Oct 20 2004, Neggers, S.F.W. (Bas) wrote:

> Dear Darren, List,
> 
> thanks for the comments to your code. I ran an example using my own GUI, 
> and plotted the FIR design matrix X that is created at line 313. See 
> attached PDF. I scheduled two conditions for removal from the matrix 
> (your iX), and corrected for the remaining conditions, i.e. 'nuisance 
> events', 2 of which were parametrically modulated. They are visible in 
> the design matrxi X, see PDF (column 22 and 23 are the parametrically 
> modulated events). I plotted column 20-23 (hrf, dhrf/dt, and their 
> parametric counterparts) in a second panel. Therefore, I would say the 
> code does adjust for parametrically modulated events, only not for the 
> events of interest. But perhaps we talked about different things ...
> 
> I have been digging through these lines well, and added a correction 
> options (in my original version, see attached), as you might have guessed 
> from the above. I allowed removal from the FIR+ model (not correct for) 
> more than just the conditions the PSTH is calculated for. I.e., when one 
> wants to compare PSTHs for condition A and B, one might want to remove A 
> and B from the FIR+ model. My idea behind that was that one might not 
> want the PSTH for condition A becoming dependent on how well B was 
> modelled. When correcting for B when creating the PSTH for A, this is the 
> case. A more 'neutral' way of looking at (possibly different) PSTHs for 
> condition A and B whould be to correct for neither of them. What's you 
> opinion about this idea?
> 
> When I find the time I am happy to implement the above additional 
> correction options and the "parametric histogram bin approach" I wrote 
> you about in the most recent get_psth.m function. I already did in the 
> older version, that I attached to this email. I'll notify you when I'm 
> ready with the new one.
> 
> Cheers,
> 
> Bas
> 
> -------------------------------------------- 	
> Dr. S.F.W. Neggers 
> dept. of Psychonomics,Helmholtz Institute 
> Utrecht University 
> Heidelberglaan 2 
> 3584 CS, Utrecht, room 17.09 
> the Netherlands 
> Tel: (+31) 30 253 4582 Fax: (+31) 30 2534511 
> E-mail: [log in to unmask] 
> Web: http://www.fss.uu.nl/psn/pionier 
> -------------------------------------------- 
> 
> 
> 
> -----Oorspronkelijk bericht-----
> Van: SPM (Statistical Parametric Mapping)
> [mailto:[log in to unmask]]Namens Darren Gitelman
> Verzonden: dinsdag 19 oktober 2004 18:41
> Aan: [log in to unmask]
> Onderwerp: Re: [SPM] PSTH once more: get_psth error
> 
> 
> At 03:46 AM 10/19/2004, Neggers, S.F.W.  \(Bas\) wrote:
> Dear Bas:
> 
> Regarding this issue:
> > Our sessions have the same conditions modelled, so that limitation is 
> > no problem. When I understand your code well, it does correct for 
> > events that are parametrically modulated, but cannot extract PSTHs for 
> > parametrically modulated events, or at least does not take into account 
> > the modulation?
> 
> No the code doesn't deal with removing effects from parametric events at 
> all. However, I see neither does spm_graph.
> 
> The way my code and (I believe spm_graph) works is that first you 
> identify an event-type. The first column of that event (in SPM.Sess.U.u) 
> is always the onsets (stimulus function) in microtime. Other columns, if 
> present, will represent parametric effects but these are ignored. The 
> first column column plus information such as the TR (bin size), the order 
> of the FIR set and the length are forwarded to spm_volterra to make the 
> FIR basis and then down-sampled to scan time (lines 240 ~ 260).
> 
> Assuming that you select to adjust for all effects except for the one you 
> are modeling. Line 277 then identifies the columns of the original design 
> matrix that should NOT be adjusted for.
>   iX          = SPM.Sess(ses).col(SPM.Sess(ses).Fc(ev).i);
> 
> So let's say you have a design with 3 events and no parametric effects 
> and you want to model event 1. Then iX will contain a 1, i.e., you don't 
> want to remove signal correlated with event 1 since that is what you are 
> modeling. However, now let's say you have 2 parametric effects on each of 
> your events then the example iX will contain [1 2 3]. (Similarly if you 
> have an HRF + TD then iX would contain [1 2] for event 1.
> 
> Line 301 identifies all the columns in your design as iX0. Then line 302 
> says remove the members of that vector that you DO NOT want to adjust 
> for. So in our example let's say we have 3 events, hrf only, no 
> parametric effects and a constant term. iX0 = [1 2 3 4] at line 301. Then 
> at line 302, iX0 = [2 3 4]; Similarly for our parametric events.
> 
> Line 309 then places the columns for the events you want to estimate in 
> front of the rest of the design for the events of no interest (i.e., 
> iX0). Thus, when you model a set of onsets the parametric effects for 
> those onsets are NOT even modelled in the design for graphing purposes.
> 
> The parametric effects and event onset vector were orthogonalized in 
> spm_get_ons when the design was specified, but that does leave the issue 
> that any signal correlated with the parametric effects ends up in the 
> residuals during graphing. I guess since one isn't estimating statistics 
> at this point it may not matter.
> 
> As to your last question:
> > What I tried (because I use parametric events) was to construct a 
> > histogram for the parametric factors disctribution, divide the events 
> > in N (3 or 4 worked well for me) groups according to (wide) time bins, 
> > and then extract PSTHs for these groups separately. That way one can 
> > plot the PSTHs for each group, and see the amplitude of evoked 
> > responses change from group to group. I could implement this in 
> > get_psth.m when I find the time. Do you think that is a good idea?
> 
> I'm not sure I'm qualified to comment on this in any formal way, but it 
> seems reasonable to me. I guess you get a kind of contrast estimates plot 
> with broad groups of the parametric effect (averages) on the abscissa and 
> the corresponding parameter estimate for each group on the ordinate. Yes 
> if you can add it that would be great.
> 
> Cheers,
> Darren
> 
> >Dear Darren,
> >
> >Thanks for the comments.
> >
> >I used the version from may 2004, the last line of the comments say:
> >
> >% $Id: get_psth.m 1.2 2004-06-30 23:45:02-5 drg Exp drg $
> >
> > I do not remember anymore whether I got your function from your website 
> > or somewhere else, perhaps the version was altered.
> >
> > It indeed looks quite different around the lines where I found an 
> > error, I can't explain that either.
> >
> > I'll try marsbar as well. I do like to have a sole function (no GUI 
> > elements) for PSTH extraction though, it is easier to use in our own 
> > automated scripts than a whole GUI like the marsbar. That's why I 
> > started using your code, and also to educate myself regarding the 
> > details of PSTH calculations using FIR estimates. I'll have a look at 
> > Marsbar though, perhaps it has some nice functions too.
> >
> > Our sessions have the same conditions modelled, so that limitation is 
> > no problem. When I understand your code well, it does correct for 
> > events that are parametrically modulated, but cannot extract PSTHs for 
> > parametrically modulated events, or at least does not take into account 
> > the modulation?
> >
> > What I tried (because I use parametric events) was to construct a 
> > histogram for the parametric factors disctribution, divide the events 
> > in N (3 or 4 worked well for me) groups according to (wide) time bins, 
> > and then extract PSTHs for these groups separately. That way one can 
> > plot the PSTHs for each group, and see the amplitude of evoked 
> > responses change from group to group. I could implement this in 
> > get_psth.m when I find the time. Do you think that is a good idea?
> >
> >Cheers,
> >
> >Bas
> >
> >
> >-----Original Message-----
> >From: SPM (Statistical Parametric Mapping) on behalf of Darren Gitelman
> >Sent: Tue 10/19/2004 07:57
> >To: [log in to unmask]
> >Cc:
> >Subject: Re: [SPM] PSTH once more: get_psth error
> >
> >Dear Bas:
> >
> > Thanks for the vote of support. I'm glad you're using the function, but 
> > I don't recognize the code below at all. The get_psth function changed 
> > quite a bit since its first incarnation. What version are you using? 
> > 0.1? The version is now 1.11.
> >
> > I don't know if this is an issue but the get_psth code will not deal 
> > with either parametric events, or sessions if the events types are not 
> > the same in each session. Sorry I can't be of more help about this. You 
> > might see if the newest version does what you want. If the newest 
> > version also bails out then I can probably be of more help.
> >
> >Also, a plug for Matthew Brett's program marsbar- it really is vastly
> >superior and the ROI and other tools are outstanding.
> >
> >Cheers,
> >Darren
> >
> >At 09:11 AM 10/18/2004, Neggers, S.F.W. (Bas) wrote:
> > >Dear Darren and others,
> > >
> > > I have been succesfully using your function get_psth.m for a couple 
> > > of studies now, using single session design. Works great. I made some 
> > > minor (logistic) alterations and have also built a GUI around it 
> > > allowing one to select ROIs and even calculate average PSTHs for 
> > > selected events and models within these ROIs, and average over 
> > > subjects. I'll share it on my sourceforge page as soon as I think it 
> > > is ready and easy enough to use.
> > >
> > >
> > > Currently I am analysing a 2 session design, and I ran into an error. 
> > > The functions get_psth bails out at line 209 saying:
> > >
> > >----
> > >iu=find(SPM.Sess.U(events(n,n2)).u>0);
> > >??? Field reference for multiple structure elements that is followed by
> > >more reference blocks is an error.
> > >----
> > >
> > >I had a look at the code, and I think I have found the error. The code
> > >around line 209:
> > >
> > >202:    for m = 1:length(sessions)
> > >203:        ses = sessions(m);
> > >204:
> > >205:        xBF          = SPM.xBF;
> > >206:        U            = SPM.Sess(ses).U(ev(1));
> > >207:        % event vector in microtime, pool over columns in 'events'
> > >208:        for n2 = 1:size(events,2) %loop columns in 'events'
> > >209:            iu=find(SPM.Sess.U(events(n,n2)).u>0);
> > >210:            U.u(iu)=SPM.Sess.U(events(n,n2)).u(iu);
> > >211:        end
> > >
> > > I suspect that one has to specify the session (variable 'ses' in the 
> > > four loop) for which the 'find' function has to calculate the 
> > > indices. This present code works for 1 session, but for more session 
> > > the code tries to index a field directly at an array, which leads to 
> > > the error.
> > >
> > >I think that the correct code at line 209 should be:
> > >
> > >209:            iu=find(SPM.Sess(ses).U(events(n,n2)).u>0);
> > >210:            U.u(iu)=SPM.Sess(ses).U(events(n,n2)).u(iu);
> > >
> > > Could you indicate whether this is OK? Perhaps I am not understanding 
> > > the procedure well, and my patch leads to unwanted results.... The 
> > > code now executes fine and I obtain a matrix with 2 columns in 
> > > PSTH.events(..).psth, one column per session I think.
> > >
> > >Is this correct?
> > >
> > >Thank you in advance,
> > >
> > >Bas
> > >
> > >--------------------------------------------
> > >Dr. S.F.W. Neggers
> > >dept. of Psychonomics,Helmholtz Institute
> > >Utrecht University
> > >Heidelberglaan 2
> > >3584 CS, Utrecht, room 17.09
> > >the Netherlands
> > >Tel: (+31) 30 253 4582 Fax: (+31) 30 2534511
> > >E-mail: [log in to unmask]
> > >Web: http://www.fss.uu.nl/psn/pionier
> > >--------------------------------------------
> > >
> > >
> > >
> > >
> > >-----Oorspronkelijk bericht-----
> > >Van: SPM (Statistical Parametric Mapping)
> > >[mailto:[log in to unmask]]Namens Darren Gitelman
> > >Verzonden: donderdag 12 augustus 2004 18:57
> > >Aan: [log in to unmask]
> > >Onderwerp: Re: [SPM] FW: [SPM] refs on PSTH
> > >
> > >
> > >Alexa/List/Russ:
> > >
> > >Thank you for this information.
> > >
> > > Alexa, in relation to your question below my code allows the user to 
> > > choose whether to adjust for various columns in the design matrix- 
> > > essentially either for other sessions or for other events within the 
> > > same sessions. I added this because we were trying to compare our 
> > > results with results obtained from AFNI. To my understanding, which 
> > > is based on a discussion with an AFNI user and not my direct 
> > > first-hand experience, AFNI does not adjust for other events, but 
> > > this could be incorrect. Answering, yes to both the adjustment 
> > > questions will produce results as in SPM2 - spm_graph.
> > >
> > >Cheers,
> > >Darren
> > >
> > >
> > >At 11:28 AM 8/12/2004, Alexa Morcom wrote:
> > > >Hello list & Bas/ Russ
> > > >
> > > > It might be worth pointing out that although Russ's page is a good 
> > > > introduction to how these kinds of plots work, the PSTH plot works 
> > > > differently in SPM2 to SPM99, and it's the SPM99 method that Russ's 
> > > > page discusses. In SPM2, spm_graph fits an FIR model for the event 
> > > > of interest and it's this code that Darren & I have hacked.
> > > >
> > > >For more about the use of an FIR model to make inferences, see Rik 
> > Henson's
> > > > HBM 2001 abstract at 
> > > > http://www.fil.ion.ucl.ac.uk/~rhenson/refs.html. See also 
> > > > http://www.fil.ion.ucl.ac.uk/spm/data/ for Rik's sample datasets
> > which
> > > >include examples of the use of an FIR basis in the main model.
> > > >
> > > > Nobody's done anything formal to my knowledge on different ways of 
> > > > implementing code to make these FIR-PSTH plots, but the main 
> > > > decisions to make, as I undestand them, are a/ whether plots of 
> > > > more than one event
> > type
> > > > should deal with each separately and b/ whether one should adjust 
> > > > at the same time (or beforehand) for all other event types in the 
> > > > model.
> > These are
> > > >matters for individual choice but saying yes to a/ and b/ is to my 
> > mind the
> > > > most consistent with spm_graph, and should mean that PSTH plots 
> > > > don't vary according to whether event type A is plotted against B 
> > > > or against C. With non-orthogonal regressors there are various ways 
> > > > that these choices can affect the results. I believe that Darren's 
> > > > program implements a choice about b/, but Darren please correct me 
> > > > if I'm wrong.
> > > >
> > > >I hope this helps!
> > > >
> > > >Alexa
> > > >
> > > >
> > > >
> > > >| -----Original Message----- From: SPM (Statistical Parametric 
> > > >| Mapping) [mailto:[log in to unmask]]On Behalf Of Russ Poldrack 
> > > >| Sent: 03 August 2004 16:25 To: [log in to unmask] Subject: Re: 
> > > >| [SPM] refs on PSTH
> > > >|
> > > >|
> > > >| you can find a little more information here:
> > > >|
> > > >|  
> > > >|  
> > > >| http://sourceforge.net/docman/display_doc.php?docid=6217&group_id=13529
> > > >|
> > > >| the code in my roi toolbox (available at the same web site) 
> > > >| implements this kind of PSTH averaging based on an FIR model.
> > > >|
> > > >| cheers
> > > >| russ
> > > >|
> > > >| On Aug 3, 2004, at 8:20 AM, Neggers, S.F.W. (Bas) wrote:
> > > >|
> > > >| > Dear SPMers,
> > > >| >
> > > >| > I'd like to read a little bit more about the theory behind 
> > > >| > extracting a PSTH from your data based on the estimates of a 
> > > >| > simple FIR model. I read through the code in spm_graph.m and 
> > > >| > get_psth.m from Darren, and I think I get the basic idea, but 
> > > >| > that's just not enough. Is there a more formal description of 
> > > >| > the PSTH approach followed in SPM, perhaps in the form of a 
> > > >| > paper doing some kind of validation?
> > > >| >
> > > >| > I plan to implement get_psth in an activation cluster based PSTH
> > > >| > extractor, and really exactly like to know what I'm doing here.
> > > >| >
> > > >| > Kind regards,
> > > >| >
> > > >| > Bas
> > > >| >
> > > >| >
> > > >| > --------------------------------------------
> > > >| > Dr. S.F.W. Neggers
> > > >| > dept. of Psychonomics,Helmholtz Institute
> > > >| > Utrecht University
> > > >| > Heidelberglaan 2
> > > >| > 3584 CS, Utrecht, room 17.09
> > > >| > the Netherlands
> > > >| > Tel: (+31) 30 253 4582 Fax: (+31) 30 2534511
> > > >| > E-mail: [log in to unmask]
> > > >| > Web: http://www.fss.uu.nl/psn/pionier
> > > >| > --------------------------------------------
> > > >| >
> > > >| >
> > > >| ---
> > > >| Russell A. Poldrack, Ph.D.
> > > >| Assistant Professor of Psychology, UCLA
> > > >| Franz  Hall, Box 951563
> > > >| Los Angeles, CA 90095-1563
> > > >| email: [log in to unmask]
> > > >| phone: 310.794.1224
> > > >| fax: 310.206.5895
> > > >| web: http://www.poldracklab.org/
> > > >|
> > >
> > >
> > >  
> > > ------------------------------------------------------------------------- 
> > > Darren R. Gitelman, M.D. Cognitive Neurology and Alzheimer¹s Disease 
> > > Center Northwestern Univ., 320 E. Superior St., Searle 11-470, 
> > > Chicago, IL 60611 Voice: (312) 908-9023 Fax: (312) 908-8789 
> > > -------------------------------------------------------------------------
> >
> >
> >-------------------------------------------------------------------------
> >Darren R. Gitelman, M.D.
> >Cognitive Neurology and Alzheimer¹s Disease Center
> >Northwestern Univ., 320 E. Superior St., Searle 11-470, Chicago, IL 60611
> >Voice:   (312) 908-9023     Fax:  (312) 908-8789
> >-------------------------------------------------------------------------
> >
> >
> 
> 
> -------------------------------------------------------------------------
> Darren R. Gitelman, M.D.
> Cognitive Neurology and Alzheimer¹s Disease Center
> Northwestern Univ., 320 E. Superior St., Searle 11-470, Chicago, IL 60611
> Voice:   (312) 908-9023     Fax:  (312) 908-8789
> ------------------------------------------------------------------------- 
>