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

Sun Apr 10 12:05:30 EDT 2016

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20160410/5be8431d/attachment.html>