That should work. I just made a slightly different modification to the code, which will be in 5.2
pmat = FTest(dof1, dof2, Fmat); ind = find(rvarmat == 0); pmat(ind) = 1; % in case all time points are same value ind = find(pmat == 0); pmat(ind) = eps(0); % for REALLY sig voxels fsigmat = -log10(pmat);
On 11/30/2012 11:25 AM, Caspar M. Schwiedrzik wrote:
Hi Doug and Sebastian, thanks for your input. I think I can confirm that it is the problem that Sebastian described. FS 5.1 uses betainc, which returns 0, even in Matlab R2011b. The workaround that Sebastian suggested works, with a slight modification. In line 888 in fast_selxavg3.m currently reads ind = find(pmat == 0); pmat(ind) = 1; That seems wrong to me, as -log10(1) gives 1. I replaced line 888 with ind = find(pmat == 0); pmat(ind) = eps(0); -log10(eps(0)) gives 323.3062. Sebastian's solution of pmat(ind) = eps underestimates the significance because eps is by default eps(1). Does that make sense?
I confirmed that the time courses indicate a highly significant difference; I have 27 runs of block design; the problem happens both for contrasts against baseline and for contrasts between conditions; I currently have this problem only in one subject.
Thanks, Caspar
2012/11/29 Sebastian Moeller sebastian.moeller1@rwth-aachen.de:
Hi Doug, hi Caspar,
which matlab version are you using? We had some issues in the past that some matlab 2007 and 2009 statistics toolbox versions returned p values of 0, which obviously will not work as overlay, since those typically assume a volume of: -log10(p_value) and on matlab 2007b (maci):
-log10(0.0)
ans = Inf
-log10(eps)
ans = 15.6536 So you should
So test your input stat volumes for 0.0 and try to replace those with eps in matlab and see how the overlay look then. Then try to teach fs-fast to do this automagically :) For saity checking have a look at the time course at those voxels (I assume NHP block design data here), and remember if you can see the modulation in the time courses with your bare eyes it will most likely be significant. So at those voxels where the contrasts return zero I would expect really great time courses with strong differences in modulation hiught between the members of the -a and -c collections of contrast blocks.
best Sebastian
On Nov 29, 2012, at 09:55 , Douglas N Greve wrote:
Oh, I did not realize this was an fsfast issue, I thought you were using mri_glmfit. In that case, I'm not sure what could be causing the problem since the p-values are being computed by matlab. How many runs do you have? Is is a contrast that has a huge amount of power(eg, something vs fixation)? Does it happen in other subjects? One path to debugging is to run selxavg3-sess with -run-wise. This will create an analysis for each run separately. You can then see whether one run in particular is causing the problem. doug
On 11/27/2012 08:34 PM, Caspar M. Schwiedrzik wrote:
Hi Doug, I am afraid the p values are still too small in Free Surfer Linux-centos4_x86_64-stable-pub-v5.1.0-full. I redid mkanalysis-sess mkcontrast-sess selxavg3-sess in 5.1., it looks verz similar as in 4.5., including a whole of 0.0 in the center of the cluster. Any further advice? Thanks, Caspar
2012/11/26 Douglas Greve greve@nmr.mgh.harvard.edu:
No, it does not. With version 5 I went to a simple AR1 model instead. doug
On 11/26/12 10:34 PM, Caspar M. Schwiedrzik wrote:
Hi Doug, thanks for the input. What I meant is that in version 5.1, mkanalysis-sess does not seem to recognize the -taumax flag to set the maximum delay for the autocorrelation function. Caspar
2012/11/26 Douglas N Greve greve@nmr.mgh.harvard.edu: > On 11/26/2012 02:12 PM, Caspar M. Schwiedrzik wrote: >> Hi Doug, >> I'll do that. >> Two quick follow-up questions regarding 5.1: >> - it seems that I cannot specify taumax anymore in mkanalysis-sess. Is >> there another argument that would allow me to set the autocorrelation? > What do you mean by "set the autocorrelation"? You can turn it off with > -no-whiten. > >> - in a block design, would refeventduration be the block length or the >> length of the individual events within a block? > The block length. This will not change the p-values, only percent signal > change values (often not even looked at). > doug > >> Thanks, >> Caspar >> >> 2012/11/26 Douglas N Grevegreve@nmr.mgh.harvard.edu: >>> Hi Caspar, I think I fixed this in later versions. If you upgrade, you >>> can run the stats from 5.1 with recons from 4.5 (just don't mix recons >>> from different versions). >>> doug >>> >>> On 11/26/2012 01:15 PM, Caspar M. Schwiedrzik wrote: >>>> Hi! >>>> I ran into a funny problem when calculating contrasts in Freesurfer >>>> 4.5.0. >>>> Namely, the center of my cluster of significant voxels has a p-value >>>> of -0.0, resulting in a funny whole where you would otherwise expect >>>> to find the most significant voxel(s). >>>> It seems that the p-value is too small. Is there a workaround >>>> available? >>>> Thank you very much, >>>> Caspar >>>> _______________________________________________ >>>> 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 >>> Outgoing: >>> ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer@nmr.mgh.harvard.edu >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >>> 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 > Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ >
-- 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 Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Sebastian Moeller
telephone: +1-626-325-8598 /+1-626-395-6523 / +1-626-395-6616 fax: 626-395-8826 German GSM: +49 - 15 77 - 1 90 31 41 mobile: +1-626-325-8598 +1-626-807-5242 US CDMA: +1-626-807-5242 moeller@caltech.edu
Division of Biology MC 114-96 California Institute of Technology 1200 East California Boulevard CA 91125, Pasadena USA