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

Mon Apr 11 13:13:16 EDT 2016

Just talked with Rafael about this: next Monday at 10 AM PST works for both
of us. Does that work for you? I sent you a calendar invite. Anyone else
who wants to join, please let me know and I will add you to the hangout
invite as well.

Ariel

On Mon, Apr 11, 2016 at 8:58 AM, Eleftherios Garyfallidis <
garyfallidis at gmail.com> wrote:

>
> 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
>>
>
> _______________________________________________
> 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/95793b4d/attachment.html>