<div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 11:53 AM, Ariel Rokem <span dir="ltr"><<a href="mailto:arokem@gmail.com" target="_blank">arokem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi everyone, <div><br></div><div>In Rafael's recent PR implementing free-water-eliminated DTI (<a href="https://github.com/nipy/dipy/pull/835" target="_blank">https://github.com/nipy/dipy/pull/835</a>), 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 (<a href="https://github.com/nipy/dipy/pull/835#issuecomment-183060855" target="_blank">https://github.com/nipy/dipy/pull/835#issuecomment-183060855</a>). </div><div><br></div><div>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).</div><div><br></div><div>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? </div><div><br></div><div>Happy to hear what everyone thinks, before we move ahead with this. </div><div><br></div><div>Cheers, </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Ariel</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></font></span></div>
<br>_______________________________________________<br>
Neuroimaging mailing list<br>
<a href="mailto:Neuroimaging@python.org">Neuroimaging@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/neuroimaging" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/neuroimaging</a><br>
<br></blockquote></div><br></div>