Traco Redesign

I've put together a pull request to help clarify some of the ideas I proposed earlier on this thread.

In this pull request there is an example called newApi.py this example still needs some work, but I hope it will help show how this new tracking framework is meant to be used. In the example I've done some probabilistic tracking with the CSA and CSD models and some deterministic tracking with the CSA model. Be warned that the CSD fitting takes about 45 min.

To describe how this works, in each of the three tracking examples I create a direction getter and a tissue classifier which I pass with seeds and affine and a step_size to LocalTracking.

LocalTracking is an example of what we've been calling a “streamline manager” it tracks each seed and yields a streamline if the streamline doesn't hit any invalid points during tracking.

For the deterministic tracking I've modified the PeaksAndMetrics class to make it a bonefied DirectionGetter. It calls existing cython code that was written for EuDx.

For something to be a  DirectionGetter it needs to subclass from dipy.tracking.local.DirectionGetter and implement a cython cdef method called get_direction. The cython requirement is so the inner tracking loop can be compiled. A DirectionGetter needs to also have an initial_direction method. This method is python for now (but we can change this).

For the probabilist tracking the direction getter is ProbabilisticOdfWightedDirectionGetter (I'm open to a more succinct name). I've written the it in python, but used a cython helper type to make it work. Let me know if anyone wants to hear me rant about how this awesomeness works.

I've implemented one example tissue classifier,  ThresholdTissueClassifier, which like direction getter has a cython method called check_point. This method returns the type of tissue to the streamline manager/framework which then has to decide what to do next.

This PR needs more tests, a better example and there are some corner cases to deal with (literally the interpolation breaks at the corners of the image). But I promised you guys some code so here it is
I strongly disagree.

On Wed, Oct 1, 2014 at 11:11 AM, Eleftherios Garyfallidis <
notifications@github.com> wrote:

> In dipy/tracking/local/direction_getter_py.py:
>
> > +        return peak_directions(blob, self.sphere, **self._pf_kwargs)[0]
> > +
> > +
> > +class ProbabilisticDirectionGetter(PeakDirectionGetter):
> > +    """Randomly samples direction of a sphere based on probability mass
> > +    function (pmf).
> > +
> > +    The main constructors for this class are current from_pmf and from_shfit.
> > +    The pmf gives the probability that each direction on the sphere should be
> > +    chosen as the next direction. To get the true pmf from the "raw pmf"
> > +    directions more than ``max_angle`` degrees from the incoming direction are
> > +    set to 0 and the result is normalized.
> > +
> > +    """
> > +    @classmethod
> > +    def from_pmf(klass, pmf, max_angle, sphere, **kwargs):
>
> Bago, I will ignore the last part of your response because it is
> irrelevant with this PR. What your lab is doing has nothing to do with how
> we will name this function. This is decision of the dipy developers not of
> yours or mine or any lab.
>
> When I read your PR I see examples only with odf inputs or shfit inputs. I
> think a good compromize so we are all happy would be to have 3 classmethods
>
> from_shfit
> from_odf
> from_pmf
>
> Of course from_odf and from_pmf would be exactly the same. But at least
> now someone who is not familiar with the pmf idea can use the odf one.
>
> Is that okay with you?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/nipy/dipy/pull/341/files#r18296895>.
>