[Neuroimaging] [dipy]Fitting diffusion models in the absence of S0 signal

[Ariel Rokem]

Hi Rafael,

On Thu, Mar 24, 2016 at 4:12 AM, Rafael Henriques <rafaelnh21 at gmail.com>
wrote:

> Hi Eleftherios,
>
> What can we do if the data don't have b0s?
> In the last years, everyone was including the b0 data in their DWI
> acquisitions. However, nowadays some groups are starting to acquire
> diffusion volume of images with low b-values (e.g. 300 s.mm-2) instead
> of the b0 volumes. They are doing this to insure that when fitting
> diffusion models they do not take into account Perfusion confounding
> effects. So my question is - what can we do to generalize Dipy for
> these cases? My suggestion is to include S0 always as model parameter,
> so even if users do not have b0 data, the model can easily give the
> extrapolated non-perfusion effected S0 signal.
>

My example code was not really that great to demonstrate this point. I have
now updated the notebook so that it works with data that has a b=0
measurement,  but also with data that doesn't (you'll need to change the
commented out line in cell 3 to see both options).

I also have two alternative implementations, following Eleftherios'
suggestions (I think):

https://gist.github.com/arokem/508dc1b22bdbd0bdd748

In one implementation an estimate of S0 (`S0_hat`) is part of the TensorFit
object (I think that's what Eleftherios is suggesting). In the other
implementation, the estimate is part of the TensorModel.fit function (as
you suggest).

The main disadvantage of alternative 1 is that we would have to pass the
data again into a method of the `TensorFit` object. The main disadvantage
of alternative 2 is that it requires a change to the `TensorFit.__init__`
API. My own tendency is to prefer this change to the `TensorFit.__init__`
API, because I don't think that people are using that API on its own, but
are typically getting their `TensorFit` objects from the `TensorModel.fit`
function.

I think that passing the data in again into the `TensorFit` object will not
only be error-prone, but is also not as efficient.

Importantly, this is not just a matter for people who use the prediction
API to see that the model fits the data, but also an issue for fitting
models that depend on the DTI model, such as the new FWE DTI model.

Cheers,

Ariel




> Also, how can you recover the S0 information using the line that you
> are suggested? If params only have the diffusion tensor information,
> that line will always be equal to 1, right? Am I missing something
> here?

Best,
> Rafael
>
>
> > Hi Ariel,
> >
> > Apologies for delaying to answer.
> >
> > What I understand is that now the fit_model is doing the prediction for
> the
> > S0. Am I correct?
> > You recreate a predicted S0 inside fit_model but fit_model is about
> fitting
> > and not about predicting.
> >
> > I am not comfortable to changing fit_model to generate two parameters
> > (params and S0).
> >
> > This command can be called inside the predict method
> > S0 = np.mean(np.exp(np.dot(dm, params))[..., gtab.b0s_mask])
> >
> > So, for me there is no reason of changing the init method of TensorFit.
> >
> > I hope I am not missing something.
> > Let me know if this suggestion is helpful.
> >
> > Cheers,
> > Eleftherios
> >
> > On Sun, Mar 20, 2016 at 12:04 PM, Ariel Rokem <arokem at gmail.com>
> wrote:
> >
> >> Hi everyone,
> >>
> >> Thought I would re-raise this. Anyone have any thoughts here? Would a PR
> >> against the DTI and DKI modules be more helpful to clarify?
> >>
> >> Cheers,
> >>
> >> Ariel
> >>
> >> On Sat, Mar 5, 2016 at 3:04 AM, Ariel Rokem <arokem at gmail.com>
> wrote:
> >>
> >>>
> >>> On Thu, Mar 3, 2016 at 7:28 AM, Eleftherios Garyfallidis <
> >>> garyfallidis at gmail.com> wrote:
> >>>
> >>>> Sorry your suggestion is not exactly clear. Can you give show us how
> the
> >>>> code will look with your proposal? Also, apart from DTI and DKI what
> other
> >>>> models will be affected from this changes. Is this a change suggested
> only
> >>>> for DTI and DKI or will affect all or most reconstruction models?
> >>>>
> >>>>
> >>> First of all, to answer your last question: this will certainly affect
> >>> DTI and DKI, and there will be other models to follow. For example the
> >>> FWDTI that Rafael is currently proposing in that PR. The idea would be
> to
> >>> also more tightly integrate these three models (and future
> extensions...
> >>> !), so that we can remove some of the redundancies that currently
> exist. We
> >>> could make this a part of the base.Reconst* methods - it might apply to
> >>> other models as well (e.g. CSD, SFM, etc). But that's part of what I
> would
> >>> like to discuss here.
> >>>
> >>> As for code, for now, here's a sketch of what this would look like for
> >>> the tensor model:
> >>>
> >>> https://gist.github.com/arokem/508dc1b22bdbd0bdd748
> >>>
> >>> Note that though it changes the prediction API a bit, not much else
> would
> >>> have to change. In particular, all the code that relies on there being
> 12
> >>> model parameters will still be intact, because S0 doesn't go into the
> model
> >>> parameters.
> >>>
> >>> What do you think? Am I missing something big here? Or should I go
> ahead
> >>> and start working on a PR implementing this?
> >>>
> >>> Thanks!
> >>>
> >>> Ariel
> >>>
> >>>
> >>>
> >>>> On Mon, Feb 29, 2016 at 11:53 AM, Ariel Rokem <arokem at gmail.com>
> wrote:
> >>>>
> >>>>> Hi everyone,
> >>>>>
> >>>>> In Rafael's recent PR implementing free-water-eliminated DTI (
> >>>>> https://github.com/nipy/dipy/pull/835), we had a little bit of a
> >>>>> discussion about the use of the non-diffusion weighted signal (S0).
> As
> >>>>> pointed out by Rafael, in the absence of an S0 in the measured data,
> for
> >>>>> some models, that can be derived from the model fit (
> >>>>> https://github.com/nipy/dipy/pull/835#issuecomment-183060855).
> >>>>>
> >>>>> I think that we would like to support using data both with and
> without
> >>>>> S0. On the other hand, I don't think that we should treat the
> derived S0 as
> >>>>> a model parameter, because in some cases, we want to provide S0 as
> an input
> >>>>> (for example, when predicting back the signal for another
> measurement, with
> >>>>> a different ). In addition, it would be hard to incorporate that
> into the
> >>>>>  model_params variable of the TensorFit object, while maintaining
> backwards
> >>>>> compatibility of the TensorModel/TensorFit and derived classes
> (e.g., DKI).
> >>>>>
> >>>>> My proposal is to have an S0 property for ReconstFit objects. When
> this
> >>>>> is calculated from the model (e.g. in DTI), it gets set by the `fit`
> method
> >>>>> of the ReconstModel object. When it isn't, it can be set from the
> data.
> >>>>> Either way, it can be over-ridden by the user (e.g., for the purpose
> of
> >>>>> predicting on a new data-set). This might change the behavior of the
> >>>>> prediction code slightly, but maybe that is something we can live
> with?
> >>>>>
> >>>>> Happy to hear what everyone thinks, before we move ahead with this.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Ariel
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Neuroimaging mailing list
> >>>>> Neuroimaging at python.org
> >>>>> https://mail.python.org/mailman/listinfo/neuroimaging
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Neuroimaging mailing list
> >>>> Neuroimaging at python.org
> >>>> https://mail.python.org/mailman/listinfo/neuroimaging
> >>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> Neuroimaging mailing list
> >> Neuroimaging at python.org
> >> https://mail.python.org/mailman/listinfo/neuroimaging
> >>
> >>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20160325/df43c723/attachment.html>