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

Mon Apr 11 11:58:09 EDT 2016

Rafael can you please make a decision for when to meet to discussion about
this design change? You should pick the time as you are in a very different
timezone than us. Me and Ariel have only 3 hours of difference.

On Sun, Apr 10, 2016 at 12:13 PM Ariel Rokem <arokem at gmail.com> wrote:

> Hi Eleftherios,
>
> On Sat, Apr 9, 2016 at 3:08 PM, Eleftherios Garyfallidis <
> garyfallidis at gmail.com> wrote:
>
>>
>> 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?
>>
>>
> No - unfortunately I don't think this would be a solution to this
> particular concern. That is because what we need is really the value of the
> intercept of the signal-by-b-value curve. If we have an S0 measurement, we
> take that, but if we don't we need to *estimate* it.
>
> I will look now to the free water implementation to understand better the
>> different issues.
>>
>
> Yeah - some of the recent commits are about this particular issue (e.g.,
> https://github.com/nipy/dipy/pull/835/commits/89c09c7e4095309c9d7ae42eee313a4fd1f9c880),
> but note changes that follow (!). Maybe Rafael can also help explain.
>
>
>> Cheers,
>> Eleftherios
>>
>> p.s. Please give me your availability for a design hangout during the
>> week.
>>
>
> You can (always) find my availability here:
> https://www.google.com/calendar/embed?src=arokem%40gmail.com&ctz=America/Los_Angeles
>
> Cheers,
>
> Ariel
>
>
>>
>>
>> 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
>>>
>>
>> _______________________________________________
>> 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/20160411/7240d3c1/attachment.html>