<div dir="ltr">Hi everyone, <div><br></div><div>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?</div><div><br></div><div>Cheers, </div><div><br></div><div>Ariel </div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 5, 2016 at 3:04 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"><div><br></div><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, Mar 3, 2016 at 7:28 AM, Eleftherios Garyfallidis <span dir="ltr"><<a href="mailto:garyfallidis@gmail.com" target="_blank">garyfallidis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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></blockquote><div><br></div></span><div>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.</div><div><br></div><div>As for code, for now, here's a sketch of what this would look like for the tensor model: </div><div><br></div><div><a href="https://gist.github.com/arokem/508dc1b22bdbd0bdd748" target="_blank">https://gist.github.com/arokem/508dc1b22bdbd0bdd748</a><br></div><div><br></div><div>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. </div><div><br></div><div>What do you think? Am I missing something big here? Or should I go ahead and start working on a PR implementing this? </div><div><br></div><div>Thanks! </div><span><font color="#888888"><div><br></div><div>Ariel</div></font></span><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div>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></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><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><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></div></div>_______________________________________________<br>
Neuroimaging mailing list<br>
<a href="mailto:Neuroimaging@python.org" target="_blank">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>
<br>_______________________________________________<br>
Neuroimaging mailing list<br>
<a href="mailto:Neuroimaging@python.org" target="_blank">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></span></div><br></div></div>
</blockquote></div><br></div></div>