Dear, Bas, Alexa, List:
At 08:05 AM 10/20/2004, you 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 ...
Yes exactly. The code does model parametric effects based on events of no
interest because it uses that part of the design matrix. My comments only
referred to when one has an event of interest and there are also parametric
effects tied to that event. Then the code does not deal with those
parametric effects (nor does spm_graph)
>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?
I agree with Alexa's comments about this issue.
>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.
thanks,
Darren
>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
>-------------------------------------------------------------------------
>
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
|
