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

Sat Apr 9 18:08:07 EDT 2016

Hi Rafael and Ariel,

Apologies for delaying to answer here. I think we need to set a hangout to
discuss about this.

One thing that maybe important for this discussion is that the function

from dipy.core.gradients import gradient_table

has a parameter called  b0_threshold.

This can be set to be 300 or higher and then the b0 will be considered
as the one at 300. So, if the datasets don't have b=0 but b=300 these can
be used instead.

This means that just by changing the b0_threshold the datasets can be fit
in a different ways.
Could be that the actual easier solution is to call the gradient table in a
different way (different
b0 threshold) rather than changing the API?

I will look now to the free water implementation to understand better the
different issues.

Cheers,
Eleftherios

p.s. Please give me your availability for a design hangout during the week.

On Fri, Mar 25, 2016 at 11:14 AM Ariel Rokem <arokem at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/20160409/b68a7fbe/attachment.html>