mwaskom / moss Goto Github PK

This will let us drop the nipy image stuff (I think). See http://nipy.org/nibabel/image_orientation.html

I am getting an "ValueError: operands could not be broadcast together with shapes (64,64,30) (64,30,64) " error when using Mosaic:

m = Mosaic(orig,mask,mask, step = 1)

What's strange is that

print nib.load(orig).shape
print nib.load(mask).shape

returns (64,64,30) for both.

And

m = Mosaic(orig,mask, step = 1)

works fine.

This issue is coming up in the report for the functional mask step of the lyman preproc workflow.

To speed things like iterated deconvolution up

Hi Michael,

I was playing around the with DesignMatrix class and I am a little confused by the HRFs. They don't come out looking quite like the canonical HRF. It looks like perhaps the code is not adjusting for different TRs, although I am having trouble tracking down the source of the issue:

from moss import glm
import pandas as pd
import seaborn as sns
%matplotlib inline

design = pd.DataFrame({'condition':['test'],
'onset': [0],
'duration': [2],
})

#convolve
hrf = glm.GammaDifferenceHRF()
model = glm.DesignMatrix(design = design, tr = 1.0, ntp = 14,
hrf_model = hrf, hpf_cutoff = 128)
sns.tsplot(model.design_matrix.values.flatten())

Could save a lot of code for finding the tight field of view.

The bunch module has been dead for a while now, and a fork of it called munch is actively developed. Please consider replacing usage of bunch with munch.

@mwaskom I just discovered this. I was thinking for quite some time about doing something similar to prevent myself from copying my utils manually from project to project...
How would you feel about contributions mostly related to visualization, stats and dealing with reaction time data and a few MEG specific utils.

This will let us drop a dependency on statsmodels.

I think it just means looking at percentiles? We don't use the ECDF object for anything more complicated.

small issue with default parameter values (I think this is unexpected behavior). The FIR class sets oversampling = 1, but if you don't set oversampling = 1 in the DesignMatrix call, then the frame times get messed up and FIR convolution doesn't work as expected. Because the default value is 16 in DesignMatrix, the FIR convolution doesn't work unless without this parameter set properly.

It would be good to have ~30 seconds of eyelink data with a few known saccades and blinks for testing the moss.eyelink module.

Hi Michael,

I might be wrong, but it looks like you don't orthogonalize the temporal derivative regressors relative to the main events. It looks like both SPM and FSL do this, and it results in more accurate beta estimates in simulations:

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3896880/

-Ian

Here are some issues I have run into and want to think more about:

• Downsampled timeseries are shifted with respect to the hires timeseries. This is because the downsampling also shifts the predicted response forward to correspond to the middle of the TR. This makes some sense but also might be surprising. I want to rethink whether this should be done and whether it is being done in the most obvious way. Further, need to think about this in the context of an FIR model.

• Should the default oversampling over the design matrix/hrf kernel be changed? It inherited 16x oversampling from FSL but that means it is hard to specify very short events with a given duration. I think it might make sense to change the parameterization to give a hires time bin (not relative to TR) and make the default 60 to correspond to the refresh rate of a typical monitor. Stimulus events will generally be limited by that resolution.

• Needing to give the HRF functions a hires stimulus to get a simple predicted response is confusing outside of the context of a DesignMatrix.

• A DesignMatrix with high-pass filtering but demean=False will have a zero mean because the filter removes a constant trend. This is confusing. Do we want to add the column means back in after filtering and then allow the presence of a constant trend be determined by demean?

I've got a class hanging around that I can easily refactor into function compatible with the existing bootstrap and ci functions. Got tests too.

Happy to submit a PR to include it.

Ref: http://staff.ustc.edu.cn/~zwp/teach/Stat-Comp/Efron_Bootstrap_CIs.pdf

Hi Michael,

I was wondering whether mosaic would allow plotting one image only, not in an overlay setting, yet with the ability to control the color range etc.

I was playing around a bit, but could not get it to what I wanted.

Second request: is there a possibility to switch from neurological to radiological convention?

Thanks!
Maarten