OK, well at least it's nice to know I'm not going crazy looking at the
probability maps. Could what you're seeing be due to preprocessing (i.e.
spatial blur and masking before running melodic) or is it almost certainly
motion-related? Or do you mean something else by "spiking"?
On Monday, October 10, 2011 15:06:23 you wrote:
> Nope, that looks like something is wrong - I suggest you load the data into
> fslview and start looking at some of the time series (or look at a movie
> loop of your data). I've only seen such histograms where data was heavily
> corrupted by spiking effects. feel free to upload if you want us to double
> check... hth
> Christian
>
> On 10 Oct 2011, at 13:40, Benjamin Kay wrote:
> > Ah, there it is! Don't I feel rather foolish now (^_^')
> >
> > The center of the histogram is close to zero and the peak is farily
> > narrow. Does the attached image look typical to you?
> >
> > Means : -0.000000 85.754878 -53.936238
> > Vars : 1.000000 2774.603215 2125.397460
> > Prop. : 0.561720 0.204818 0.233461
> >
> > On Monday, October 10, 2011 02:00:47 you wrote:
> >> Yes, you can:
> >> click on the tresholded image - that should bring you to a second page -
> >> then scroll down to see the GGMM fit.
> >> Cheers,
> >> Andreas
> >>
> >> Am 10.10.11 00:35 schrieb "Benjamin Kay" unter <[log in to unmask]>:
> >>> I'm sorry -- I still don't follow what you mean by the "histogram
> >>> fits". Is
> >>> this a GUI feature? I ran melodic from the command line. Is there
> >>> somewhere I
> >>> can find this plot in the HTML report?
> >>>
> >>> On Sunday, October 09, 2011 18:16:10 you wrote:
> >>>> Hi,
> >>>>
> >>>> In the first instance simply look at the histogram fits (click on the
> >>>> thresholded maps and then scroll to the bottom). The main Gaussian
> >>>>
> >>>> should
> >>>>
> >>>> be centred at zero and have unit standard deviation. If you happen to
> >>>>
> >>>> have
> >>>>
> >>>> really unusual data then the mixture model might not work, though -
> >>>> feel free to upload your filtered_func data and we'll have a look hth
> >>>> Christian
> >>>>
> >>>> On 6 Oct 2011, at 20:59, Benjamin Kay wrote:
> >>>>> On Thursday, October 06, 2011 14:29:41 you wrote:
> >>>>>> Hi - why do you think the values in melodic_IC are too high? These
> >>>>>> should be valid Z values and are probably what you want to be
> >>>>>> working with.
> >>>>>
> >>>>> Thank you for responding! In the melodic practical, the example uses
> >>>>> fslview to look at melodic_IC with "-b 5,10", so I had expected my
> >>>>> z-values to be somewhere in this range. Instead I have a great many
> >>>>> z-values greater than 50. To see my component clearly I have to use
> >>>>
> >>>> "-b
> >>>>
> >>>>> 150,300". (When looking at melodic_oIC, I can see clean-looking
> >>>>> components with "-b 0.3,1".) My probability maps light up pretty much
> >>>>> the entire brain, even with "-b 0,0.99", when melodic is run with the
> >>>>> default --mmthresh=0.5.
> >>>>>
> >>>>>> The
> >>>>>> thing to check is that the central Gaussian (null part of the
> >>>>
> >>>> histogram)
> >>>>
> >>>>>> is of standard devation 1. I'll be surprised if this is wrong -
> >>>>
> >>>> you're
> >>>>
> >>>>>> just not used to seeing strong signal (the tail) relative to such a
> >>>>>> cleaned-up null (because the structured noise is moved into the
> >>>>>> other components and not appearing in the null).
> >>>>>
> >>>>> I'm sorry, but could you please explain how I can check this?
> >>>>>
> >>>>>> Cheers.
> >>>>>>
> >>>>>> On 6 Oct 2011, at 14:58, Benjamin Kay wrote:
> >>>>>>> Bump! If you know how melodic_IC is derived from melodic_oIC,
> >>>>>>> please share! I'm having trouble with a dataset where the z-values
> >>>>>>> in melodic_IC are way too high. Knowing what's supposed to happen
> >>>>
> >>>> would be
> >>>>
> >>>>>>> very helpful to me in my efforts to debug this.
> >>>>>>>
> >>>>>>> On Wednesday, September 28, 2011 12:21:38 you wrote:
> >>>>>>>> It's been mentioned before that melodic_oIC contains the "raw" IC
> >>>>>>>> maps, that melodic_IC contains the Z-scaled IC maps, and that
> >>>>>>>> Noise_stddev_inv is used to convert the former to the latter. I'm
> >>>>>>>> curious as to precisely how this conversion is achieved. That is,
> >>>>>>>> given melodic_oIC, how do I get melodic_IC? The IEEE TMI paper
> >>>>
> >>>> seems
> >>>>
> >>>>>>>> to suggest it is a simple matter of doing voxel-wise division of
> >>>>
> >>>> each
> >>>>
> >>>>>>>> raw IC map by the standard deviation of the noise (technically the
> >>>>
> >>>>>>>> square root of the estimate of the noise variance), so:
> >>>> http://www.fmrib.ox.ac.uk/analysis/techrep/tr02cb1/tr02cb1/node8.html
> >>>>
> >>>>>>>> fslmaths melodic_oIC -mul Noise_stddev_inv my_melodic_IC
> >>>>>>>>
> >>>>>>>> But this doesn't seem to work. Indeed, lines 519-548 of meldata.cc
> >>>>>>>> would suggest something more is happening. Can anyone explain how
> >>>>
> >>>> to
> >>>>
> >>>>>>>> get melodic_IC from melodic_oIC using fslmaths?
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>> --
> >>>>
> >>>>>> --- Stephen M. Smith, Professor of Biomedical Engineering
> >>>>>> Associate Director, Oxford University FMRIB Centre
> >>>>>>
> >>>>>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
> >>>>>> +44 (0) 1865 222726 (fax 222717)
> >>>>>> [log in to unmask] http://www.fmrib.ox.ac.uk/~steve
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>> --
> >>>>
> >>>>>> ---
> >
> > <IC_19_MMfit.png>
|
