It might be ok to do it the way that you suggest. If you have an event that does not have many presentations, then it will be susceptible to noise. If you then average that with other events that have many presentations, then the average will be contaminated and it will be better to combine them in the paradigm file. If the number of presentations is balanced, then combining them in the contrast is probably ok. If you do this, when you look at the output of roisummary-sess you should average the values together before judging whether they are high or low. doug
Finnegan Calabro wrote:
I'll try that… we created a lot of events with the intention of just having a couple contrasts that combine many events together (e.g., to compare events 1-10 vs 11-21 in one contrast, and 1-5/11-15 vs 6-10/16-21 in another, and so on). So the contrasts that do this do have lots of significant regions, but we haven't actually tried looking at the individual events vs null (though I suspect you're right that they won't have much that's significant).
But maybe this isn't an ideal way of doing the analysis, and it'd be better to either (1) have fewer events and just use different analyses (with a different trial-to-event mapping for each) for each contrast, or (2) compute % signal change based on the contrast rather than the event (though I'm not sure if there's a nice way to do this other than loading ces.nii and h-offset.nii in matlab and masking them by the roi?).
On Mar 8, 2012, at 3:04 PM, Douglas N Greve wrote:
The only thing that I can think of is that the data are really noisy and you're just getting a really big spread. I computed the efficiency of condition 18, and it was pretty low. The variance reduction factor was actually less than 1, meaning that you are actually amplifying the noise in your design. This is probably a side effect of having 21 conditions. To debug this further, try reducing the number of conditions (maybe just to 1 or 2) and see if the extreme values go away. Do you actually see any significance in the maps of 18 vs fixation? doug
Finnegan Calabro wrote:
Here it is, thanks again.
On Mar 8, 2012, at 2:39 PM, Douglas N Greve wrote:
Nothing comes to mind. Can you send me the X.mat file in the analysis dir?
Finnegan Calabro wrote:
Thanks Doug. Looking at the beta.nii.gz values in the mask (assuming the first N entries in beta correspond to the N events, with nuisance variables after that), the values for event 18 (which had a particularly high % signal change) look like:
4.3453 21.4786 16.6500 8.1440 31.4507 5.0272 15.9165 36.8251 7.9907 20.7835 14.6263 18.0771 19.3031 9.8763 5.2008 9.1234 21.6566 22.7819 27.9337 22.8663 22.2126
So it doesn't seem to be one (or a small number) of voxels skewing the data. I don't think we're landing in the ventricles either, in part because this is happening to all of the 7 ROIs we've defined all over the cortex. We also looked at cespct.nii.gz and see lots of pretty high values in there as well (though that's for a contrast, not an event, and I'm not sure whether those values should necessarily match).
Can you think of anything else we should check that could be causing this? (it was a pretty standard analysis design i think, but could something wrong at that stage have produced results like this?).
Thanks very much!
On Mar 8, 2012, at 11:58 AM, Douglas N Greve wrote:
Hi Finnegan, there's nothing there that looks wrong with your commands, but I agree that those values look too high. It is possible that some of the 12 voxels in the ROI is causing the problem. If you go into the subject's analysis dir, you'll see a mask there that corresponds to your ROI. You can load that in matlab, find the voxels in the mask, then load the beta.nii.gz and extract out the values from those voxels to see if something looks funny. Also, check to see whether any of the mask falls into ventricle. doug
Finnegan Calabro wrote:
> Hi all, we're using 5.1 to analyze some single subject, event-related functional data, and are getting some strangely high values for % signal change when using func2roi-sess and roisummary-sess. Here are the commands we're running: > > func2roi-sess -s LMV2012_N01_heading -roidef rhmed_singlevsdouble_1 -analysis glheadgen_analysis -labelfile /home/vmrao17/freesurfer/subjects/LMV2012_N01/label/rhmed_singlevsdouble_1.label -maskcontrast allvsoff -maskthresh 1.50 -masktail pos -maskmap sig > > roisummary-sess -sumfile /home/vmrao17/tmp/summary.txt -roidef rhmed_singlevsdouble_1 -analysis glheadgen_analysis -s LMV2012_N01_heading > > > And this is the output of summary.txt: > > LMV2012_N01_heading 51 > 12 > 123.737160 > 1.535988 > 1572.000000 > 0.050000 > -0.000000 > 21 > 1 > 0.734151 > 3.595402 > 4.435675 > 5.482294 > 0.544176 > -0.166144 > 2.951724 > 2.114511 > 3.178010 > 2.814232 > 0.944738 > 0.466052 > 8.508595 > 7.646451 > 6.767788 > 9.197896 > 8.802674 > 11.339759 > 7.822568 > 4.040024 > 8.018742 > > The problem is that the effect size values seem very high and/or the baseline seems very low (e.g., 100*11.33/123.7=9%!). > > In 4.5 we were computing a scaling factor for these values, but my understanding was that in 5.1 that was no longer needed, correct? Is there anything else we should be doing differently when computing % signal change from this output now? The only other strange thing I notice is that the TER value is 0.05, but documentation describes TR/20 and our TR=2sec, which would seem to suggest it should be 0.1 instead of 0.05? > > I'm attaching the full output log for the two commands above as well. Anything that we're obviously doing wrong? Thanks! > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >
>
Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: www.nmr.mgh.harvard.edu/facility/filedrop/index.html