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

Julio Villalon jevillalonr at gmail.com
Mon Apr 11 16:16:50 EDT 2016


Hi guys,

I was wondering if you guys could share some literature about the reason
behind acquiring volumes with low b-values instead of B0s.

Thanks!

Julio

2016-04-11 10:21 GMT-07:00 Eleftherios Garyfallidis <garyfallidis at gmail.com>
:

> Cool, thank you. That time is good for me.
>
> On Mon, Apr 11, 2016 at 1:15 PM Ariel Rokem <arokem at gmail.com> wrote:
>
>> 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
>>>
>>>
>> _______________________________________________
>> 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/a0f62f3d/attachment-0001.html>


More information about the Neuroimaging mailing list