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

[Eleftherios Garyfallidis]

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